bank select
how should a correct bank select message look like?
i send "177, 0, 1, 177, 32, 1, 192, 1" but the device doesnt do what i want.
MSB, LSB, PG is usual way for multibank devices.
But CC channel should match PG change channel
177 is ch2 , 192 ch1 ...
oh damn, 176 :) thanks.
ok and what about incoming bank select commands. how would i distinguish between an MSB/LSB pair and a "regular" controller 32 message using midiparse?
That is only the thing of midi receiver to respond
to MSB/LSB pair or not.
If a device is set to respond to LSB/MSB + PG change,
it would ignore it if message is not complete.
look at it as a sysex string.
So there is no "regular" or "unregular" CC 32.
It is only what the midi receiver is set to respond to.
If You have some midi hardware that needs that,
You can easily test what would happen if You mess arround with
that MSB/LSB/PG string.
I mean if the message trio gets interrupted by some other CC
message in between, or has timeout etc.
I would use match to get the data recognised.
I think it works similar in hardware devices.
i dont know much about these midi things, but yes, for sysex it is clear how it works: it starts with a unique value and it will be simply ignored when there is no F7 at the end. (and in max you would solve it simply by [route])
but say i want to fake a receiving device in a max patch, and that receiving device should react to both, CC 32 - but also bank select.
then this would mean that it had to check ANY input (of the chosen "master channel") against the combination "177, 0, n, 177, 32, n,"? i somehow wished midiparse would that for me...
You can just go with thresh and match as in example I posted yesterday.
That will report received MSB LSB PG combination.
I don't know why should CC 32 be used for anything else
in case in the patch or midi device it is used for bank select.
But if You really want that, and also want to distinguish if CC 32
came in in combination with CC 0 and PG, than midiparse alone won't help You.
As midi is serial protocol, data gets in byte by byte.
So one has to group that using thresh to be able to work on the list.
If You want to simulate a hardware device, then I remember
having JV 1080 which responded exactly to that MSB LSB PG schema.
It recalled bank and the preset only if whole string came in.
Single CC 0 or CC 32 messages were ignored, but single PG change
message on specific midi channel recalled preset from current bank.
I don't remember if CC 0 and 32 were assignable as "normal" CC messages.
-----------
I think that kind of behaviour should not be difficult to program in max.
Just You need to decide if CC 0 & 32 have to be filtered out
in case they come in together with PG change as Bank-Preset combo.
That would complicate the things a bit.
now when i want to do the same for MMC, MTC, bank select and sysex, each of them will require such a match filter before the midiparse object. while some other things would be cool to have behind it.
maybe it would be easier to write everything on my own? could that be best practice?
omg and as it seems some units want the LSB first. ;(
sysex, MMC, MTC have nothing to do with CCs.-
So why would one need to separate that ?
You can just detect bank change and leave the rest as is.
It could all be very simple - just don't use bankCC messages for other things, and all is fine.
P.S.
I mean the point is - if You need CC 0 and 32 to serve as bank change,
than whenever they get received, does not matter if in a string
for MSB LSB PG, or just as single controller,
their value will be passed to anything that is listening to them.
Only the recipient that needs Bank change will ignore them
if they did not arrive in a string.
But the problem is that if You send Bank Change,
then other receivers will get that number and interpret is as CC value .
not really good.
Here a possible filter
"So why would one need to separate that ?"
for example to display it - but also to use it. everything what is not covered by midiparse but comes in from a midi port must be received somehow using custom code.
one of the two contexts what i am doing here is to use a computer as midi patchbay, i.e. routing midi data. to route data, i have to track it first.
it would be great if midiparse had another outlet for "if input doesnt match", just like route/select. that is the direction i am thinking, making a new midiparse abstraction.
this isnt fully working but you can see where i am going.
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 18 538 113 9109513 midiparse;
#P newex 148 539 97 9109513 print rest;
#B color 14;
#P newex 371 364 73 9109513 t l 0;
#P newex 148 384 73 9109513 gate;
#P newex 371 396 97 9109513 print bankselect;
#B color 14;
#P newex 148 315 73 9109513 t l l 1;
#P newex 211 247 83 9109513 print sysex;
#B color 14;
#P newex 307 197 49 9109513 1;
#P newex 248 197 49 9109513 2;
#P newex 148 217 73 9109513 gate 2;
#P message 148 89 156 9109513 240 \, 100 100 100 \, 55 55 \, 247;
#P newex 248 169 128 9109513 select 240 247;
#P newex 148 149 73 9109513 t l l;
#P newex 606 257 49 9109513 t b i i;
#P newex 760 278 49 9109513 + 192;
#P newex 694 277 49 9109513 + 176;
#P user umenu 606 180 52 9109540 1 32 196 0;
#X add 1;
#X add 2;
#X add 3;
#X add 4;
#X add 5;
#X add 6;
#X add 7;
#X add 8;
#X add 9;
#X add 10;
#X add 11;
#X add 12;
#X add 13;
#X add 14;
#X add 15;
#X add 16;
#P newex 606 315 192 9109513 list set 176 0 nn 176 32 nn 192 nn;
#P message 148 67 156 9109513 6 32;
#P newex 371 335 192 9109513 match 176 0 nn 176 32 nn 192 nn;
#P newex 14 43 50 9109513 midiin;
#P message 148 45 156 9109513 176 0 1 \, 176 32 1 \, 192 22;
#P comment 661 181 100 9109513 Master Channel;
#P connect 12 0 10 0;
#P connect 1 0 10 0;
#P connect 4 0 10 0;
#P connect 15 0 13 0;
#P connect 14 0 13 0;
#P connect 13 0 17 0;
#P connect 20 1 19 0;
#P connect 17 2 19 0;
#P connect 19 0 21 0;
#P connect 10 0 13 1;
#P connect 13 1 16 0;
#P connect 17 0 19 1;
#P connect 10 1 11 0;
#P connect 11 0 14 0;
#P connect 11 1 15 0;
#P connect 5 0 3 0;
#P connect 17 1 3 0;
#P connect 3 0 20 0;
#P connect 20 0 18 0;
#P connect 6 0 9 0;
#P connect 9 0 5 0;
#P connect 7 0 5 1;
#P connect 9 1 7 0;
#P connect 7 0 5 4;
#P connect 9 2 8 0;
#P connect 8 0 5 7;
#P window clipboard copycount 23;
your filter is a good idea (deleting the messagebox)
"thresh 10" is not working btw.
it merges all kind of input into weird lists :)
the alternative would be to leave it out (because match does really need it) and reset the match object(s) somehow in case some problem appear with similar strings (which could happen inside sysex strings, among others.)
contrary concept:
- give up the idea of allowing CC 0 (unlike 32, nobody uses 0 in practice)
- dont care for wrong data which should not occur == no übersecure coding anymore
result:
- now the recognization of bank select MSB/LSB can be done post-midiparse.
- only CC data will be affected by the process
- the process done to CCs which are not CC#0 is limited to t - match - gate - route (not very expensive)
- no latency
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 426 167 93 9109513 print pgm;
#B color 14;
#P newex 300 362 42 9109513 t b l;
#P newex 385 382 70 9109513 zl reg;
#P newex 300 332 69 9109513 match 32 nn;
#P newex 272 402 70 9109513 zl join;
#P message 64 80 85 9109513 176 \, 0 \, 22;
#P newex 133 327 57 9109513 route 0;
#P newex 441 254 53 9109513 1;
#P newex 441 230 53 9109513 loadbang;
#N vpatcher 315 276 497 445;
#N comlet 0;
#P outlet 38 92 15 0;
#P window setfont "Sans Serif" 9.;
#P newex 38 63 30 9109513 t 1;
#N comlet data;
#P outlet 100 92 15 0;
#N comlet data;
#P inlet 100 47 15 0;
#P connect 0 0 2 0;
#P connect 2 0 3 0;
#P connect 0 0 1 0;
#P pop 1;
#P newobj 216 294 43 9109513 p t1d;
#P newex 133 274 58 9109513 gate 2;
#P newex 130 183 61 9109513 t l l;
#P newex 180 472 72 9109513 print cc;
#B color 14;
#P newex 272 472 93 9109513 print bankselect;
#B color 14;
#P newex 276 232 70 9109513 t 2 l;
#P newex 276 203 70 9109513 match 0 nn;
#P message 19 59 85 9109513 176 \, 32 \, 22;
#P message 144 58 156 9109513 176 \, 0 \, 1 \, 176 \, 32 \, 1 \, 192 \, 22;
#P newex 78 129 171 9109513 midiparse;
#P connect 0 3 18 0;
#P connect 13 0 0 0;
#P connect 1 0 0 0;
#P connect 2 0 0 0;
#P connect 0 2 7 0;
#P connect 4 0 8 0;
#P connect 11 0 8 0;
#P connect 9 0 8 0;
#P connect 8 0 12 0;
#P connect 12 1 6 0;
#P connect 7 1 8 1;
#P connect 8 1 9 0;
#P connect 16 0 14 0;
#P connect 14 0 5 0;
#P connect 7 0 3 0;
#P connect 3 0 4 0;
#P connect 9 1 15 0;
#P connect 15 0 17 0;
#P connect 17 1 14 1;
#P connect 17 0 16 0;
#P connect 10 0 11 0;
#P connect 4 1 16 1;
#P window clipboard copycount 19;
You are right about not filtering any midi for display puproses.
Just like midi monitor.
For midi routing - it usually needs only redirection of
send/receive devices and maybe rechannelising.
But for all of that one can leave devices itself to cope with
messages.
But for internal / custom, whatsoever usage, I would also try
dedicated ctlin, pgmin, etc sysexin and rtin midi objects,
cause they allready offer channel selection,
and that could make filtering using thresh or pack -> match easier.
If thresh 10 (default) can't work, try it without other arguments,
there is also quickthresh - adjustable.
---------
The last patch You posted has one problem -
You are not taking midi channel output from midiparse
into filtering.
So if one sent bank change messages on several channels
like most of DAWs would do on the beginning of the sequence
than only first one would be recognised as such,
the following ones would be useless .
There are still many midi devices that need both bank 0 & 32 messages.
actually i have never used any of these special midi in objects, because the main problem remains: that the regular [midiin] still has all the rubbish in it, too.
about channel, i am aware that it is missing, but eventually it is even easier to do it like that compared to hex input? all the calculations which are required for this will only affect occurances of CC#0
the more i read about how different devices use things like bank select differently the more i understand why midiparse doesnt cover it.
Bank change is only a CC number, nothing else.
Only receiving device decides to use it for bank change.
Thee is no "universal" midi synth or whatever device.
They all interpret messages as they are set to.
So this all seems to become a complicated story ,
and I still don't really understand what are You trying to build.
Just for fun:
Logic Audio bank message menu
exactly.
and which moron once suggested to have only 128 sound patches but 16000 banks anyway? on planets with intelligent life they would have done it the other way round.
In fact midi was the reason I started programming with Max.
I had 12 Powermac towers in the studio, all filled with Sample libraries,
and needed something to route midi, select samples,
change keymaps depending on preset etc from my central Mac with Opcode
Studio Vision and Protools hardware.
That was maaaany years ago.
hehe, i just noticed that there is a sysexin since 4.6
so i will just make my own sysexin for older versions and thats it.
...instead of this^^
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 706 419 490 9109513 110.manygate;
#P newex 706 304 115 9109513 route 247;
#P newex 902 323 49 9109513 t 1 247;
#P newex 843 323 49 9109513 t 2;
#P newex 706 343 115 9109513 gate 2;
#P newex 843 295 128 9109513 select 240 247;
#P newex 706 275 115 9109513 t l l;
#P newex 706 380 104 9109513 midiparse;
#P connect 2 1 5 0;
#P connect 2 0 4 0;
#P connect 1 1 2 0;
#P connect 3 1 7 7;
#P connect 5 1 3 1;
#P connect 6 1 3 1;
#P connect 0 6 7 6;
#P connect 0 5 7 5;
#P connect 0 4 7 4;
#P connect 0 3 7 3;
#P connect 0 2 7 2;
#P connect 0 1 7 1;
#P connect 0 0 7 0;
#P connect 3 0 0 0;
#P connect 4 0 3 0;
#P connect 5 0 3 0;
#P connect 1 0 6 0;
#P window clipboard copycount 8;
no wait, it exist for 4.1 too. damn, that happens when you use 4 different computers.
Nice to see I'm not the only one still running that old max versions.
I am not sure, but think there was some 3d party external dealing with sysex in max 3.6
i am even more ignorant than i thought: sysexin is already present in 4.1.
however, of course those special midi input objects are still no alternative for me.
if i want to filter and route and display midi streams - and also include an option for "everything else" (besides sysex and what midiparse offers) - the whole thing only works with custom filtering like shown in my last patch anyway.
and "everything else" is quite a lot, not only MPE and all that clocking and transport stuff (which could easily be programmed for max 4.1) but for example also "broken data" (say like a sysex which has begun but not been ended).
the only thing i gave up is the original topic, bankselect, because it turned out to be nonsese.
I am afraid You won't be able to show "broken" sysex message,
either checking raw midi from midiin,
or output of sysexin, because it does not get recognised at all.
Most hardware devices would not send it at all, till the whole string gets compiled.
i know that it is like that for receiving data; the target device will not do anything with the sysex until its complete.
but at least software can send it, no? in max itself for example it is easy to send wrong data to midiout. :)
Midi specification and rules were only partly implemented
into hardware and software.
Every manufacturer did it so or so...
For example there were units which would try to thin data stream,
if messages repeated, so instead of sending
176 7 88, 176 7 89, 176 7 90
only 176 7 88, 89, 90 was sent.
Not every hardware recognised that.
Also midi stream was produced from different processors,
and so there were units (mostly mixers) which communicated faster
when using sysex, than CC messages, even that sysex
had much longer string than a simple CC.
The fact that max midiout sends uncomplete sysex message
merged with next complete one is a bug in the software.