In the previous post, I did a quick review of the new Vyzex Vortex software program. I also put in some details about the new features in firmware 1.20. I also updated the detailed user guide that I wrote a while ago to reflect the changes in the firmware, (even some undocumented ones).
The main feature in the new firmware is the ability to access and modify the Vortex Patches on a computer. The software (psicraft.com/Vizex)(these guys are pretty funny: there are a few puns in the code and the comments!) is even well done!
Now, because Alesis decided to issue software to let the users program the Vortex from a computer AND store presets on said computer AND retrieve the stored patches from the Vortex, they had to modify the firmware to let the computer access the data (bidirectional). Since the Vortex has a single standard Midi port (5 pin DIN) and it is used for output (from the Vortex) it cannot be used for bidirectional communications. The USB port is used instead. I know that the USB port can be switched to non-midi mode (by pressing C2 and E2flat while powering on, for example…) but generally, the USB port acts as a standard USB Midi port (Core Midi compliant on a Mac). It is detected as such by the computer (and iPad, iPhone). So , when the Vizex software talks to the Vortex, it uses Midi commands. Actually, it uses SysEx commands to exchange information.
Let’s see what the data exchange is:
(I started with the Vortex connected to the computer)(a Mac in this case, but it should work similarly on a PC, although the Vortex is using the standard Windows Midi Port driver that has a bug that prevents sharing a port between two programs. This is why I did all the data
sniffing research on a Mac)
1- When you start the Vizex program, it will send a standard Dump Request (Universal Non-Real Time message type) which is just a short 6 bytes Sysex containing “F0 7E 00 06 01 F7”, also known as a General Midi Device Inquiry. It will send this message on each Midi port defined on the computer waiting a (short) while for a response. Standard midi equipment (if it is polite!) will send a Sysex back identifying itself.
2- The Vortex (with firmware 1.20) reacts (politely) and replies with a 37 byte Sysex messages: “F0 7E 00 06 02 00 00 0E 35 00 19 30 31 32 30 01 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F F7”. Ignore the “F0 7E 00 06 02” (it identifies the string as a Sysex response to a device inquiry). The next part is “00 00 0E” which is the manufacturer ID (“alesis”, of course) followed by “35”. That byte is the ID of the Vortex. The rest is unknown data, but I’m guessing that the “30 31 32 30”, which corresponds to characters 0120, is the firmware version number (confirmed by looking at the string from the previous version of the firmware (0103)).
3- Having found its mate, Vyzex sends “F0 00 00 0E 01 35 63 00 01 01 F7” to the Vortex. This is an 11 byte SysEx that contains the Vortex ID string “00 00 0E 01 35” followed by what I guess is a command to tell the Vortex to send the content of a Patch (“63 00 01”). Patch 01 in this case. That’s the 01 just before the F7, which marks the end of the SysEx string (always).
4- The Vortex complies and sends a nice 127 byte SysEx that starts with “F0 00 00 0E 01 35 61 00 75 01” followed by what I think is every parameter in that patch. The key here is the “01” that follows the “75”. That’s the patch number. So there are 116 bytes used to store the parameters for that patch.
Steps 3 and 4 are repeated 22 times, retrieving each and every Patch stored in the Vortex. Why not 24, since the Vortex has 24 patches? Patch 23 is reserved for the Sonivox Synth software available for the Vortex (free for every buyer) and Patch 24 is reserved for Alesis (in particular to work with Ableton Live).
If you load a set file in Vyzex, it will tell you that the loaded set is not synced with the Vortex. It will ask you if you want to overwrite the vortex with the freshly loaded set (you can also choose to overwrite just one patch). It will then act this way:
1- Vyzex send a 127 byte SysEx command to Vortex. That command starts with “F0 00 00 0E 01 35 61 00 77 01” where the “01” that follows “77” is the Patch number. We can also deduce that “61 00 77” means “write” and that “61 00 75” from step 4 above is “read” (as in “red”) (and also that “63 00 01” is a request to read)
2- Vortex replies with “F0 00 00 0E 00 35 68 00 00 F7” where “68 00 00” means “I just received and stored a Patch successfully”.
Steps one and two are repeated for each bank using a bizarre scenario. Since the Vortex cannot “buffer” incoming data, i.e. read it all and assign it to the appropriate patch, it must receive one patch, store it then receive a program change before it receives the next patch! Actually, when receiving only one patch, the Vyzex will
1- Send a Program Change to select the proper patch
2- Send 127 bytes to store the patch with, you guessed it “F0 00 00 0E 01 35 61 00 77 XX” at the beginning to “write” it
3- receive a 10 byte SysEx (yes, the “F0 00 00 0E 00 35 68 00 00 F7” one)
The Vyzex will then send a couple of Program Change commands, for no obvious reason (to me) except some confused idea about “count from zero/count from one” from the programmer.
Now, what I found while researching this is that Vortex WILL respond to incoming Program Change Midi commands. I had tried that previously (on original firmware 1.03) and while it was supposed to work (according to the Midi Implementation Sheet supplied by Alesis for the Vortex) it did not work. Is that a fix in firmware 1.20? This is very interesting since it will allow me to select a Patch from a software running on my computer, or by pressing a switch on my FCB1010 foot pedal board, for example. Nice.
So, I found how to communicate with the Vortex. Now what?
Well, WHAT is communicated to the Vortex? What is the structure of the Patches? Here’s what I’ve found:
I have accounted for each and every one of the 127 bytes in the Patch SysEx. It’s pretty much what you would expect: definition for every modifiable parameter in the Patch. I also found a few hidden gems. For example, there is a 16 character string stored in the Patch that contains the Patch name defined in Vyzex! So while the Vortex cannot display the string (stuck with a stupid 3 digit numerical display), it is stored…
You want the Patch definition? Just ask. I will not publish it since I know there are some developers out there looking over my shoulder… and it was a lot of work!
Conclusion: A clever programmer could write code to communicate with the Vortex directly from a PC/Mac/Linux workstation. That programmer could also write a simple interface on an iPad… or an iPhone, and use that device to store an load patches without a computer… one programmer could also write some code for an Arduino to display Patch parameters on a remote display… one programmer could even write code for an Arduino to interface directly with a Vortex and an FCB1010…
You must have read my mind. I can select vortex patches using my fcb1010? Whaaaaaat. How.
See the next post: http://practicalusage.com/?p=998
Are there hidden parameters that can be set? Like for the annoying aftertouch kick-in delay?
Every parameter that can be assigned can be from the Vizex interface. Aftertouch, in particular, cannot be modified at all.
I’m interested in getting the Patch Definition for the 127 bytes in the Patch SysEx as well as any additional communication protocol info that you may be willing to share. Please send this info to my private e-mail address.
As per your offer, I’m still interested in getting the Vortex Patch Definition for the 127 bytes in the Patch SysEx as well as any additional communication protocol info that you may be willing to share. I’m guessing that you may have forgotten to send it when I initially requested it back in 2015.
You can send the info to my private e-mail address.
Thanks for all your great articles!