Another minor UX thing: When scrolling and pointing to the bit on the right, the scrollbar appears and you have to wait or fiddle to edit. Can move the bar more to the right?
1 Like
FYI : I’m not having this scroll bar issue on Windows 10 PC. But I’d would prefer a little space at the right side of the bits as well.
Two UX update requests:
The way to assign a series of bits to a control can it be done as follows:
- click on the first bit
- then shift click on the last bit (in the same byte)
Right now, if I need all 8 bits , I have to click them one by one in the right order. Would be nice to get this sped up
In the left control column can you add extra filters, not only for the name, but also for:
- page name (same behaviour as with control name)
- category (same behaviour as with control name)
- parameter number (with wild cards: type 6* to get al params starting with 6)
1 Like
Hej @martin
I have finished my two synth presets (Ambika and Shruthi) as far as I can get with the editor - it worked really well - even the whole mod matrix 
Two areas of controls on the Ambika are not recognized by the Patch Editor: The Parts section and the Arp/Step section…
The patch editor just doesn’t recognize anything while changing values… Normal NRPN knob feedback works. Here are some screenshot of the controls from the IXOS software editor:
It’s not a big deal for me, but it would be nice to complete the preset. If you are interested, we can investigate further and I can read out some SysEx dumps. The IXOS editor reads out the controls via patch request.
Update: I just found out, that I need to send additional SysEx requests for these values… but I had no luck till now to get it to work.
1 Like
Hi @martin ,
last part of the patch parsing tool investigation:
I made a preset for the Korg DS-8, for which I knew how to trigger a patch request, but the patch request itself and the parameter changes were undocumented.Would the parsing tool be of help?
The answer : YES !
The other way round (figuring out the parameter changes, which the DS8 receives but doesn’t transmit), was done with a set of controls : one that set the byte to address, the other one to set the value. With the DS-8 that was kind of easy as the display changes accordingly to the value you try to change. I’ve also tried to go outside the usual values, hoping to discover some of the Yamaha 4-OP traits that are typical for the used sound chip, but this was not possible. Korg did a good job hiding the interior workings of the chip. I found no means to tweak other controls that the ones on the synth itself.
A tool like Midi-OX remains invaluable to monitor midi behaviour outside of the E1 and to investigate a synth’s MIDI quirks. And the DS-8 has them 
Keep up the good work!
1 Like
So much great stuff has been done here by Martin and the other forum members. I’ve been completely slammed at home and work and barely have time to power up some gear, let alone work on my presets in progress or start something new.
I’m hoping that by the beginning of February I can jump back in and start exercising some of this cool stuff. The customer support and forum member contributions here have been so far above and beyond what I’ve experienced with any other piece of hardware. It blows my mind to see how far and how quickly this device has evolved.
Just wanted to give a general “thumb’s up” to all here.
6 Likes
Working on my third synth with patch parsing. An old Matrix 1000 with the Tauntek version on it, and with almost complete , but somewhat inaccurate SysEx documentation.
I found I new challenge; Martin. The patch dump from the Oberheim Matrix 1000 is sent in two pieces, one of 256 bytes, and a second of 19 Bytes.
As a result, with the Patch Editor in MIDI-learn, you see the message appear and then immediately disappear…
The trick to get it : after requesting the patch, you need to disable the MIDI-learn in the fraction of a second between the first part is shown and before the second part is processed. Takes a bit of exercise but doable.
However it also means it won’t be possible to investigate/assign controls to that second part via the ‘Responses’ screen, as that part is never shown . But with only 19 bytes that can be done in json with the help of Midi-Ox.
It will be harder to deal with patch dumps that are more than a 1000 bytes long (Yamaha TG77 for instance). I think it would be a good idea as well to be able to browse through all message bytes per 64 of 128 bytes when ealing with long answers.
1 Like
I got all excited for nothing, the DSI Evolver uses a packed data format for its dump…
"Data is packed in 8 byte “packets”, with the MS bit stripped from 7 parameter bytes, and packed into an eighth byte, which is sent at the start of the 8 byte packet."
1 Like
That is perfectly ok and the patch editor will allow you to map the parameters no problem. I made a preset for DSI Mopho - It uses the packed data format too, I think the majority of DSI synths use that format.
Same for Korg I think
and Alesis (at least the Micron/Ion synths)
Some new experiences on the patch parsing tool, learned while doing the SE-02 preset:
- When a preset consists of multiple requests, the middle pane in the patch editor ‘responses’ tab only shows the assignment of the control when you by accident are looking at the responses for the right request. Not impossible to deal with, but it slightly defies the purpose.
- The "what-is -different " indications in the right pane are not correct when there are multipe responses. I think the comparison algo is comparing to the last received response, instead of the last respons of the same request. For this parsing exercise I’m using screenshots do to the compare.
- For this particular synth (see the thread about the SE-02 preset) I’m in need of a formula to change the values between how the SysEx transmits lists (typical 0,1,2…8 max) and how their corresponding CC’s transmit them (typically spread over a 0…127 range)
1 Like
I think I now have the same problem(s) of disappearing editor results with a new request for the Ambika Patch dump…
I realized that the missing parts of my patch dump are due to extra sysex requests for these parts:
I replaced command 17 with 19 which sends back two parts and none of the results stay in the editor.
If I send two different requests with command 18 first and then command 17 some results stay but before that the numbers change multiple times in the editor… I’m still too much of a beginner to understand where to solve this riddle for now (i.e. sending command 19 first and the 17 shows both editor responses empty).
Also @martin I found a bug: In “Requests” when I want to delete my second request via the trash icon it deleted its content but not the request tab itself in the list. It is also still available in the list under “Responses”.
I think I have hit another issue/confusion which threw me off for a day when I came back to this.
When I have enabled “Midi learn” in the response tab then when I change a value on the Yamaha SY85 it sends out it’s editing Sysex and the sysex message is changed messing up the parsing steps. (SY85 is directly connected to the Electra One via Midi Out 1 and Midi In 1)
So for me the procedure is
Select ‘Preset Parameter’ → press clear message → enable midi learn → request patch from electra one controller → disable midi learn → change value on synth → enable midi learn again → request patch from electra one controller → disable midi learn again → assign bits to parsing rule to parameter.
To me this seems a bit redundant? Or am I missing something? (Genuine question )
So it’s about the “enable midi learn → request patch from controller → disable midi learn” part because else any change on the synth will mess up the marked bits.
It’s always the same action between grabbing the mouse and controller and mouse again, so what if…the editor app could initiate the patch request. Then it knows when to expect data and what to do with it and can ignore anything in between. To me it already feels a bit weird I have to request a patch from the controller while I am editing the the preset in the browser.
Edit: other than that it works fine. It beats my previous way of working of generating sysex parsing by creating json arrays from a python script from a supersimplified midi data list csv which I created from the SY85 sysex PDF and copying it manually into the json screen… 
Also: a lot of the times it seems all 1’s in the sysex screen are highlighted green (green circle with while outline and white 1 inside). Does that have special meaning? (not a single 0 is highlighted at that time)
Edit 2: I know realized that you can also work “without the magic” if you have the sysex data sheet next to it. If you know which bytes belong to which parameter you can assign stuff really fast
About the enable/disable midi learn thing - I leave it enabled all the time till I got all parameters allocated. Even clear message is not necessary with most parameters lining up in the next SysEx bytes ahead…
But I see your problem with the SysEx send back with every value change… Maybe you can set the SysEx header of the editor in a way that the Electra ignores this SysEx knob feedback or you can switch off SysEx out on the synth?
1 Like
I first ensure the E1 can control the parameters of the synth.
Once that done and you have the sysex implementation, then I typically do 8 to 10 parameters at a time in the patch parsing, with the midilearn disabled. Then I set those new parsing parameters on the E1 in an easy to remember sequential order (something like 10, 20, 30, 40…) then enable midilearn and request the patch. These rather arbitrary parameter values usually make the sound horrible but checking the correctness on the Patch Editor and one the E1 (the set values should not change) easier.
1 Like
A sysex tweak It is different (already one the 3rd byte of the message) from a patch request but I have no Idea how to set it to ignore those…
I tried creating a separate header for the param changes and hoped the editor would recognise it and ignore the “sysex parameter changes” from the synth, but it does not seem to do so. (At least not when midi learn is enabled)
I did however find a new way of inspecting how bits are distributed for example for a parameter that has a range of -127 to 127 (devided over two 7 bit values but synth manual does not say how). With my new “parameter change from synth header” enabled I can wiggle the knobs on the synth from min to max and exactly see when the signed-bit comes into play. To it works as a real time monitor
1 Like
Always a riddle these SysEx messages 
Good luck with your preset!
1 Like
I had some time with the Electra and Ambika again and took a look at the SysEx command for the part and sequencer data…
The problem is that the Ambika sends multiple SysEx dumps for one command to the Electra:
- Patch Dump
- Part1 Dump
- Part2 Dump
- …
- Part6 Dump
- Seq Dump
It seems not possible for now to handle more than one dump per command via the Patch Editor. As I’m not into LUA this functionality has to wait…
1 Like
I’m having similar issues on other synths, for which I can’t set the parsing:
- The Moog Subseqeµuent 37 (probably theSubsequent 37 CV and the Sub 37 as well then):
Sysex message to parse not being shown in patch editor. Can anyone help? - The Sequential OB-6 (probably the P-8 as well ):
https://forum.electra.one/t/dump-request-values-not-received-or-when-correctly-received-not-well-represented/13193
1 Like