Reading MK2 presets into Mini for Reprogramming

Martin,

It’s not clear if I should be trying to read MK2 presets into the Mini or just try recreating them from scratch with the reduced format required. Documentation seems to imply you can move back and forth programming them but not sure that really is feasible. The current web editor does not allow me to load any MK2 presets on Mini. Maybe only simple ones it can easily map are allowed to do that.

I removed the initial assert statement which I assume would cause the program to be rejected. Not sure what the plan is here, ever best case an MK2 preset using 36 controls can only map to the new multi controls that allows for 32 controls on a page (2 sets of 16 - looking at the demo). Then again all the control numbers in the MK2 versions would likely not map one to one either.

So should I simply be loading up code and then reworking for the Mini in terms of the user interface and then have separate MK2 and Mini versions? And are there suggested names then to use to differentiate a Mini from MK2 program.

Also can you have Mini and MK2 connected - does the web editor allow you to switch between them?

Thanks

Rich

Also how do you rename the multi fader f1 (“FADER 1”), f2(“FADER 2”), etc. option names when you dive down into the menu. Is that done with a formatter? Thanks.

I am mentioned it elsewhere but as there has been quite some progress I will summarize it here.

The update of the editor to fully support Mini is done in two steps. The first one is already online (app.electra.one). It added a new layout of controls for Mini and resolved some issues from the past. The change in how the editor works internally was huge. And with over 20GB of preset data in the database it caused some friction. But the essentials work now.

Yesterday, I deployed the second part of the update to beta.electra.one. It is a pre-production environment that is connected to the production data (read presets). I am currently testing everything there and making sure it works as it should. There are still some quirks. This second update delivers the final functionality as well it reflects most of what was mentioned here on the forum in the past and recently.

The main idea of the editor updates is to decouple the definition of the controls/groups (values/messages/lua) from their physical locations. To do so, a “layout” layer has been added. it is way to define where controls are located within the preset pages. By having layouts a developer can maintain one sets of MIDI messages, overlays, patch parsing rules, and Lua while having two or more independent layouts of controls.

Until recently, there was this ambiguity about what a preset is and what the project is. They seemed to be the same thing, just organized differently. With the recent update the idea is more obvious. A project maintains all the pages, controls, layouts, lua for multiple target controllers (mini, mk1/2) now. A preset is a subset of the project data compiled for given target hardware controller. This is a change that will bring some benefits to mk1 users too in the future.

how does that work in the real world:

in the latest update (on beta) a user can open two different layouts in the same time:

Controls and groups can be dragged and dropped between the layouts. The drag/drop action will not create a new copy of the control, instead it will create a reference to the original control. The original and the referenced control use the same “reference id”. This is a bit over-simplified but I hope you catch my drift.

If you place a new control on the layout or if you copy/paste controls, a new copies are created, meaning they are their own reference ids..

This way a project may have controls that are used in both layouts (mk1/2 and mini) as well as there can be controls that are used in specific layout only. Lua has access to all controls using their reference ids.

There is also a new “view” called controls:

It is a list of all controls defined in the project across all available layouts.

I will be testing/improving things on beta today. Once I reach the point I feel it is safe use for ordinary users I will update app.electra.one

a few important notes:

  • vast majority of projects/presets that do not have fancy dynamic layouts should be really easy to migrate to between the mk1/2 and mini.
  • complex presets (such as @jhh @moss and yours) might either needs some doing in terms of Lua being aware of two different layouts.
  • the upcoming controller firmware update will allow mk2 to simulate mini and thus run mini presets on it.
  • whoever decides to test the update on beta is strongly advised to work with copies of their projects. The updated editor makes changes to the presets that are not backwards compatible. Of course, if you do such change by mistake, you have an option to revert back to the previous revision of the project.

A full overview of editor changes will be provided in a separate post.

It is also important to mention that while Mini is capable of fully running mk2 presets, there are physical restrictions given by the number of knobs, buttons, screen resolution. Having a complex preset that supports both conrollers will require some thinking about the layouts and their restrictions.

The new “4 Fader” control type was meant to provide a hint on what could be done and possible direction to go to get more out of Mini. Currently, it is based on mk2’s standard multi-value conrol with prefixed values. I am quite sure that in the future this could be extended and made more flexible. I already received quite some feedback and idea on that. The points you mentioned are totally in line with that and make perfect sense.

And final remark. As always, I am open to any input from you guys and will use it to shape things up. After all, you spent more time using electra than I do. I have become just a software developer :wink:

2 Likes

Superb, Martin.

There are two things popping up, that might help with porting:

  1. adding up to 4 subpages to each Mini page via the buttons. When for instance a Mk2 preset has an OSC page for 3 oscillators, it would be handy to translate this to an OSC page on a Mini as well, where you can access 3 subpages for OSC1, OSC2 and OSC3, each with a similar layout. One page of 36 Mk2 controls can then easily be ‘translated’ to 1 page + 4 subpages on a Mini, giving 40 controls in total.
  2. In a few presets, controls are being moved between slots, or slots are hidden/made visible. As these slot parameters are often referenced by in lua, without actually correlating them to the controls, that might be quite hard to port such presets. If you can keep the #reference of each control the same between the various E1 formats, that is already a big part of the page. However giving each slot a fixed reference will not be possible. But we don’t need that: if we would be able to give a unique slot-name ourselves to those slots we want to address in lua (instead of addressing them by page and slotnumber), then porting would be much easier
1 Like

Martin. Thanks! I need to wrap my head around this and sta4t with some simple preset conversions.

1 Like

@martin ,
another handy feature in the Web editor for the Controls page: if we could choose the sorting based on #ref, name or parameter number, this would be very handy to figure out what #ref or what virtual parameters are not yet in use.
currently the search isn’t working yet of that control page

1 Like

The search has been added. It’s on the beta. It allows searching controls by the name, reference, message type, parameter, midi device, channel, port, formatter, and function name. Ordering totally makes sense. I will add that later.

Just throwing a few hints on the search here:

name, midi device name, formatter, function → just type text you search for

reference → type ref #nnn

message → type “cc7 #10” or “virtual #1000” it always reflects how things are shown on the output

channel and port → type “port: 1” or “ch: 16”

3 Likes

Are you suggesting we will be able to control 8 values when clicked?