lorenzo.pagliei

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 

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 

There is also an object in the jasch collection to feed into Max 

NRPN. You'll have as output values between 0. and 1.

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.

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.

re-bug-ctlin-missing-lsb-of-14-bit-message

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.

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 

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.

>
> 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?
>


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 

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.

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.


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 

BTW, like you I am interested to know why two parallel [ctlin 1] and 

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.

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.......

>
> 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.
>
>


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:

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]. 

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