Macro Pages / Macro Control Item To Allow Simple User Remaps of 3rd Party Presets

Ideas / Feature requests
1

My idea is for twelve Macro pages, each filled entirely with 36 Macro objects.

A long press of a macro object would allow the user to select any existing control in a preset to mirror on the macro page. Until a control to mirror is selected, the slot is blank. Once a control is mirrored, a further long press will show the usual expanded version of the control. But this time with the addition of an ‘Edit’ button to allow recall of the control selection dialogue.

This would allow users, of any ability, to instantly create their own customized layouts (control subsets) of existing presets without having to edit a copy of the template in the editor.

Because there are often a lot of controls to choose from in a preset, the preset page would be selected first from a list. That would then update a list of available controls to the right of the page list.

The macro pages and their coding would exist separately to templates and not require template creators to add the functionality. This would mean immediate backwards compatibility and use with all existing templates. No coding required from the template creators.

The Macro pages could be selected from the twelve slots immediately above the existing twelve preset page selection buttons.

When an ADSR combined control is mirrored, there would be an option to choose just one of the four functions. This would allow a user to split up a combined ADSR control to four macro controls for A, D, S, and R.

There could also be Global Macro pages that allow users to mix up controls from different presets on a single macro page. I accept that that would be much harder to implement.

1 Like
2

Interesting idea.
Would the new map/macro keep the original control’s color/labeling/etc?
Would you want to create groupings/borders around certain sets of controls?

I know some presets try to economize on screen space by moving controls around and/or hiding controls. I guess that if the macro mapping feature referenced the actual Control Id, it is unique and could be tracked.

Every user has a different perspective on what controls should be where and how the screens and connections and such should be laid out.

There’s a fine balance that is maintained since the E1 does not have 36 physical controls and with a lot of similar controls in every position you run the risk of making it look more like a spreadsheet in that everything looks the same. Without physical positioning/grouping/color/style cues, it’s hard to develop muscle memory and makes doing edits or finding a parameter difficult.

That’s why simple things like a real MiniMoog or SH-101 is so fast and fun to use. Your hand reaches for a control without needing to think about what you’re doing. Any type of remote editing platform can strive to be like that, but will usually fall short unless the implementation is simple.

So, my thought at the moment is that it’s an interesting idea and it might be good to see some kind of basic implementation of it on a small scale to see if it actually does help.

I don’t know about other preset developers, but I rarely get any feedback on my presets - about features, bugs, layout, behavior, etc. Usually it’s radio silence for whatever is posted. Sometimes there will be a message or two and usually (and correctly) about a bug, but generally it’s out there and who knows if it’s being used by anyone. If a macro mapping feature would make things more useful then that would be a good thing.

3

Every user has a different perspective on what controls should be where and how the screens and connections and such should be laid out.

The main benefit to preset creators would be that they no longer need to worry too much about having a UI layout that caters to all users. The preset page layouts could be designed for hardcore patch programming, but a user of the preset could then create a macro page with a subset of mirrored controls for live-tweaking.

Would the new map/macro keep the original control’s color/labeling/etc?

Yes, exactly the same, a mirror/clone. Renaming and recolouring would be too complicated and reduce the likelihood of the macro system being implemented. Maybe as a V.2 implementation much further down the line.

Would you want to create groupings/borders around certain sets of controls?

No. For the same reasons as above. Keep it simple to start with.

It is down to the individual user setting up their Macro page to arrange the macro controls in ways that make logical sense to them. The preset creator need not worry about this.

4

I should add that as many preset creators already use particular colours to indicate control groups, those colours would carry over to the macro and the group origin of the controls should still be obvious.

I would expect macro creators to want to keep control subsets of a particular preset group together. It would improve usability, for sure.

5

The way I envisage the Macro item working is that it simply points to a particular control location on a preset. Like Page 1, position 27. It shows and duplicates whatever control is at that position. The macro creator choose from the names of controls at the different positions, but the macro item just memorizes the position.

If the preset creator then issues an update which moves controls around (unlikely after initial development), then the macro creator would have to update their macro to point to the new positions.

It may be better to point to the actual synth parameter, but would that carry over colours and names as simply as referencing the position?

6

OK, a quick sketch of the solution is embedded in this microWave version

Once you do a sync and grab a patch (or not - untested), go to Page 11
Bottom left - you can select a slot from 1 to 24. Once you pick a slot, the next control scrolls through the first 24 or so controls in the editor.

Once you find a control you like, press the “Set !” button and it will appear there.

Many many caveats - making copies of a control is not natively supported and the amount of difficulty doing it manually (handling lists, changing ranges, embedded function() and formatter() methods) is way beyond what is useful.

As another note - there are a limited number of Control IDs so in practice you’d only have a subset of the whole available and then there’s all the coding that depends on sometimes a Control ID and sometimes a parameter number and sometimes a slot, the headaches go on and on.

By actually moving the control around, you bypass the vast majority of those problems. The main thing that would need to be done is to initially record (as part of an updated version) the initial page number of every control so that if you change your mind, the control can be put back into its original spot.

This ends up leaving holes all over the preset, but if someone wanted a particular configuration, they could go page by page adjusting positions.

An Undo button would be nice to put it back, but that’s too much work for me at the moment. I just wanted to give you a feel of what could be done relatively quickly and safely. There’s still the issue of any controls that interact with each other and any functionality that gets called when certain pages become active 9and there’s the whole custom control thing.

But - for certain circumstances, this could be useful, if for no other reason to create a ‘using it live’ subset and saving that off as a snapshot.

7

Also - if you are in playing, go to the Cfg/Save page and try the “Get Version” button and the “Get All Names” button.
If the Get all names doesn’t crash your E1, try scrolling through them with the control to the right and see if all the names fully match.

The name editor at the bottom has been started, but not fully finished yet.

No idea what Patch save will do at the moment, I recommend not touching it.

8

Thanks for making that version to test. It does work, but is it actually testing for what I am proposing?

A page of macros controls will simply be stored on the E1 as a table of two positions:
The macro item position on the macro page + the referenced control position on the preset page.

When a macro page control is adjusted, it is just a UI alias, the control that is really being adjusted is the unique one being referenced on the preset page. There is no duplication of control items in the preset.

Also - if you are in playing, go to the Cfg/Save page and try the “Get Version” button and the “Get All Names” button.

It gets the version and released date fine - 02.00 94/03/07
It does receive data with the get names button.
The only name retrieved is the first in A01. At least that is the only name displayed using the rotary control to go through them, the rest are blank.

9

The problem is that on a technical level, I don’t really understand how the E1 works. All I know is that for the macro system to be a success, it must require zero programming from preset creators, and be backwards compatible with all existing presets, with no further action required from the creators.

10

That is the problem - to create a macro “thing” you either need to duplicate all the control info or actually move the control around.

Given the structure of the E1, currently there is no way to create something that looks like a control (or momentary button) that only references the actual object and still is able to display the name, value, range, and execute the functions associated with the control.

re: “Get All Names” - try it right after SYNC, but before recalling a patch.
(or if that’s what you did, try Get All Names before sync)

(I’m testing with manual data entry via MIDI-Ox, so not 100% sure what the MW is doing).

1 Like
11

re: “Get All Names” - try it right after SYNC, but before recalling a patch.
(or if that’s what you did, try Get All Names before sync)

I have tried both ways and it still just displays the one name. I know the ‘get all names’ button pulls all the patches, because it keeps adding them to the Masterboard in the Laser Mammoth librarian.