sysex MTS message to tune a REV2 synth
Hello,
Basically, with a list of 128 frequencies, one for each midi key, I would like to tune my prophet REV2 using Midi tuning specification standard (MTS).
I understand that I have to send "sysex" messages, through the "midiout"object.
but really I can't figure out how to "translate" my list of frequency in sysex.
I guess I'll have to use sxformat or something? ...
http://technogems.blogspot.com/2018/07/using-midi-tuning-specification-mts.html
I could find someone that explain how to do that for supercollider.
But I need to use max.
Would any one be able to help me somehow with that?
I understood that I have to translate each frequency to the closest midi lowest midi note, and then the deviation in cent in represented with 2 pair of hexadecimal value ...
I guess I'm lacking some basic computer knowledge to understand what a bit, bytes, hexadecimal, checksum etc... means.
So it's very difficult for me to do the math....
Any help would be really useful!
thank you
sxformat sounds like the way to go. Have you got the midi spec for the REV2 as that should tell you what the format of the sysex messages needs to be.
Unfortunately, (or at least unless I'm missing something) sysxformat requires all the message bytes to be in decimal format whereas most midi configuration data sheets list things in hex or binary. If I can find a copy of the midi spec somewhere, I'll try to help you out.
This is an example from my project where my X-Touch mixing desk requires sysex messages to configure the illuminated scribble strips:
To answer part of your question:
Bit: a single binary entity, either 0 or 1.
Byte: a collection of bits. Although there were several older systems out there, the modern standard is that a byte consists of 8 bits. (A byte with 4 bits used to be referred to as a nybble or nibble!) Usually, all 8 bits are accessible to give decimal vales from 0 to 255 (hexadecimal $00 to $FF). However, some of the older MIDI devices only used 7 of the 8 bits to give data values from 0 to 127 (hexadecimal $00 to $7F). The eighth bit was sometimes used for a byte checksum but mainly differentiated data values (0 to 127, $00 to $7F) from commands (128 to 255, $80 to $FF).
Word: a collection of bytes. 16bit words use two bytes, 24bit words use three bytes, 32bit words use four bytes and 64bit words use 8 bytes.
Decimal: normal number notation, 0 - 9, base 10.
Hexadecimal: a binary representation of 4 bit nibbles, $0 - $F, base 16. That means that each nibble can have values as follows: $0 $1 $2 $3 ... ... $9 $A $B $C $E $F for the equivalent decimal values of 0 to 15. 8-bit Hexadecimal bytes (two 4bit nibbles) therefore range from $00 to $FF (or 0 to 255).
Checksum: an extra bit, byte or word added on to the end of a message that is effectively all the data values added together and then lopped off to the size of the checksum. It was used in the days of slow, asynchronous serial interfaces (MIDI included) as a quick way to ensure that all the data values in a message had been received correctly. Checksums were needed on older devices but new kit doesn't use them much anymore as the interfaces are more reliable and there are better ways to ensure data integrity.
thank you very much! I'll have a closer look later. In the mean time, here are the specification for this "MTS" thing... It's pretty clear I guess, but still far to have it work. I need to transform my frequencies in 3 bytes: closest lower midi note, deviation in cent * 2^14 in the 2 other byte... but then how do I create a bulk sysex message with this huge list of datas? (3 * 128) . It doesn't seem that a sxformat takes lists...
You have to put all the individual sysex data bytes into the sxformat message although you can use up to 9 wildcards and a few other expressions and use separate inputs to replace them. Beyond that, there is no limit as to how long sysex messages can be. Unfortunately, as you say, sxformat doesn't accept lists as such - it can only accept the values in a list to replace all the $ix wildcards in the object, of which there can only be a maximum of 9!:
Depending on how the implementation is defined, it could be a tad tedious!
Ok thank you very much for your explanation, it's much clearer now. So as I understand I need to translate each frequency into 3 bytes. Each byte containing a number 0 ... 127 because each byte is 7 bit. 1rst byte: the closest lower midi note. Then the 2 other bytes tells the cent deviation up to the this note. so I guess 128^2 possibilities? So I guess I need to multiply my deviation in cent by this number to got my cent deviation "rescaled", from 0.....100 to 0.... 128^2= 16384?
Then I need to make a "bit marking operation " apparently... so $i1>>7 and $i1 & 127. I don't understand that, but ok. Then it's give me The 2 bytes I needed.
I’m out and about today so no computer to hand but you might want to read up about ftom, which you could use to find the nearest MIDI note value to a specific frequency, % (mod division) that you can use to extract byte values from larger integers, and possibly some of the Boolean and bitwise operators (search for the Object Thesaurus in the documentation where they are all listed together).
So...
Here is the form of the message to send to the rev-2 in order to have a proper bulk message send with 128 frequencies, one for each midi-key.
240 126 0 8 1 [one integer between 1 and 16 for the tuning program] [ list of frequencies in the form of 3 -7 bits- bytes words, so 3 * 128 ints = 384 bytes ] [one checksum byte (XOR of each bytes Except first (240) and last (247)) ] 247
I don’t think the checksum byte is mandatory (it works without), put I prefer to put it anyway….
The list should be send with a midiout, with or without iteration… both seems to works fine.
Here is the patch attached!!
thank you for your help Andy!
Rats! I wrote you a long reply and then closed the window before posting it! Grrrr!
Anyway, it looks like you've done a great job there so far! My only advice would be to use a coll, bag, table or funbuff object to store the tuning values in and then process them from there. That way you could create any number of tuning tables and then generate the required sysex message using a single process. I prefer coll as you can open the data in an editing window as well as load, edit, manipulate and send the data using code. coll also maintains a copy of your valuable data on disk by default.
thanks Andy! well actually I have been develloping my own tuning device that outputs 128 frequencies . I put it attached, if anyone is interested: it's to tune in just intonation, one octave, then the rest is automatically "transposed".
To have it work you need "ppooll" (ll.lline object) and "Bach" (ratnum object) packages. But yes Coll is really practical too if I needed!
You’re making excellent progress!