Handling mixed 7/14-bit CC input
Hmmm ... so I'm taking CC output from midiparse, which may be 7-bit or 14-bit (paired MSB/LSB messages), and I can't know which CC numbers are 14-bit.
The following is the best solution I've been able to come up with, seems to work well enough, but that [pipe 0] concerns me a little. If I'm missing anything simpler/better, a nudge would be appreciated.
John Pitcairn wrote:
> Hmmm ... so I'm taking CC output from midiparse, which may be 7-bit
> or 14-bit (paired MSB/LSB messages), and I can't know which CC
> numbers are 14-bit.
Usually the fine LSB has a Midi controler + 32 compared to MSB Midi
controler.
> The following is the best solution I've been able to come up with,
> seems to work well enough, but that [pipe 0] concerns me a little. If
> I'm missing anything simpler/better, a nudge would be appreciated.
I don't see any test for controller numbers + 32, I would not rely on
the controler to send always two parts...
Look at my St.DblCtlin, its supposed to read 14-bit controllers (haven't
tested it for a while because of a lack of high resolution controlers)
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
sorry if this is a repeat, but did you check out the old pitch bend
object?
xbendin or something like that. it is 14bit.
Unfortunately I'm keen to avoid 3rd-party externals - this will be going in a commercial app.
The manual doesn't make it explicitly clear that [next] is intended to be used this way however, and I have since determined the patch won't work for all hardware, even if the events have the same timestamp (according to MIDI Monitor). So I'm not sure exactly how the next object decides what is part of the "same" event for incoming MIDI. Rats.
Plan B does involve testing for MSB/LSB (+32) messages arriving back to back, but that becomes a bit more complicated to implement.
It would be nice if xbendin could be coaxed into help here, but 14-bit pitchbend is just a single 3-byte message anyway.
Hmmm.
John Pitcairn wrote:
> Quote: Stefan Tiedje wrote on Thu, 15 June 2006 18:10
> ---------------------------------------------------- Unfortunately
> I'm keen to avoid 3rd-party externals - this will be going in a
> commercial app.
Don't worry, my abhaXions are supposed to be LGPL, and though the
St.ools are supposed to be GPL which would not allow you to close source
it, I can give you the permission to just do it, as you are kindly asking...
The algorithm by the way is pretty simple, just look at it to create
your own version, nothing protectable about it I guess...
> The manual doesn't make it explicitly clear that [next] is intended
> to be used this way however, and I have since determined the patch
> won't work for all hardware, even if the events have the same
> timestamp (according to MIDI Monitor). So I'm not sure exactly how
> the next object decides what is part of the "same" event for incoming
> MIDI. Rats.
14-bit Midi is never "one" event, its two!! always - (The exeption is
pitchbend). You have to detect the controller numbers, if they differ by
32, they belong together...
> Plan B does involve testing for MSB/LSB (+32) messages arriving back
> to back, but that becomes a bit more complicated to implement.
Its less complicated as you might think (at least less complicated as
your patch and also less complicated as my more universal and feature
overloaded St.DblCtlin ...;-)
Let me know if it works for you (cant test it with hardware at the
moment...)
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Sure, that sort of thing works fine, but my problem is that I won't know in advance which CC numbers are 14-bit, and I want to allow for the possibility of a 14-bit CC7 (say) AND a 7-bit CC7, depending on what message follows it, so I can't just look for them by number.
Ideally, I don't want the user to have to think about CC numbers at all, apart from perhaps an "allow 14-bit CC" checkbox, so that part of the processing can be turned off if it's obviously not applicable.
For some reason the "next" object worked fine with my BCR2000 in USB mode, identifying the back-to-back MSB/LSB CC messages as part of the "same" event, which is what got me a bit excited initially. But that seems to be a (very) special case.
Anyway, I have a solution hacked up, which I'll post back here after a bit more testing and cleanup.
Thanks for your time and assistance.