Forums > MaxMSP

Handling mixed 7/14-bit CC input

June 14, 2006 | 10:34 am

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.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#N vpatcher 20 74 361 596;
#N comlet list: number , value;
#P outlet 61 466 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 61 374 21 196617 b 1;
#P newex 61 424 106 196617 pack;
#P newex 85 271 45 196617 gate 2;
#P newex 61 398 34 196617 i;
#P newex 120 78 125 196617 unpack;
#P newex 195 245 36 196617 pipe 0;
#P newex 157 271 48 196617 gate 2;
#P newex 195 319 50 196617 +;
#P newex 195 295 38 196617 * 128;
#P newex 195 180 22 196617 2;
#P newex 157 180 22 196617 1;
#P newex 195 221 50 196617 gate 2;
#P newex 251 111 50 196617 next;
#N comlet list: number , value;
#P inlet 120 47 15 0;
#P connect 7 0 13 0;
#P connect 6 0 13 0;
#P connect 13 0 10 0;
#P connect 10 0 12 0;
#P connect 12 0 14 0;
#P connect 4 0 11 0;
#P connect 3 0 11 0;
#P connect 11 0 10 1;
#P connect 0 0 9 0;
#P connect 9 0 11 1;
#P connect 1 0 3 0;
#P connect 4 0 7 0;
#P connect 3 0 7 0;
#P connect 6 0 12 1;
#P connect 7 0 12 1;
#P connect 1 1 4 0;
#P connect 4 0 2 0;
#P connect 3 0 2 0;
#P connect 2 0 8 0;
#P connect 8 0 7 1;
#P connect 7 1 5 0;
#P connect 5 0 6 0;
#P connect 9 1 2 1;
#P connect 2 1 6 1;
#P connect 9 1 1 0;
#P pop;
#P newobj 207 170 50 196617 p 14-bit;
#P newex 207 198 50 196617 print;
#P newex 139 97 126 196617 midiin;
#P newex 139 129 219 196617 midiparse;
#P connect 3 0 2 0;
#P connect 0 2 3 0;
#P connect 1 0 0 0;
#P window clipboard copycount 4;


June 15, 2006 | 6:10 am

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


June 15, 2006 | 12:57 pm

sorry if this is a repeat, but did you check out the old pitch bend
object?
xbendin or something like that. it is 14bit.


June 16, 2006 | 5:02 am

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.


June 16, 2006 | 8:31 pm

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

#P inlet 84 79 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 151 119 62 196617 prepend set;
#P newex 151 99 50 196617 + 32;
#P newex 151 79 69 196617 loadmess $1;
#P comment 232 146 100 196617 $2 Midi Channel;
#P outlet 84 221 15 0;
#P newex 134 168 13 196617 b;
#P newex 84 168 44 196617 < < 7;
#P newex 84 192 77 196617 +;
#P newex 151 144 62 196617 ctlin $1 $2;
#P newex 84 144 64 196617 ctlin $1 $2;
#P comment 232 124 100 196617 $1 controler# MSB;
#P connect 11 0 1 0;
#P fasten 11 0 2 0 89 140 156 140;
#P fasten 2 0 5 0 156 165 139 165;
#P connect 2 0 3 1;
#P connect 10 0 2 0;
#P connect 9 0 10 0;
#P connect 8 0 9 0;
#P connect 1 0 4 0;
#P connect 3 0 6 0;
#P fasten 5 0 3 0 139 188 89 188;
#P connect 4 0 3 0;
#P window clipboard copycount 12;

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


June 19, 2006 | 12:36 am

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.


Viewing 6 posts - 1 through 6 (of 6 total)