Solvable, but not an easy task, It’ll need renaming functions and variables in most cases and perhaps accepting a few suboptimal situations along the route. But the idea would be awesome.
1 Like
no, please do not do anything! 
Editor and the controller must do that on the background. Functions and variables must be placed to a separate namespace / context. Users should not do anything special about that.
1 Like
You could do something like auto-decorating the LUA functions as part of the import.
A simple letters+numbers prepended to the name might be sufficient
1 Like
yes. I am looking at Lua environments (Programming in Lua : 14). I could use it either for decorating or create a separate environment for each instrument.
I took a quick read through that section. After reading, I am concluding that the function names are the easy part.
I know that I will often need some global variables to keep track of things like the number of times a timer or transport function was called or a button toggling between different states or global arrays of lookup values to make processing quicker.
Renaming all those globals plus all the references to them in an automated fashion might become a challenge, especially with some of the internal names currently in use.
I don’t necessarily think it is an overwhelming burden to ask the original preset developers to do some cleanup if they want their code to become part of the set of instrument files. At least the original developer will know what needs changing and can in theory re-test as well.
It might take more time, but again, once one or two of us goes through that process, suggestions on a faster workflow can be made.
2 Likes
I just tried to see what really is in the env:
for n in pairs(_G) do print(n) end
added it to your Looperlative preset. I can see all your global variables are there, too. There are also other global objects, such as library names, constants, etc. So, the job here seems to be more about filtering these out.
That was on my ‘to-do’ list for the weekend - trying to see what was in the global space for each of my presets.
The Looperlative preset is in some ways an anomaly. It doesn’t do any sysex processing and is all about manipulating the Electra One environment and controls in real time to provide visual feedback while you work. One thing I wanted was that every time I had a control dedicated to a track, I wanted its state (empty/playing/recording/…) to be reflected across all controls/pages. There is also a lot of function re-use and the need to track state across multiple functions/pages and the most convenient way I found to do that was through various global values and arrays.
I imagine you pretty much viewed a “worst case” preset.
Will there be a chance to redo how devices are managed in the editor/electra?
I’ve been thinking about it today and this is how I see the relationship:
If we consider that a studio is set up with instruments and that the connections to the instruments, which are the (midi) devices and that those generally don’t change much, then the preset wouldn’t have anything device specific in it.
You could make the device part of the instrument as well, but I’d love to get code and config separated so that you could get preset or instrument updates without needing to customize them for your setup.
It would also make the whole setup more straightforward because you would logically setup of the instruments in your studio and their connections and then include them in presets.
I am imagining containers for these separate things in the editor and on device, but I realize that the device might not be able to handle this. But since the device really only works through the editor, you could process “preset” payload together before delivery and have the editor organized differently without adding much overhead on the device. You mentioned the lua issues and I also wonder about sysex mapping and how would you have multiple instruments in the same preset on v1 hardware that are able to keep up to date with patch requests.
1 Like
Hi @dstengle,
thanks for your input!
Your ideas go in similar direction as mine. Not the same, but similar.
And important thing is that till now the Instrument file is a file that (only) the editor works with. Electra does not understand the instruments. An instrument file is a definition of categorized messages (in / outbound) of a specific MIDI device. It does not contain information about MIDI channel etc. Such instrument files can then be used to build Preset files. A Preset file reflects a concrete setup (an instrument connected to a particular port and channel). The preset is the file that is uploaded to E1.
This was the original idea of the project and it is still supported (although the instrument files are now rather hidden in the editor). Although this sounds great for some situations, it can be cumbersome in others. Often, creating a preset straightaway without thinking about the instruments makes much more sense.
Over the time and with lack of decent support for editing instrument files in the web editor users created many presets which are implementations of individual synths. It means, kind of an instrument definition plus the default layout of controls. I see two big inconveniences here:
- users need to make copies to change the MIDI port and channel settings
- once they get a copy, they disconnect their new preset from subsequent changes made to the original preset
This is how I would like to solve that:
-
Make it possible to generate instrument files out of existing presets and allow users to edit/maintain the instrument files. All instruments files would be available to users in the editor. The would simply drag and drop predefined controls in the same way as you pick the Faders, lists, envelopes now. Actually, the selection of controls you see in the sidebar now are controls of so-called “Generic-midi” instrument file.
-
I will make it possible to override the device settings of a preset. This means that you will be able to use someone elses preset but change device settings in your account. By doing so, you would also subscribe for notifications on changes made to that preset.
-
I will make it possible for users to have a “development branches” for their public presets. The idea is that it would be possible to make changes to a public preset but “releasing” them to other users in a controlled way. Note, this can be done already by exporting and importing revisions between presets. This would just make it much more convenient. Currently, a new version of the preset is a new preset. That breaks the idea of tracking the “original” preset.
Anyways, above sounds more complex than your proposal. But it somehow reflects the current situation and capabilities of the controller.
Regarding the sysex messages and multiple devices on v1. The sysex messages (almost) always have enough data to identify the model and particular device. E1 can easily detect the destination of the messages. It is possible to create presets that have multiple devices with patch requests on v1.
Not that the above idea would be set in stone, but unless something changes, I will develop things according to that plan. Any input is welcome and will be reflected.
Cheers,
Martin
2 Likes
It looks like your plan addresses much of what I’m thinking.
I love #1 and that was how I had hoped it would work originally. I kept looking for a way to get the editor to do that and realized that the plan had not come to fruition yet.
For #2, it might be useful to have users configure their studio in the editor and then create or use presets from that perspective. This wouldn’t require any change on the electra but would make the “studio management” experience more consistent.
Regarding #3, this seems to get into the nature of the editing process as code vs no-code. Have you considered splitting the user experience between developers and preset users? Maintaining a process that offers versioning and releasing in a custom tool might become a lot of work compared to a source control and build and release type process.
I pointed out in another thread how some of the developer experience could be improved by more templating and compiling. If you had more of a development workflow with testing, you could potentially make the experience of developing and testing sysex processing more straightforward. I could see having a project with a sysex dump and a testcase with a known set of values from that dump and having a tighter feedback loop to create the processing configuration/code.
In the end, all of this is just about building and compiling what goes to the electra and the electra itself doesn’t need to change much or at all. It is more about making the front-end of the process more manageable and scalable.
In any case, thank you for taking so much time to write such thoughtful responses to my feedback. Let me know if you need any other sort of help.
-Dave
[Edit: grammar and more clarity on #2]
1 Like