johnpitcairn

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.

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. 

handling-mixed-714-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

Usually the fine LSB has a Midi controler + 32 compared to MSB Midi 

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

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


sorry if this is a repeat, but did you check out the old pitch bend 

xbendin or something like that. it is 14bit.

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.

Plan B does involve testing for MSB/LSB (+32) messages arriving back to back, but that becomes a bit more complicated to implement. 

> 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

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

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 

> 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 

Let me know if it works for you (cant test it with hardware at the 

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

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.

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.

Handling mixed 7/14-bit CC input