Home › Forums › General › Programming › Snapshot save and recall a la Virtual Midi Sliders
- This topic has 10 replies, 3 voices, and was last updated 13 years ago by atom.
-
AuthorPosts
-
April 27, 2011 at 6:55 am #295
For simple cc control I like Virtual Midi Sliders[/url:q1ru43yp] by Wouter van Beek from 2005 a lot, with its nice 5 PAGES concept and also its great SNAPSHOT banks A,B,C,D each with 10 possible snapshots of maximum 5 * 24 sliders and buttons.
There is already a Jomox Airbase-99 slider setup file in the package.
It is for me almost unbelievable how beautiful and useful this tool is, even in its 1.0.0 version, so I can recommend it also to others. As it uses only a simple .exe and .ini file for its settings, you can easily copy this .exe into new directories rename them and use multiple instances of Virtual Midi Sliders in parrallel but each with different settings. In short you can use Virtual Midi Sliders as a GUI for your hardware midi controllers and those nice snapshot save and recall features, all controllable directly via midi.
The reason I post it also here, apart from sharing it with the community, does ctrlr v5 have already such a great snapshot save and recall mechanism where you can also save and load entire snapshot lists for a given device? If not, atom you might have a look to Virtual Midi Sliders as a great reference implementation. It would be interesting trying to recreate the Virtual Midi Sliders concept in ctrlr v5, if possible.
April 27, 2011 at 9:05 am #2331it will be embedded in the Program Manager and it should be the first feature that will come (it’s the simplest one to do).
so definetly YES
April 27, 2011 at 1:18 pm #2332Sounds very interesting! Also the possibility to see in Ctrlr v5 all parameter values/positions of the current program (which is currently loaded in the synth). Then you can change them, save them in Ctrlr and reload this new patches/programs.
April 27, 2011 at 1:46 pm #2333well yes that would be perfect, but you must understand that it is impossible to write such a program without actually having all those devices to test.
program dumps are different on each hardware, sometimes they are different between firmware versions on the same hardware.
April 28, 2011 at 11:29 am #2330OK, I see. With the Virus I already can manage this. The program dumps are in Sysex format – and because all other parameters are Sysex aswell – receiving the dump (in Ctrlr) works perfect.
Tetra’s program dump is also in Sysex format, but the other parameters are sending/receiving NRPN – so the dump isn’t recognised by Ctrlr. Is there any solution/work around to handle this?April 28, 2011 at 11:43 am #2329heh it does not work like that
you send a program dump request the device responds with
a) 99.9% with a large sysex message that you need to decode, parse and translate into parameter values
b) 0.1% with a series of messages, where each one represents a value for a parameter (this does not require any work it’s like someone had move each slider on the synth to it’s position)that’s why i’m trying to implement a stable scripting engine, so that for option a) you can translate this chunk of data to data that ctrlr understands (for example DSI synths pack their
sysex data in a special manner it’s described in the manual you need to unpack the data first to actually use it)April 28, 2011 at 12:09 pm #2328You’re right, my bad. I think the Virus can handle case b) (remember it from reading the manual) – the Tetra "only" can handle case a). There was my mistake. I’m curious about how this will work.
April 28, 2011 at 12:39 pm #2326well in some pseudo code
function receiveProgram(MemoryBlock receivedProgram)
{
processReceivedData() // do whatever is needed here, decode, decompress, shift bitsloop for each modulator in panel
{
match recieved data to the modulator
set the modulator value to those from the received data
}
}[code][code]
function receiveProgram(MemoryBlock receivedProgram)
{
processReceivedData() // do whatever is needed here, decode, decompress, shift bitsloop for each modulator in panel
{
match recieved data to the modulator
set the modulator value to those from the received data
}
}[code]
April 28, 2011 at 12:54 pm #2327Seems to be a lot of work to support a large amount of different synths, if each has it’s own Sysex "code" which has to be decoded and translated individually.
April 28, 2011 at 1:27 pm #2325like i wrote it’s hard and can’t be done in one universal way.
April 29, 2011 at 12:32 pm #2324I can imagine. I’m looking forward to the way how this could work – it’s a powerful feature.
-
AuthorPosts
- The forum ‘Programming’ is closed to new topics and replies.