Sequential Rev2 - Request Program Dumps
I just purchased a Prophet Rev2, and I'm in the process of building a patch for augmenting the sequencer lanes.
The patch is currently receiving data per knob turn on Rev2, as well as updating the device as I make adjustments via Max.
The only issue I now have is that I'd like for each program change to dump out the respective sequence data to populate my patch. (Rather than having to go through each step, turning knobs.)
The manual gives the following information for Requesting Program Dumps:
1 - 1111 0000 (SysEx start)
2 - 0000 0001 (DSI ID)
3 - 0010 1111 (Rev2 ID)
4 - 0000 0101 (Request Program Transmit)
5 - 0000 00vv (Bank Number, 0-7)
6 - 0vvv vvvv (Program Number)
7 - 1111 0111 (SysEx end)
I understand that these are bytes in binary.
My questions are:
1. Am I correct in thinking the space indicates that they're not to be evaluated as one value (ie. the first line being 15 0, second line being 0 1, etc)?
2. What would be the best methodology for sending this out of Max?
Thanks for your time,
-- Aaron
no that is 8 bit binary number.
converted to int :
240 1 47 5 $1 $2 247
2 changeable arguments are bank number and program number
this
6 - 0vvv vvvv (Program Number)
simply means max value is
0111 1111 = 127
@SOURCE AUDIO -- Ah ok. I see. Thank you. :)
I was able to find a thread that directed me to Jasch's [bitlist] external for bi-directional conversion: https://cycling74.com/forums/binary-to-decimal/replies/1#reply-58ed1fe56908cf22c838c087
That said, when sending ^those through it, I got different values for a few:
1 1 1 1 0 0 0 0 = 15
0 0 0 0 0 0 0 1 = 128
0 0 1 0 1 1 1 1 = 244
0 0 0 0 0 1 0 1 = 160
-
-
1 1 1 1 0 1 1 1 = 239
Did I do something wrong when inputting them through [bitlist], or is [bitlist] doing something I wasn't expecting? Do you have a more preferred method of conversion?
Many thanks,
- Aaron
why not try to understand binary format ?
it runs from right to left , and each place is double of the previous
8 bit max :
1 1 1 1 1 1 1 1
is sum of :
128 64 32 16 8 4 2 1
1 1 1 1 0 0 0 0 is sum of
128 64 32 16 0 0 0 0 = 240 decimal
Ah ok, I appreciate the explanation; that makes sense. -- I guess [bitlist] is set to read right to left then, which would result in simply needing to add a [zl rev] before or after.
Which then leaves the last question -- What methodology is best for sending this out of Max?
here is bitlist example set to what you need
To send that sysex you can use midiout or sxformat.
Firstly, thank you so much (as always) for you time. It's really really appreciated. :)
Second, I'd actually anticipated needing to convert back to 8-bit binary before sending back out.
I take it that's not necessary afterall?
Thank you so much,
- Aaron
You are welcome (as allways)
and you take it right, no need to convert anything.
Midi out does the job of itering the list , so there is no need to use sxformat.
Ah ok, sweet. :)
I suppose another question would be what are the advantages/ disadvantages of using the message box with the $'s or a [pak 240 1 47 5 i i 247], etc.
I think the right question is how to avoid sending of sysex string
before it is "baked", using pak will output if any list member changes.
example I posted not.
Ah ok, I see. That makes sense. I appreciate it. :)
I was able to get everything working for the most part. The only slight hiccup is when capturing the resulting SysEx dump (which I'm doing with [zl group]), the position of the data I'm seeking seems to move around a bit from program to program.
I figured this was likely due to other data coming into [zl group] before the request was made, so I placed a [gate] before it, and set a [thresh 200] -> [t zlclear 0] to close it and clear any remaining data from the group, but things still seem to move around a bit. Not entirely sure why yet.
why don't you use sysexin -> thresh?
Oh ok. I suppose it's just the number of times I've run into people suggesting [thresh] is liable to create headaches later down the road that I've tried to avoid using it for awhile.
thresh does the same as
route 240 > zl group / sel 247 to output list.
For very long sysex strings that would be better than thresh.
AH. dude, I should've thought of that. That's fire. Damn.
Thank you so much. :D
Alright, one last thing:
I'm currently using the following logic for deriving the Program Dump request per program change:
My question: Might there be another method that doesn't use [thresh]?
Thanks,
- Aaron
I also received your initial message which you probably deleted.
Program change can't be 13 bytes long.
and it does not start with 176 which is CC# change status byte on midi channel 1.
prophet needs to send bank change which would be I guess
176 32 nn
then program change
192 nn
if you use midiin then simplest way is to insert midiparse
and route needed data.
here sent / received bank change and program change
I don't really understand the midi flow, who is sending program changes,
Max or Prohet itself ?
If it is Prophet , then you receive bank/program, and after that send
dump request from Max.
Repack received data, form sysex string and send it out.
little trouble is that order of that is Bank change first, followed by Pg change.
You need to make sure both current values are sent out.
like this
delay 100 might be too long, but it is a safe value.
---------
How about received sysex dump ?
All ok, or also troubles with that ?
back in the days i have often asked that myself, but in fact [midiformat] already cares for the right "packet size" itself.
you only have to look in the midiout.maxhelp where they send "144, 60, 60" - and you know it is always single bytes what is transferred.
of course splitting things into single bytes is done as late as possible, so that you can not get in trouble with their order.
@SOURCE AUDIO - Yeah, I was talking about the total integer count out of [midiin] on program change messages - I was wrong, it's 17 integers instead of 13.
RE: MIDI flow
1. Max is set to listen for program/ bank change messages issued from Rev2.
2. When a new program is loaded on Rev2, a request is made to dump the corresponding program's param state into Max via SysEx.
RE: [midiparse]
Ah ok, I hear you -- For whatever reason, there had been a bit of latency using [midiparse], but checking it again now, it's seeming fairly responsive.
RE: [del 100]
Apologies if this is a stupid question, but would a potential workaround be to run the bank number (route 32) into the cold inlet of a [pack], with the program change running into the hot inlet, with a [zl rev] following?
RE: "Is all ok with the received dump?"
Yeah, I haven't had issues since you mentioned the start and end points (240/ 247) are suitable filtering agents.
@Roman -- Oh ok, I see. Thanks for the input. I'll check into the midiout helpfile. :)
Thanks all,
- Aaron
pack zl rev - why not, sure.
Could you post that 17 ints program change list from Prophet.
Makes me wonder.
It should need only 5 alltogether.
If you want to try non midiparse approach, then
you would have to use either iter, followed by match,
or ctlin set to listen to bank change and pgm in
to again pack them into dump request.
Alright, here's a couple of lists [thresh] captures out of [midiin]:
Program Change (Bank 1, Program 1):
176 99 32 176 98 94 176 6 0 176 38 0 176 32 0 192 0
CC# change (Noise set to 0):
176 99 0 176 98 14 176 6 0 176 38 0
RE: midiparse
It seems to be working fine for me at the moment, but I'll look into those if it should start to lag again.
Lastly, here's the current logic I'm using for capturing the sysex dump:
If you see anyway that that could be refined, let me know. :)
Thanks so much,
Aaron
of this :
176 99 32 176 98 94 176 6 0 176 38 0 176 32 0 192 0
only last 5 (176 32 0 192 0 ) are bank / program change.
One would need to peek into Prophets midi specs to find out
why are they sent out on program change...
from midi specs
that 4 CC#s are exactly 99 98 6 38
RE: those 4 CC#'s
Ah ok, I see. That makes sense.
RE: your alternative capturing method
AH. -- As [sysexin] is only passing data that was prompted, [route240] is unnecessary. Nice. :)
Next question -- Is there a good way of filtering out the sysex dump running from [midiin]?
I am afraid not.
midiin is listenning to all but real time messages like clock start, stop etc
only dedicated objects like notein, ctlin etc ignore the other kind of messages.
Using midiselect is one option beside midiparse as one can better filter
stuff one wants to use, but at the end it is allways a matter what gets sent to midiin.
You could turn of that NRPN messaging, to reduce data if it is not really necessary