Got it.
Electra + mioXL + Mac + Keystep + Pulse + microwave, Auricle was the last hurdle but no more (flw?). Pretty simple despite cable-permutations and manual-diving for breakfast and lunch. So this is a proof-of-concept solution and it looks possible to do exactly what was hoped for. Now for those yet-to-be-made Presets for the rest of the gear… Big thanks to Martin and thetechnobear!
I am sure that MioXL will be a real benefit for your setup.
I’m trying to get up to speed on what can be learned regarding the Electra and how to learn it. Just found “User guide : Editor” (User guide : Editor.html) - is that document current - it appears to be incomplete or broken. In that document are found a few references to either other documents or to sections that were to be found in the same “User guide : Editor” - for example “Writing SysEx templates (file:///tutorials/sysextemplates.html)” it’s clickable but returns an error
( Your file couldn’t be accessed
It may have been moved, edited or deleted.
ERR_FILE_NOT_FOUND)
Is there an all-inclusive table/list of all relevant documentation generated within Electra-world for users/newbies and for experienced users/creators? How about a similar list or table of sources relevant for understanding and developing Electra generated outside Electra-world?
@resyn, where did you find the that link? Isn’t it a saved copy on your computer? file:///tutorials/sysextemplates.html looks strange, it a refers to a file on your file system.
In general, as @markus.schloesser said, all available documentation can be found at https://docs.electra.one/
Not sure exactly where but the html file I found by hitting a link in a document that was/is somewhere on the electra docs or forum site, and hitting that link opened a single html file, which then provided links that didn’t work (of course html files often have a bunch of other files in the same repository, gifs, other html files etc). Anyway I’ll ignore it and stick with the docs-site and the forum-site.
Still have a few questions, one being how I can get help trying to put together Presets for other gear than what the public repository shows now (should I be collecting sysex snippets? which ones? etc), also finding Presets that have existed or were at least being used as examples but are no longer able to be found on the site, such as one for the Waldorf microwave XT, Strymon Big Sky and so on… Where are they now? And I have not found something I thought would be everywhere in the forum = requests from people hoping to find Presets for their favorite gear, or help in developing a preset.
One crucial question (for me) is w regard to patch-request functionality in Presets: is there some reason to expect that this will one day soon be an easy-to-apply addition to any Preset, so that the Patch Request button works with all Presets? While the few Presets that match the few pieces of gear I have at hand are a gas to use, they all exhibit the impossibility of knowing what’s going on in any particular patch that I use the controller to edit.
Am quite used to being able to download a bank of patches (say, on the Matrix 1000) to a computer editor in Mac or PC and choose a patch and begin editing it from known existent parameter values, or even simply requesting patch values for the patch in the particular unit’s current edit-buffer. Very difficult to effectively work blind so to speak. Performance situations are a little different, though even then it would often be good to know what the patch-value is starting from (which cutoff-value for instance).
What are the plans for Patch-Request - will every Preset need extensive or difficult re-working to be able to use this functionality, or is it very easy to do once one knows how to make any particular unit divulge its (patch-values) secrets?
I am in the middle of creating a preset that requests the current patch data from a synth, displays the current values, and allows a user to edit it with the changes being sent back to the synth.
I’ve also done this on other platforms with other tools (Windows, Liine’s Lemur platform, Arduino).
Getting a patch dump, parsing it, and having all the controls map properly can be a very difficult and time-consuming task.
The pain associated with it is directly related to how much system exclusive information is provided by the company and how completely they document their sysex patch dump format and any handshaking needed to request and receive it. even with mostly complete/correct documentation, I’m finding a lot of crazy hurdles and gaps to getting the ElectraOne to match up with what it on the synth’s display.
Unfortunately, even modern gear doesn’t guarantee that a manufacturer will provide (or even implement) that sysex information.
I fully agree that a remote controller/editor is less useful if you don’t know the current values, but for some gear, it may be impossible unless the data is reverse-engineered by someone if the company doesn’t make it public.
So, you can contact manufacturers if the info isn’t public and if it’s really important, you can vote with your wallet and let them know that too.
Of course a good idea to contact the manufacturing company (1) if the company still exists. And even if they do they’re not always willing (2) to go to the trouble to re-source the documentation they have or have had and send it to you. Ensoniq DP/4+ is the type 1 problem, type 2 is maybe Kurzweil, Lexicon - the companies exist though often in a re-constructed form that entails having lost the connection to their own original documentation…
I’ve been hunting through pages and files all over the electra.one (and relevant github) sites I can presently find but have not discovered any material I understand (as a non-programmer) that in detail deals with this particular problem ie how to program a patch-request - wouldn’t have a clue where to start. But even a non-specialist could with rather shallow training perform simpler rote tasks of a programming-related nature that might ease the process along.
Software development history is filled with people/companies creating shortcuts/shells/IDEs to make programming easier for sure.
The ElectraOne community definitely is providing feedback to Martin (and Tomas) about the hardware, underlying OS, and web-based editing environment. A lot of progress has been made and I’m very impressed by it so far.
I do think at this point, a non-programmer type can successfully create a preset to allow editing any device that supports remote editing by CCs or NRPNs. However, given the variety of sysex schemes manufacturers use to save/load patches, you need more than a simple “here’s how to send a patch request” + “here’s how to receive a patch dump” set of commands.
Those commands may be easy to find/implement, but for the foreseeable future, there’s likely to be very little automated/templated/pre-programmed assistance for parsing out the received patch data.
The best bet is to find a template completed for the same company even if it’s a different device because often a company will keep the same general sysex formatting across a range of devices.
The other place to look is other remote controllers (hw and sw) to see if someone else has been able to parse it all out. I’d look at any CTRLR or Lemur templates, Open Source/freeware computer editors, or templates created for the Novation Remote series or Behringer knobby/fader controllers.
It would be awesome to have a funded position for developers to create and distribute presets for all kinds of gear, but even with documentation, having the actual hardware in hand is a necessity to fully complete it.
…which is why I suggested people like me with no apparent programming experience but gear in hand could perform rote documentation tasks, both 1) to locate/assemble sysex documentation sources for units and 2) in accordance with crude but adequate rules to shake (so to speak) the sysex out of those units (to document a unit’s response to orders) - and pass it to people with coding acumen.
So a simple instruction set which could be used by anyone here with an Electra and some MIDI units who also has time and the inclination to assemble and document. To stay systematic we need a “repository” of this documentation and the units already collected, to prevent repetitious efforts.
Maybe “any sysex” sent in qualifies the unit to be on the list, and the collected sysex materials to be accessible for Electra developers. Probably not a simple task to put together a venue (web-page, repo, whatever) for that work - finding a way for developers to get essential input and work performed by end users hungry for a Preset for their favorite MIDI unit.
A partnership can definitely be successful. A device + 2 MIDI cables (or MIDI <–> USB cable) + computer with MIDI-OX (PC) or Sysex Librarian (Mac) loaded can accomplish that initial data query/acquisition task.
Once the process starts, typically there will be disconnects between data transferred and data displayed, so the person w. the hardware has to be willing to be a meticulous beta tester to exercise the preset and report back the successes and failures.
Yet it could be that more than one individual has each specific unit. I would think electra.one would have much to gain in this effort by asking each Electra owner to return a list identifying every MIDI unit they own (or care to see a Preset for).
The system (the platform, the coding, the problem-solving) - there are lots of wrinkles, and once a few of them are more worked-out than today, the number of Preset candidates might well expand beyond expectation…
The biggest hurdle, IMHO is time. It takes time to develop a full preset that pulls down a patch, allows editing and updating. This is especially true if it’s the first one for a particular family of instruments (like a Lexicon processor or Nord synthesizer for example). At this point, I’m about 85 - 90% done with my preset and so far it’s been in excess of 160 actual hands-on-keyboard hours.
To be fair, some of that is due to learning, a maturing platform, and lost work due to various issues, but still that’s a non-trivial amount of time to invest in something that will be public domain. That’s with me being able to have a closed and immediate code/test/fix loop. Adding in a remote person will certainly extend the wall-clock time and likely the coding time too.
A very good points were mentioned here. Here some feedback on that:
There is an idea and a plan to make a visual editor for parsing patch dumps values. I think it will allow non-programmers to create presets that that can read the values from the device. Of course, certain knowledge of MIDI, sysex, and bytes / bits manipulation will be required.
It is important to mention that Electra tries to address this issue (having parameter values in sync) in two different ways. One is Patch parsing, meaning the connected device is the “owner of the values” and Electra reads them to be in sync. The other are the snapshots, where Electra becomes the master that tells the device what the values should be.
Each way has its own pros and cons.
Also, none of the ways is fully implemented. I wish it was but it is not. For me, personally, Electra project is a lot about talking to the users and trying to reflect what they say and combine it with my own ideas. It often might seem that some ideas I forgotten but I keep them on the list 
And hopefully will get done one day,
There are many synths with a very obscure sysex implementation. I can understand that when it is a machine from 80-ties. I do not get that when I am working with something that is manufactured these days (eg, Roland TB3). Lua has been added to Electra to make it possible to handle situations when things are tricky. So, I agree here with Tom, there are things that only a programmer can handle. The forum is here to make the connection between the programmers and the non-programmers
I had a chance to work with many of the users on the forum to get their synths working with Electra. Most often it is about sysex messaging or patch parsing. The reason is obvious, there is much more complexity in it.
What I have learned is that it is not necessary to have the hardware unit next to me. It is important to have the sysex documentation and the samples of sysex messages (requests and patch dumps). Once, I have this (or anybody else), the preset can be created. Having said that, I can imagine adding this somehow to the app.electra.one. I am quite sure that there are many users (including me) who would pick the challenge of making a full-blown preset if sysex messages and docs were available. If I take this event further I can imagine app.electra.one being the communication channel between the hardware unit and the developer. And we have here, of course, the RTP MIDI…
I have many scanned pdfs with sysex implementation. I always liked the idea that Electra website would not only provide the presets but also a well documented MIDI implementation docs for each device.
yes, it is. I had many moments when I said to myself that I am going to work on presets (or better instrument files) only. The problem is that I still feel there is so much that can be done to the firmware and there is so much that @tomas may do in the editor that we stay working in that area. I am hoping that sooner or later we will be able to make Electra our full time and primary job, we are not there yet.
always nice to see a response from you @martin on these topics. You might know the platform well, 
so your opinion matters.
Just one follow-up about having the hardware – in 99% of the cases, I can see having just a full sysex spec would be good enough. In my case, I am in the 1% category (see below)
Personally, I usually find it faster to start from an Init preset and adjust as I want, so in all likelihood, I will end up using Snapshots more than scrolling through presets and then editing. So in that case, there is less to be done to create a working preset for a device.
The other issue as you probably know is – how good is good enough? In reality you might never actually be “done” with a preset. Do I really need to add the ability to pull back all the patch names and present them in a dynamic list (still working on how to do that) so the user can select by name instead of by bank/patch number? No, not really, but I want to try it.
(below)
I have the sysex information for the Ion/Micron (everyone says it is the same and the editor and patch converters I’ve seen believe that to be the case. However, I’ve also created a “Sysex doc Corrections” file to fix the errors in the sysex based on doing multiple patch dumps/sends. Also, I have weird issues where the ordering of the parameter options do not follow in a 0, 1, 2, … n manner and I’ve had to create translation maps so that destination = filter1 on the ElectraOne translates destination = filter1 on the Micron and not destination = LFO 1 rate.
But in general, most people should not run into these weird cases.
From what I gathered over the years using different kind of editors/ librarians and talking to their developers is that a LOT of sysex documentation has a LOT of errors.
I heard this (sysex docs not dependable, or complete) often from the individuals at emagic handling us betatesters for SoundDiver, have heard the same from a couple of individuals developing and supporting their editors on Mac (in one case Mac and iOS). Reverse-engineering makes for more work but might it in the end be sufficient? Haven’t yet done any of this work such as adjusting a parameter on a PCM70 and while that’s being done getting a readout (that can be saved) from some receiver program, and then which are the programs that can be used for this on the Mac? What do the people developing instruments need from us?
This is all fascinating. Does anyone have any logic for prophet 6 to have bi directional communications with Electra? Any way I can get it started?
There is another way to reverse engineer SysEx on some synths.I.e. Some have the ability themselves to send out parameter edit messages.
So far all these messages appear to be exactly the same regardless if they are sent or received, so this helps the reverse engineering a lot.
I discovered that way Korg is using not 2 but 4 different ways of transmitting values over two bytes. No word on that in the manuals.
Typical set-up during reverse engineering is that the E1 and synth talk to each other, but at the same time the keyboard, the synth and the E1’s midi message are being sent to MIdi-Ox without any further transmission. In other words the midi-Ox gives you real time insight in how those 3 devices interact .
Very easy to do with the MioXL.
I plan on making an OB-6 bidirectional preset. But not just now yet.
It’s the same platform as the P6, and I believe a very limited amount of parameters is different between both of them.