Czesc Krzysztof, hi all,
I'm trying to record into xeq_record. The notes are recording fine, however I really need to capture the pitch bend messages. I imported a midifile to take a look and I see how the bend messages show up. I get:
0 1-track 224 112 65 1 ;
which I understand as: time, track name, pitch bend status byte (0xe0), lower 7 bits , upper 7 bits and finally channel number. Right?
When I print from the [xeq_parse]'s 6th outlet I get: 14401 and I don't understand why...
bendin object lets me read a 14 bit(?) value for pitch bend (out the left outlet) and channel (right outlet).
Now comes the question you've been all anticipating: How do I use bendin to record the bender data into xeq_record and stay compatible?
Or should I use midiin?
I tried midiin with midiparse (maxlib) but it seems to be converted to 7 bit so it wouldn't help...
Please, enlighten me.
On Sat, 26 Oct 2002 02:07:58 -0500 Michal Seta mis@creazone.com wrote:
When I print from the [xeq_parse]'s 6th outlet I get: 14401 and I don't understand why...
I do understand:
112 --> [<< 7] --> [| 65] --> 14401
I've got to learn a bit about bit twiddling.
So, how do I do the reverse?
On Sat, 26 Oct 2002, Michal Seta wrote:
On Sat, 26 Oct 2002 02:07:58 -0500 Michal Seta mis@creazone.com wrote:
When I print from the [xeq_parse]'s 6th outlet I get: 14401 and I don't understand why...
I do understand: 112 --> [<< 7] --> [| 65] --> 14401 I've got to learn a bit about bit twiddling. So, how do I do the reverse?
(x<<n)|y is the same as (x<<n)+y when y is smaller than 1<<n (and not negative). in a more general situation, however, ORing would not be inversible. (I don't know why | was used instead of + here; + is clearer)
z = (x<<7)|65 z = (x<<7)+65 z-65 = x<<7 (z-65)>>7 = x
matju
On Sun, 27 Oct 2002 10:30:35 -0500 (EST) Mathieu Bouchard matju@sympatico.ca wrote:
z-65 = x<<7 (z-65)>>7 = x
Thanks!
Sorry for replying in 2 installments but I needed to get it off my chest...
On Sun, 27 Oct 2002 10:30:35 -0500 (EST) Mathieu Bouchard matju@sympatico.ca wrote:
(x<<n)|y is the same as (x<<n)+y when y is smaller than 1<<n (and not negative). in a more general situation, however, ORing would not be inversible. (I don't know why | was used instead of + here; + is clearer)
I got the '|' instead of '+' from this code: (http://home.planet.nl/~roosp/mt_pitch.html)
unsigned short CombineBytes(unsigned char First, unsigned char Second) { unsigned short _14bit;
_14bit = (unsigned short)Second; _14bit<<=7; _14bit|=(unsigned short)First; return(_14bit); }
of course I should have looked into Krzysztof's source for xeq_parse first (which I did while I was downloading my messages which already included the solution) and there the '+' is used and, of course, it is clearer. reversing the addition _is_ simple :)
Thanks a lot.
Czesc Michal,
thanks for a bug report... actually, two bug reports -- one for xeq_parse, the other for the Pd's 'bendin'/'bendout' code!
When I print from the [xeq_parse]'s 6th outlet I get: 14401 and I don't understand why...
and rightly so, because I screwed things up. It should have sent 8432. Pitch bend data is little-endian (while midi files use big-endian numbers, and I guess I was then assuming everything was big-endian:)
bendin object lets me read a 14 bit(?) value for pitch bend (out the left outlet) and
channel (right outlet).
yeah, it is in the range 0..16383. But the range accepted by a 'bendout' object is -8192..8191. So instead of [bendin]->[bendout] one has to put [bendin]->[- 8192]->[bendout].
- (no bug here)
I tried midiin with midiparse (maxlib) but it seems to be converted to 7 bit so it
wouldn't help...
do you really mean maxlib -- I have thought 'midiparse' was available through the cyclone only. I have a note in the source about checking that max/midiparse filters lsb out (perhaps I need to recheck this?)
- (lots of bugs here)
I have all but started a 0.2 branch of xeq. But this is not so easy. Allocating time to Pd, even to just reading this list, is a luxury I barely afford these days...
Krzysztof
Michal Seta wrote: ...
I'm trying to record into xeq_record. The notes are recording fine, however I really
need to capture the pitch bend messages. I imported a midifile to take a look and I see how the bend messages show up. I get:
0 1-track 224 112 65 1 ;
which I understand as: time, track name, pitch bend status byte (0xe0), lower 7 bits ,
upper 7 bits and finally channel number. Right?
On Tue, 29 Oct 2002 18:04:46 +0100 Krzysztof Czaja czaja@chopin.edu.pl wrote:
Czesc Michal,
thanks for a bug report... actually, two bug reports -- one for xeq_parse, the other for the Pd's 'bendin'/'bendout' code!
When I print from the [xeq_parse]'s 6th outlet I get: 14401 and I don't understand why...
and rightly so, because I screwed things up. It should have sent 8432. Pitch bend data is little-endian (while midi files use big-endian numbers, and I guess I was then assuming everything was big-endian:)
ahhh....
bendin object lets me read a 14 bit(?) value for pitch bend (out the left outlet) and
channel (right outlet).
yeah, it is in the range 0..16383. But the range accepted by a 'bendout' object is -8192..8191. So instead of [bendin]->[bendout] one has to put [bendin]->[- 8192]->[bendout].
I was gonna answer that 'hmm... however when I record a sequence and then play back I get the right behaviour' and noticed that when I convert [bendin] output to msb+lsb I got them swaped on the output. So, feeding [xeq_parse] directly into [bendin] gives the right result now. Thank god for mistakes.
However, I think only [bendout] is -8192..8192, no? [bendin] seems to be behaving correctly.
do you really mean maxlib -- I have thought 'midiparse' was available through the cyclone only.
Yeah, sorry. midiparse from cyclone.
- (lots of bugs here)
I have all but started a 0.2 branch of xeq.
Well, for now I deal with what I have :)
Thanks for clarifications.
-
Krzysztof Czaja -
Mathieu Bouchard -
Michal Seta