I’ve not noticed anything so far
2 Likes
A new beta. I was hoping this would be a candidate for a regular release but it still does not feel right.
firmware-1.5.11.img.zip (163.3 KB)
as you can see there were a few releases that were not public.
- USB stack improvements. Less issues in general. The large sysexes are still pain. See below…
- bitWidth fix for @shankar
- increased buffer size for @joris.roling
- faster reading of buttons for @studiobischof - pls let me know if you feel a difference
- WIP: support for packet transfers
The firmware was tested with MacOS X only (High Sierra, Catalina, Big Sur M1) and iConnectivity routers. Will test windows and linux tomorrow.
5 Likes
Super! Do you think I can give it a shot in windows or would you prefer to do a check on your side before we started using it in windows?
1 Like
feel free to test it out. Revrting back is safe.
2 Likes
I like 1.5.11 so far! I haven’t tested the bitWidth fix yet. Most likely I will get to it only tomorrow morning my time. One thing I would love to see in the console app is the ability to copy full midi log to clipboard, just like you have the button for the text log. Since I am spending most of my time now on patch dumps, the midi log isn’t helpful since it just shows a few bytes and there isn’t a way to expand the text beyond that. So, I am still using midi-ox to grab the output from the synth.
1 Like
@martin Hej Martin, thanks for the super fast update!
I just tested it and I feel no real difference - the lag between pressing and switching seems the same, even if I try to release the knob immediately.
Maybe I’m more sensible to latency than others because of my drumming background. It’s totally usable 
And I will concentrate on using the touch screen for now where I now hit the controls directly and it also works while resting my hand on the control.
1 Like
Hi @martin,
The SysEx Buffer increase seems to work fine, thank you!
About the WIP: support for packet transfers, is there anything to work with for me? Maybe some preliminary docs?
Cheers 
1 Like
Ok, if you wondered why it was so silent here… here it comes.
When I saw all the feature requests coming in and when I looked at my available time I decided to take a step back and thought about how to resolve it. After having a brief talk with @thetechnobear I decided to give priority to a work that I was originally planning to do in far future.
The lastest firmware (links below) brings Lua scripting language to Electra. it comes in two flavours:
- the Preset Lua extension (Preset Lua extension | Electra One Documentation)
- The standalone Lua (Electra One Lua script | Electra One Documentation)
The Preset Lua extension is the main thing and it is a continuation of the Electra as we know it now. It brings possiblity to extend the declarative preset JSON with function calls and event handling with Lua. I think it is a very powerful combo where you can define the initial preset state with the JSON and use Lua for doing the work that would be hard to describe in JSON. This basically opens the field for customers SysEx parsers, value formatting, MIDI LFOs, Dynamic changes of the preset layout.
I hope this will unblock @andersskibsted and @rhawtin with their bitwig work. Essentially it should make integration with other DAWs easy. And I hope it will also help the @thetechnobear orac integration.
The standalone Lua is goes even further. It requires a special firmware to be loaded.This firmware exposes Electra’s internal API and allows the developers to write their own Electra One application.
Of course, this is the first beta release that brings Lua. So, it is far from perfect. I strongly suggest that only people who are willing to experiment, test, mess around will use it now. I would love if you guys came with the feedback on the API that I suggested and described in the documentation. I am ready to adjust anything so that we will find a perfect match for all of us.
I have also took some time to update the development docs. The SysEx implementation | Electra One Documentation has been updated and quite some stuff was added to Electra’s Github repository repository. Mostly demo scripts. I will keep adding more examples there.
It is worth mentioning that I have decided to release my nightly builds. I did not like the prolonged periods without the releases and feedback. The snapshots of my work will be available on the Downloads page and the there is also a new Change log page.
Last important bit, @akira basically took over the Electra One Console development. I am very thankful for that and the app is already way better than it was so far.
To get the latest beta firmrware, visit Electra One firmware | Electra One Documentation and scroll down do public betas.
To get the latest version of the ElectraOne Console, which is needed to flash the beta firmware, visit Management applications | Electra One Documentation and scroll down for betas.
the changelog of the latest beta is available at Nightly builds | Electra One Documentation
Again, do not expect 100% stable thing. I wanted to make a kick off to get the communication going.
PS: thanks to @shankar for giving it the first test ride and making the very first Electra user application ever 
12 Likes
Yea! (I’m very happy with this 
)
2 Likes
Excellent stuff… will take a look and start to think how I can reorganise things.
one quick thought…
Is it possible to embed some lua within a preset?
(my reading is, that at the moment the lua is sent separately as sysex msg)
it would seem useful to be able to have a preset that contains some custom lua.
(not really needed for Orac though , I can just as easily send the lua after sending the preset)
I guess my intial thoughts are… presumably, I should be able to dynamically create the controls on the E1 itself.
that raises a few questions:
- can I send the lua up as lots of different sysex calls… so as to avoid the sysex size limitation.
e.g. send a few handlers, as different calls.
rather than just one (large!) sysex - sending data to my lua script
is there a way for me to send some data to my lua script, so it can be unpacked to fill data structures?
i guess, a sysex message , that could be unpacked, and interpretted by a callback I supply?
(perhaps I can just use patch.onResponse)
the syex size issue is the show stopper for me at the moment…
I don’t want users having to reconfigure thier hardware/os, but the presets are too big to send up in one go. similarly im concerned the sysex for lua scripts might hit the same issue.
anyway, I’ll have to have a play with the api - see whats possible, and the figure out how I can best use it.
( I think the bit of the puzzle im missing is… I see lots of ways to send data from E1 to device/app , but Im a bit unclear on how I can send non-trival (e.g. cc/note) data to the E1)
really great work, opens up a lot of possibilities for the E1 !
EDIT: side question …
does loading a new lua script essentially reset the lua context?
a concern here, might be the lua namespace get polluted, if you start loading multiple lua scripts/presets,
if its not cleared out, you could get name clashes etc.
EDIT2: epr/lua
I’ve just read your comment about keeping epr/lua separate - which I think is reasonable.
but might mean you end up needing a container which can have both.
i.e. something that says , load this lua, then load this epr.
(Im thinking in terms of how do devs distribute these ‘advanced’ presets using lua functions)
1 Like
The current status is that you use the preset and lua upload sysex message to save both to the same preset slot on electra. The preset then can only use functions from the lua sitting next to it and lua can access objects of that preset only.
That is why I brought that new firmware (as decribed at https://docs.electra.one/developers/lua.html#a-brief-overview). This firmware exposes the low level API. Because the time was limited I included only one generic UI component. I think for the first tests it should be sufficient, The direction I would like to go is to allow users to override the paint method. Thus create their own graphics for the components.
I have this stil in the WIP. There is something that I call a data container. It makes it possible to split any Electra sysex message to number of smaller packets during the transfer. It started as a small addition but has grown bigger because I found that the only way to make it reliable was to add ACK/NAK handshake and checksums. Finishing it is high up on the priority list.
hmm, I like that idea 
@thetechnobear I think, for orac, the stand-alone Lua is more appropriate. That one has callbacks for all MIDI message types.
Currently, it does override existing objects only. I need to find a decent way to clear the context of the script, while keeping the global libs there.
Yes, indeed. The instrument files make it even worse. It all needs to be invented. I will listen carefully
3 Likes
you might want to have a look at norns for this,
they initially loaded everything into the same namespace, and had issues clearing it out.
I think now it loads scripts into a separate namespace, so they can be unloaded (leaving ‘globals’ intact)
(sorry, Its a bit vague, they did this a while ago… so would need to go fish out some more details)
but does that mean the user then can’t use the E1 for loading other preset without having to reflash the E1?
I can’t see many users wanting to do this…
or is this just that a preset is not loaded at all… so the E1 leaves you lua to get on with it.
(the exception being, it allows access to menu screen to load another preset)
having separate firmware implied the former to me…
(But I’ll load up the firmwares tommrow to see what is what )
1 Like
actually, thats probably too hasty…
this is perhaps just a different way at look at the E1, that I just wasn’t expecting/used to …perhaps switching between apps could very much be a new way users will interact with the E1.
I definitely like the idea of having an app that has more control, and can so do something quite different to the ‘midi controller’ app.
1 Like
well, my idea is that one day the firmwares would be stored on the internal storage and you would just pick what you wanted to run… I mean, kind of leaving the world of uploading firmware and replace it with running an application. If you catch my drift…
2 Likes
So excited for this development and so fortunate to have been able to do the test ride and build the first ever standalone app (even though it is just a chaselight toy 
). Moar to come!
1 Like
fair enough, I guess thinking back , my main concern was expending effort ‘converting’ to an app,
and then finding users wouldn’t use because switching back to use the E1 as a midi controller was too much faffing (requireing the computer to reflash)
if in the future, its more like switching to a different kind of preset, then definitely the app route sounds like the right route for me.
having a quite look at the standalone api… some immediate thoughts
- component drawing
this is not going to get me very far , as I see it its not really going to be display parameter values.
really Id like to be able to have some kind of render() callback, then with a limited graphics api (drawtext, fillrect, drawrect , drawline) - then I could render something like a slider - touch/encoders callbacks
it would be useful if there was a way to attach these to a component, otherwise I think pretty much every app is going to having code to map the touch to component.
this should be optional since, its also useful to have these assigned at the ‘canvas’ layer. - window
Im assuming this is like juce, where if I hide a window it will hide (and not call rendering code) of any compoent thats in that window … so we can use this as a ‘paging’ system
note: callbacks would similarly be processed only on active components/windows. - component types
I think the basics are button, slider, option , listbox?
but Im ok, to render these myself (see point 1) - though its likely we will all need these, so may be a bit of code duplication. - documentation
are we able to see the globals , things like TOUCH_POINT_1
(Id be happy to start grok the firmware source if available)
of course, I recognise all of this is ‘leading edge’ stuff, and that you have many other priorities, so its just ideas.
I think really I ‘all I need’ ( ) , is just to be able to render a custom component, and also a really simple graphics api (draw text , rectangles with fill, lines, ability to change colour) - the rest i think I can workaround.
the other thing is being able to upload this LUA in chunks, thus allowing me get around the sysex limitations. ( * )
anyway, I’ll load up the firmware(s) this afternoon and give it all a spin
( * ) also for the ‘standalone app’ side this would be useful anyway, this would allow me to organise my lua code into a set of files, and Id then upload each file … as I cannot just write this ‘app’ as one huge lua script.
this might also help a development process e.g. imagine I put a set of functions in a lua script, during development if I change a function, I only have to reupload that one script - rather than everything.
(we have no way of testing this code outside the E1, so we need a reasonably robust dev workflow for more complex apps)
2 Likes
Hi @thetechnobear, points taken and I think we are thiking in pretty much the same direction. The standalone firmware is at its very early phase, for now the goal was to map at least a few bits of electra’s API to Lua.
My thinking was that the this point the label could be use to display the value. But I see your point now. I think I will add a value property to the component. ie. it will have a label and value. I do not want to go much further at this very moment because I am learning the Lua C++ API as I go. I do not want to run into anything too deep without knowing it is the right thing.
yup the C layer works that way. I need to find the way to hook Lua callbacks or anynymous functions to the components.
yes, eg. Controller firmware preset pages and the Page (etc) selection windows are implemented with the same window objects. For now, the standalone firmware initializes just one window so that the components can be placed there and events triggered.
agreed.
Will add them there.
2 Likes
+1 for the idea, to have several “apps” available, to switch between the core-midi-controller “app” and custom apps. Maybe have slots available.
@martin do you already regret not design a SD Card Slot into the device?
1 Like
I regret not making the SD card accessible from the outside
1 Like
That’s awesome news, so there is enough storage for apps, sequencer data and preferences. That’s good to hear! I feared it’s all on board memory of the controller chip.
1 Like