Building on top of the Ambika presets of Bohdan and Martin, I switched the controls to NRPNs to have bidirectional feedback with the Ambika.
I also corrected some parameter ranges and list entries and added the YAM firmware oscillator shapes and filter options. The filter switch is gone, because I only have the lp filter in my hardware unit.
The next logical step would be to get the sysex parameter dump from the Ambika to the Electra but my coding and sysex knowledge is far too limited for this - even with some patch dump tutorials for the electra. If anyone has an Ambika and more knowledge I’m happy to cooperate!
With getting the patch parameters also other parts like the modulation matrix and sequencer would make more sense on the Electra. The NRPNs for that can be found with the IXOS editor too.
Two areas of controls on the Ambika are not recognized by the Patch Editor till now: The Parts section and the Arp/Step section… These require multiple SysEx requests in the Patch Editor which I still have to find out how to implement.
The visual sysex editor currently supports parsing one patch dump response in time currently. I am planning to extend this later on. One of the biggest challenges with that is to make the UI so that it is easy to understand what is happening. My time is still limited, I am finishing a new way of saving projects and work is being done on managing snapshots in the web editor. When these are done, I will most likely return to working on the sysex parser.
I too ran into the “receive multiple sysex dumps” issue. What I see is the device (Modor NF-1) sends 3 small sysex strings (64 bytes, 64 bytes, 45 bytes) and inside the Electra One I receive 32, 32, 45 bytes as 3 separate responses. So it seems that a second incoming sysex start (0xF0) interrupts the first and causes truncation)
My experience (in order to be complete) is different: When the reply apparently is containing more than 256 bytes (without intermediate F0/F7) is seem to run into the same issue. So probably there may be more than one cause to this. For all clarity I’m referring to other synths…
How about this? If we had a patch.onReceiveMulti() which was like the original, but with an additional parameter specifying the number of complete sysex messages to expect.
I am ok with receiving either one large buffer with them all together (since we can find the F0, F7 easily) or an array of buffers with the messages separated.
Or the possibility in the patch editor to say in the midilearn status which chunk or 255 bytes you want to see visualised. The first, the second etc… but also a chunk starting halfway at f.i byte 128 or starting at byte 384 to allow working with overlapping values
I updated my Ambika KEZ Preset with Firmware 3 for the Electra. Now, the actual part data of the Ambika is also read out via multiple SysEx parsings. Thanks, @martin!
Note: I tried to edit the individual sequencer steps of the Ambika via the Electra, but there is a problem, when changing values above 42. It only works correct on the internal sequencer of the Ambika. Maybe this is a bug of the KEZ firmware. But not a big issue anyway.
I think this is the final preset for the Ambika, since everything controllable is explored now
I updated my Ambika YAM Preset because with the YAM Firmware the sequencer can be readout correctly!
There are two mod sequencers and one note sequencer which can now be controlled from the Electra,
You can use the step sequencer 1 and 2 to have parameter changes in the mod matrix, which works better than sending all the changes via Midi to the Ambika. Also trying some odd numbers for the length of each sequence plus note sequences is fun
Hej @martin, yes, the new editor worked great I used the new options to send multiple SysEx to the Ambika and parse multiple SysEx from it. The allocation of the changed bytes to the right controls worked out fast. A huge tool for non programmers!
