Feature request: custom controls with user defined detail window

[jhh]

It would be nice to generalise the concept of a custom control to also allow the programmer to specify how to draw the contents of the detail window. This would allow to define e.g. a filter device with a popup controlling and showing the filter response (and adjusting it in realtime as pots are turned).

Thinking about this I think there would actually be two different types

1. Like the XY-pad: control needs to redraw full popup window and needs to handle touch and pot events all by itself.
2. Like the four stage ADSR: control needs to redraw top half of popup window whenever a value changes; bottom half is dealt with firmware and handles pot and touch events and shows values for pots automatically like e.g. the four stage ADSR does;

A custom control should have at most 8 values (so it works on Mini as well as mkI/II). On mkI/II there are mapped to middle four pots on each row. UI in webeditor similar to the four stage ADSR to specify MIDI info per control. If Message type is None then value not used, and no knob assigned in popup view.

• For additional flexibility allow to select either a dial, a button or a list as possible control type in the popup window

Allow a custom control to be controlled by more than one pot if the detail window is not shown (i.e when in normal page mode). The pots that could control it are defined by the width and height of the control. (Such controls should only span at most two rows, and only row 1+2, 3+4 or 5+6). Specify in the web editor which value is controlled by which pot.

Additional functions for the LUA interface for custom controls

• define control:setPopupPaintCallback(paintControlPopup)
  to set the function to call to draw the (top half of the) popup window; also
  called whenever one of the pots is changed
  • where paintControlPopup(control,value1,…,value8)
    is passed the 8 values of the control and uses this to draw the contents of the popup window
• define control:setPopupTouchCallback(touchControlPopup)
  to handle touch events while popup is shown
• define control:setPopupPotCallback(potControlPopup)
  to handle pot events while popup is shown

And add additional fields in the webeditor (like the function and formatter callbacks) to specify these.

[martin]

@jhh this reply touches both feature requests you posted on the forum:

Feature request: custom controls with user defined detail window

It would be nice to generalise the concept of a custom control to also allow the programmer to specify how to draw the contents of the detail window. This would allow to define e.g. a filter device with a popup controlling and showing the filter response (and adjusting it in realtime as pots are turned). Thinking about this I think there would actually be two different types Like the XY-pad: control needs to redraw full popup window and needs to handle touch and pot events all by itself. Like…

and

Feature request: some more controls like VFader 4 or XY pad

The advanced controls like the VFader are a great way to add complex functionality to the small screen of the Mini. Some suggestions for additional controls: 2 dials/faders → eg for tune + finetune; volume + pan 2 buttons (on mkI/II: aligned left/right, on Mini: aligned top/bottom) 4 buttons in a 2 x 2 grid (for the Mini only) Those would help me create a proper Ableton mixer for the Mini.

This is exactly where I am heading to. The custom controls were made more generic in 5.0.0 and have been decoupled from the projects. It is possible now to create a custom control that can be reused in other projects. The idea is to make it similar to how we work with projects / presets. Users will be able to create and share custom controls (Lua knowledge required) and other users will be able to use them just by drag-n-drop as standard controls (no Lua knowledge needed). The AI assistant in the offline editor has been already trained to gain some skills in that area. But it needs more doing…

I have already made changes to the web application so that My Presets and Public Presets are now Workspace (users work area) and Library (shared stuff). On those pages you get access to Projects, Controls, and Surfaces.

The Controls tab is for working and sharing custom controls. What is missing is me writing a tutorial, providing examples, and extending the documentation. In short: a custom control can be developed by creating a reusable Lua package. The editor takes care of including it safely to other presets. That Lua package is ready to be later used by the “preloaded” mechanism we use for presets and Lua modules already.

For now, and on contrary to Projects, shared custom controls require my approval. I want to review how each custom control is implemented prior to being made public and possibly included in other users’ presets. I will try to do the review on timely basis and will drop that rule as soon as I see things are done right.

Once the custom controls is shared, users can see them Library:

The most notable function here is the “Add to my palette”. That allows users to add a selection of custom controls to their editor. What is on users’ palette gets displayed in the editor:

If a custom control uses only one value, it is assigned to the pot according to the slot it sits in. If it has multiple values, user who wants to use it must assign the values to the pots manually. The control set is determined by the placement of the top-right corner of the custom control:

That’s the functionality in nutshell. I did this because I genuinely believe it is the right way to address requests for additional envelopes, program change selectors, and various other controls that some users find useful but that would add unnecessary complexity to the editor for others. Also, we can use the power, time, and knowledge of the community without me being a bottleneck.

The detail window for custom controls is the next step. Your idea is more/less identical to what I want to do. I will add it when we can see that the shared custom controls work ok.

I will try to share more info and real-world examples of the custom controls and how to share there soon.

[jhh]

Extremely cool. I very much like the idea of being able to share custom controls like presets. Looking forward to test this out!!

[SV_huMMer]

This is an extremely powerful tool to expand and (!!!) make more accessible the incredible powers of the Electra Platform!

As someone who starts sweating heavily from the mere thought about extensive LUA scripting, I am really thrilled to even hope that “pre-made shareable custom controls” become a reality.

[Quelectra]

This is looking great.

Is there a way to allow the user to switch what parameter the assigned knob controls when not in detail mode?

Ideally there is a built in way to change this (some gesture on the knob, use the last one used in detail mode, some other detail mode method (soft button to cycle the choice).

Ideally there is a lua method a developer can use to change this programatically.

[Flyweight]

@martin

In short: a custom control can be developed by creating a reusable Lua package. The editor takes care of including it safely to other presets. That Lua package is ready to be later used by the “preloaded” mechanism we use for presets and Lua modules already.

I think if you can assign a “virtual control” you can change the assignment anyhow programmatic.
very cool this. Animated and nice graphics.
It can for sure improve the quality of the UI.

Great to see where the E1 went. @martin