@jhh, early wip, just to verify it would work for you. sysEx messages with 0x00 0x21 0x45 manufacturer id, ie. electra one, should be recognized on all USB ports. I will extend that to MIDI IO DINs too - I think @markus.schloesser asked about that ages ago.
firmware-2.1.8a.img.zip (274.0 KB)
Thanks! Will try tonight, no access to my E1 now 
Thanks will try too.
@jhh maybe its to early. But I was thinking that all presets could have a similar template page.
On this page we could then create the part of the template to control Ableton, which you use to switch the environment, to mixer/arranger, add devices, browser presets. mix etc.
Are you Dutch? Active of Synthforum.nl? I asked there if there are more people interested in working on the script.
I have tried with the new 2.18 firmware and it works great so far.
Yes Iâm Dutch but not active on synthforum.nl. Nice to hear the new firmware works! Not sure what you mean with your idea of a template page. Do you mean to add some pages to control the mixer as well and one with say push buttons to change the currently active device/track/etcâŚ?
yes that is exactly what I mean.
Curious what @martin has in regards to changing the way the fader is displayed.
Anyhow I see many controls are 14bit ccâs but are mapped to floating point.
or for example dry/wet which is 0 to 100% but ranges from 0.1 to 100.
It would not be useful to see the raw 14bit cc I think.
Like âcompressorâ âthresholdâ in âdbâ " â- inf dbâ to â6.00 dbâ
I mean it would be nice to see the values, looking at my Zero SL MKII it is able to display everything in 10 chars.
Would it help if I start to collect parameter, names, cc resolution and display values?
I mean before customizing we might be able to come up with some logic to automatically detect the âdata typeâ is a musical sense for some of the common parameters.
Yes more intelligent choice of value representation is on the top of my feature list. Note that by manually customising the patch generated (and adding it to Devices.py) gives you the most fine grained control (and is more or less necessary anyway for larger devices where Ableton doesnât give the list of parameters in a useful order).
For dumping info about parameters you could use
P.S. I have a Zero SL Mk II as well, so know exactly what you mean. Problem is, that in order to do that you need to transport the value Ableton reports as a string (ie NOT the MIDI CC value but âp.str_for_value(p.value)â where p is a Parameter type) to the E1, probably using a SysEx command like â control updateâ (see SysEx implementation | Electra One Documentation), but that one does NOT accept a value to update, unfortunately. @martin this looks like another feature request
Regarding your other feature request: it seems to make more sense to create separate PRESETS (not PAGES) for mixer control (and yet another preset for pads): then they can be assigned separate MIDI channels, which means we have more MIDI CCs at our disposal. And it would be easier to create/manage/edit their layout independent from other devices. Would you agree?
But that would mean that when uploading a preset, one can specify which slot it will be stored in (instead of the currently selected one, as is now the only option); cc @martin
Well I was just thinking to just add some default buttons that will be present in all presets.
If I understand it correctly, the preset can have multiple device definitions and corresponding midi channels.
Yeah I agree its a good approach to create separate presets.
Canât we use list overlays of the values that Ableton reports?
Perhaps they can be created by a lua function. or the Lua formatter?
Is Ableton reporting the range of these values as well?
Thanks @Martin I can confirm this works. However, it seems that after uploading a new preset, the E1 ignores incoming value updates sent as MIDI CC immediately after the upload. Is this correct? If so, what is a safe timeout to wait before sending value updates?
Ah you are right, a preset can define more than one device, and your an assign each control to a different device. But for a more general approach I feel a separate preset is cleaner (also because then I donât need any code to split/merge json in the remote script
I use list overlays for enumerated values, but donât see how I could use them for continuous ones. For a parameter p, the Live API gives acces to p.min, p.value and p.max (as floats) and p.str_for_value(v) for any value (eg p.value) gives the string representation also shown in the Live UI. E.g. for Analog, you would get (listing the string first and real value after that in parentheses)
Volume (Volume):
Min: -inf dB (0.0)
Cur: -6.0 dB (0.5006348490715027)
Max: 6.0 dB (1.0)
Semitone (Semitone):
Min: -12 st (-12.0)
Cur: 0 st (0.0)
Max: 12 st (12.0)
Key Stretch (Key Stretch):
Min: -100 % (0.0)
Cur: 0 % (0.5)
Max: 100 % (1.0)
Unison Delay (Unison Delay):
Min: 0 ms (0.0)
Cur: 0 ms (0.0)
Max: 100 ms (1.0)
Because Ableton (of course knows what each parameter means these string representations are the most reliable and user friendly way to display values also on the E1. But like I said, that seems to require yet another firmware update (and some extra code in the remote script because it then needs to respond to value changes within Ableton too; so far I havenât figures out how to do that, because so far I didnât need to as Ableton automatically sends a MIDI CC value update whenever an assigned parameter is changed through the UI, or even when another remote controller changes it!)
Just a quick response on this one (I will read other stuff carefully tonight).
Electra needs to parse and convert preset JSON data after it is received. During the transfer and parsing of the preset, MIDI processing is suspended. The reason is that until the moment that the preset is ready to use incoming MIDI data could not be applied anyways. The time needed for that depends on complexity of the preset. I would expect up to 1 sec for very complex presets - I mean this type of presets that @NewIgnis develops 
Page switches are different in this, they were designed not to interrupt or delay MIDI processing in any way. So my suggestion would be to use page switching instead of presets uploads and use devices to cover all required MIDI channels. Adding a SysEx command for switching pages to firmware should be fairly easy.
Thanks, Iâve already updated the code to implement such a delay.
Iâll have to think about page vs preset switching a bit more: I see benefits, but also pitfalls
You can modify the order for vstplugins by clicking âconfigureâ and then reordering them, that will also change the representation order over the the api.
For M4l devices, you can open them, click on parameters and use the first column (â#â) the give parameters the order that you want. (something a lot of devs donât know about)
For internal live devices there is a py file called best of banks or similar (on phone canât remember correctly), in which the parameter order is stored. This can be edited as well. In fact thereâs a larger thread about this in abletons forums
Hi Markus, thanks for the hint on how to order parameters for M4L devices: Iâd seen that before, but forgot about it (although modifying M4L devices is too much for most users I guess). Preferably the remote script âdoes-the-right-thingâ automatically. I have seen the âBest of Banksâ definitions and will think about how to best integrate them. Modifying M4L
BTW: do you know a reliable way to get the name of a M4L Device (e.g.âCV LFOâ or âVector Delayâ) as shown in the device browser through the LiveAPI? (device.name is the name of the currently selected patch for the device, and device.class_display_name is too generic âMax Audio Deviceâ or âMxâŚâ)
That is great good idea to order the parameters in the vstâs.
But it still isnât a solution for the templates although it will make live much easier.
The philosophy is that it should work out of the box.
It is a good thing you can really customize the presets as well.
Tempering is conf files in Ableton anyhow sucks as after an update you can do it again.
Thinking about performance.
What if the e.one remote script
@martin can we have that the row selection buttons allow to scroll to rows and pages?
so if your on page 1 on the top row, if you select the bottom button you jump to the middle row if you select it again you go to the bottom row.
If you select the bottom button again you jump to page 2.
And the other way around. This will be a huge workflow improvement.
The middle button can server any other function. Ideally a mute function for kids 
I
I would no the in favour of changing something as fundamental as the button assignments; even after a few days they are already in MY muscle memory. (Although, owning a Zero SL Mk II myself I see where this request is coming from
I am talking about the 3 row selection buttons on the left of the e.one screen.
Scrolling to the pages as well as rows will work much faster then opening the page selection screen then select the page you want on the touch screen.
Adding this feature does not have to change in any other way the current behaviour.
Currently:
[row 1 button] select top row
[row 2 button] select middle row
[row 3 button] select bottom row
Idea
[row 1 button] select top row, select it again scroll back 1 page
[row 2 button] select middle row
[row 3 button] select bottom row, select it again scroll forward 1 page
Ah, apologies, I misunderstood your proposal. This actually makes sense!