Snapshot save and recall a la Virtual Midi Sliders

[TonE]

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.

[atom]

it 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

[minimalist]

Sounds 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.

[atom]

well 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.

[minimalist]

OK, 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?

[atom]

heh 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)

[minimalist]

You’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.

[atom]

well in some pseudo code

function receiveProgram(MemoryBlock receivedProgram)
{
processReceivedData() // do whatever is needed here, decode, decompress, shift bits

loop 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 bits

loop for each modulator in panel
{
match recieved data to the modulator
set the modulator value to those from the received data
}
}

[code]

[minimalist]

Seems 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.

[atom]

like i wrote it’s hard and can’t be done in one universal way.

[minimalist]

I can imagine. I’m looking forward to the way how this could work – it’s a powerful feature.

[Author]

Posts