Hi,
Do you maybe have/use a command line Preset File upload tool? It would very much help me in my development of these when not using the Web Editor (e.g. doing the Patch request & response + rules).
If you have not, no problem, will make my own (using you documentation).
I am using sendmidi. But of course there is a bit of overhead work. I was thinking about making a small suite of command line tools that would allow elementary operations such as:
it means kind of shell commands…
But as it is not real main line of development, it did not get the time slot. If you were up to picking that challange it would be great. If you were willing to make it opensource on github, I would be the happiest person around 
Yep, no problem, will do so.
Great. Thanks Joris! Btw I use JUCE, brilliant cross plaform framework. The advantage of being able to compile the same source code on mac, win, linux is simply killing. But it is just a recommendation
For the command line tool, I’ll be using NodeJS, with a cross-platform module for MIDI.
(upload part almost done: repo will be here:
Could you (very briefly) describe the ‘list preset’, ‘move preset’ & ‘remove preset’ SysEx spec?
These calls need to be added to the firmware. Not a rocket science. Will provide the info as soon as it is implemented.
btw. regarding the instrument files - I am editing the JSON schema right now. Will make it available later today. I am almost done.
Hi @martin,
The upload command in my repo works in principle, but not practically. The problem seems to be my tech stack, as very small Preset Files (sub 32KB) work, but bigger files are truncated, and the console will not accept it (of course).
And although the problem (here) is on my side of things, it got me thinking about very long SysEx messages could become a problem in many more scenarios, including hardware that does routing, like the MRCC (you mentioned it might have SysEx issues, I just asked ConductiveLabs on their forums).
I’ve had my own experiences with iConnectMIDI4+ hardware, and I’ve seen more comments here on the forum of people having issues with uploading large Preset Files. Hitting 10+ times on the yellow “SEND TO ELECTRA” button is no exception in my experience. (I must confess, this was with the v1.5.7 firmware, which is actually still in beta, so should not be blamed as such). But even now that I have the Electra One connected directly to my Mac, I need 2-4 times pressing the “SEND TO ELECTRA” before it is accepted by the console.
So anyway, maybe an alternative way of SysEx uploading might be something that users suffering this phenomenon might benefit from: chunking the Preset File, and upload the preset (as an alternative to the current way) though many SysEx messages. I know for a fact that the (infamous) Behringer BCR2000 (very robust kinda ancestor to the Electra One) does its preset uploads (which are also in fact text files) in chunks. Very simple protocol, but because of the smaller (sub 32K) chunks, hardware has much better opportunity to deal with the data. I’m pretty sure some of the less sophisticated hardware MIDI routers do simply limit the size of SysEx, and I think it is understandable.
Sorry, long story…
TL;DR
Would you be willing to implement an alternative to the current upload mechanism through SysEx (‘all-in-one-go’), which would allow for chunked uploads?
I discussed this with @thetechnobear last week. It seems to be the only reliable way to go if the transfers should be stable and reliable on all platforms and hardware.
There are two things to be done and these two things can be done in parallel as they are independent:
Anyways, I am totaly up to this. I was hoping to make sure that large data transfers over the MIDI would be reliable but it seems to be close to impossible. A bit funny because I can transfer 600kB+ firmware on the low level HID no problem - but I have control over every single packet there.
Ah, that is good. We are on the same page here, nice!
I just got confirmed by ConductiveLabs (here) that the MRCC will allow SysEx up to 4K, so your ‘well-under-4k’ seems to fit with that too.
Just a quick update on this.
I gave it a bit of thinking yesterday and made a draft of the idea on how to implement it. I will extend Electra’s SysEx protocol with Request and Transfer wrapper calls. These calls will allow transmission of any Electra’s SysEx message as the payload and will take care of the splitting such message to packets during the transfer and will allow assembly on the “other side”. The client will have control over the packet size and packets will have checksum. I am considering an optional ACK, NAK, WAIT, CANCEL scheme. But definitely not in the first iteration. Note, it will be still possible to send and receive the full SysEx messages - just by not placing them to the wrapper calls.
I decided for this scheme, because I would like to keep the format of Presest, Snapshots, Configs, and any other future objects clear and deal the packets on the “transport” layer.
I wrote a simple client yesterday. Will try to get it in the beta firmware tonight / tomorow. Once both sides are covered, I will put that in a public github repo.
I am open to any types of suggestions and modifications. As this is still in beta, things can be changed easily.
Very clever, I like it. Seems like a good generic solution.
Cool , I think this is the best approach - for dealing with large presets.
However, we still need ability to update parts of a preset, to allow for more ‘dynamic applications’ … as it’s pretty slow to send large presets in my experience.
Yes, that is part of the plan too. I see this as a separate functionality though. I already tested the crud model on snapshots. ie. they can be created, updated, and deleted individualy. The same model will be applied to controls. The idea is that there are sysex commands to create object, update it, and remove. These commands take an object type as a parameter and number of other parameters based on the command.
It works perfectly for snapshots. It is possible to update and move snapshots in the console and these changes are immediately reflected on the controlller as well as changes made on the controller are immediately synced to the console app. The calls always carry only information required for the individual object.
Doing the same for controls is perfectly doable. The only extra complexity is caused by the storage of controls in RAM. Current way of loading whole preset makes it very easy. I simply clear the RAM before loading the preset. Then I build the objects in the memory one by one nicely alligned to use all available space. Adding the updates and deletes will introduce fragmentation. Will have to add some sort of memory management to keep free RAM usable.
This work will be definitely divided into more steps. In the first iterations I will make it possible to update specific attributes of the controls (label, colour, location, visibility), ie. things that do not affect memory. The more complex stuff will come later.
That would be great, awesome! 
Thank you for the summary! Just ran into the same issue - I can transfer e.g. the Microwave XT preset from the public library, which is >120kB in one sysex message, allright using the Chrome app. But when I try to send the same message via JUCE app I have written or even via Midi-Ox, the Electra One will always display Preset Transfer failed, please retry.
I even looked at the Chromium source code of the WebMidi implementation, but they don’t do anything different than the JUCE Midi code, calling midiOutLongMsg of the Windows API, so I have absolutely no clue why it would work in Chrome and not in JUCE.
Anyway, splitting preset transfer into smaller chunks certainly will make less headache in the future.
@martin Just wondering did this every make it into production? The sysex documentation does not state it, unless I overlooked something. I still have the same problem when trying to send large presets into the device.
