Re: Bug? ctlin missing LSB of 14-bit message

Mar 8, 2007 at 8:12pm

Re: Bug? ctlin missing LSB of 14-bit message

Hi,

I’ve worked on this just a few days ago. Ctlin only serves for 7bit
CC e.g. for midi messages made of 3 bytes.

If you work with BCR-2000 or BCF-2000, and you want to feed into max
Pitch-bend 14-bit it doesn’t work because these machines send only
7bit pitch-bend values.

If you want to work with 14bit controllers you have 2 solutions:

1- programming your BCR knobs as CC 14-bit and in Max using midiin
and translate raw midi messages (6bytes of message)

2- programming your BCR knobs as NRPN and in Max the same as 1 but
messages are 12 bytes long

There is also an object in the jasch collection to feed into Max
NRPN. You’ll have as output values between 0. and 1.

Here’s my abstractions.

hope this helps

Cheers

L

#30704
Mar 8, 2007 at 8:39pm

Sure, I can parse it all out myself, but that’s rather more long-winded and certainly less efficient than using individual ctlin instances for the (known) CC numbers would be.

I’d really still be inclined to call it a bug. 14-bit CCs ARE two discrete 7-bit CC messages (both have status bytes, we’re not talking running status here), and you’d therefore expect ctlin to see them both, wouldn’t you?

I’m not actually writing for a BCR2000, BTW, that’s just used for testing. The actual hardware I’m targeting is not programmable.

#98663
Mar 8, 2007 at 10:54pm

Yes, it’s this special feature” of ctlin that forced me to parse midi
raw data…..with all the risks if one byte is lost (using match)!

BTW, i’ don’t know how ctlin parses midi raw data….it’s sure that
it recognize only the MSB. I’ve started working exactly as you with
two ctlin on CC1 and CC33 to parse LSB….but it doesn’t work, i agree.

Il giorno 08/mar/07, alle ore 21:39, John Pitcairn ha scritto:

>
> I’d really still be inclined to call it a bug. 14-bit CCs ARE two
> discrete 7-bit CC messages (both have status bytes, we’re not
> talking running status here), and you’d therefore expect ctlin to
> see them both, wouldn’t you?
>

#98664
Mar 9, 2007 at 12:19am

Quote: lorenzo.pagliei wrote on Fri, 09 March 2007 11:54
—————————————————-
> Yes, it’s this special feature” of ctlin that forced me to parse
> midi raw data…..with all the risks if one byte is lost (using
> match)!

It’s probably safer to use [midiparse] then handle the list output from that, that way you don’t have to worry about invalid input.

#98665
Mar 9, 2007 at 7:53am

yes, i’ve tried with a list verification process, but with [match],
as to now, I’ve obtained the best results in parsing the 6 (or 12 for
NRPN) byte messages. After all it look for the right byte pattern and
it works. The other solution is more delicate because you have to
handle into groups of 3 or 6 or 12 the raw midi stream with [zl
group] or similar….

BTW, like you I am interested to know why two parallel [ctlin 1] and
[ctlin 33] don’t parse MSB and LSB…..

or else why xbendin doesn’t parse a CC 14bit even if the midi
controller is set on control number 1 and 33…….

Il giorno 09/mar/07, alle ore 01:19, John Pitcairn ha scritto:

>
> Quote: lorenzo.pagliei wrote on Fri, 09 March 2007 11:54
>
> It’s probably safer to use [midiparse] then handle the list output
> from that, that way you don’t have to worry about invalid input.
>
>

#98666
Mar 11, 2007 at 10:24pm

Quote: lorenzo.pagliei wrote on Fri, 09 March 2007 20:53
—————————————————-
> or else why xbendin doesn’t parse a CC 14bit even if the midi
> controller is set on control number 1 and 33.

[xbendin] will be expecting a 3-byte message, pitchbend status byte (224-239) followed by LSB then MSB.

After you have the full CC message you could separate out the LSB/MSB bytes, prepend a pitchbend status byte and feed it to [xbendin].

But a simple [< < 7] on the MSB then adding the LSB is somewhat more efficient anyway (if you care about efficiency), even if you use pitchebend running status. ie:

#P button 311 43 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 311 76 74 196617 b 2;
#P newex 337 122 33 196617 delay;
#P number 375 152 74 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 375 122 34 196617 timer;
#P newex 311 100 62 196617 uzi 99999;
#P button 59 43 15 0;
#P newex 59 76 74 196617 b 2;
#P newex 85 122 33 196617 delay;
#P number 123 152 74 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 123 122 34 196617 timer;
#P newex 59 100 62 196617 uzi 99999;
#P newex 359 330 27 196617 i;
#P newex 359 300 82 196617 +;
#P newex 359 275 31 196617 < < 7;
#P newex 311 246 134 196617 unpack 0 0 0 0 0 0;
#P newex 59 245 134 196617 unpack 0 0 0 0 0 0;
#P newex 311 218 135 196617 match 176 1 nn 176 33 nn;
#P message 311 182 134 196617 176 , 1 , 1 , 176 , 33 , 127;
#P newex 107 403 27 196617 i;
#P newex 107 371 50 196617 xbendin;
#P newex 167 318 71 196617 loadmess 224;
#P newex 59 219 135 196617 match 176 1 nn 176 33 nn;
#P message 59 183 134 196617 176 , 1 , 1 , 176 , 33 , 127;
#P connect 3 0 4 0;
#P connect 2 0 3 0;
#P connect 22 0 18 0;
#P connect 18 1 21 0;
#P connect 18 0 5 0;
#P connect 12 1 15 0;
#P connect 16 0 12 0;
#P connect 12 0 0 0;
#P connect 21 0 19 1;
#P connect 19 0 20 0;
#P connect 22 1 19 0;
#P connect 23 0 22 0;
#P connect 17 0 16 0;
#P connect 16 1 13 0;
#P connect 13 0 14 0;
#P connect 15 0 13 1;
#P connect 10 0 11 0;
#P connect 9 0 10 0;
#P connect 8 5 10 1;
#P connect 8 2 9 0;
#P connect 6 0 8 0;
#P connect 7 5 3 0;
#P connect 7 2 3 0;
#P connect 1 0 7 0;
#P connect 5 0 6 0;
#P connect 0 0 1 0;
#P window clipboard copycount 24;

#98667

You must be logged in to reply to this topic.