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


    Mar 08 2007 | 8:12 pm
    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

    • Mar 08 2007 | 8:39 pm
      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.
    • Mar 08 2007 | 10:54 pm
      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?
      >
    • Mar 09 2007 | 12:19 am
      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.
    • Mar 09 2007 | 7:53 am
      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.
      >
      >
    • Mar 11 2007 | 10:24 pm
      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: