Associated automations

[messmerd]

The Problem(s)

Current automation tracks have some problems and quirks:

• Automation tracks can have many automation clips that each control something different. This is necessary to reduce the number of automation tracks a project needs, but also makes projects messy and disordered.
• Multiple controls, including controls with incompatible min/max ranges and incompatible types (float/int) can be connected to the same automation clip.
• Automation clips (whether on the same automation track or on separate ones) can overlap with each other and try to set the same control to two different values at once.
• Removing an instrument or effect leaves any automation clips connected to its controls in a dangling state.

A Solution

I'm proposing a new, more restrictive type of automation track which would fix all these problems and encourage better project organization. I am calling them associated automation tracks since they have a parent instrument they are associated with. When this idea is combined with the collapsible automation tracks from #735, a lot of visual clutter in the Song Editor can be reduced.

How it works:

• An instrument track can have automation tracks associated with it, and these associated automation tracks are displayed in a collapsible list directly beneath the instrument they are associated with (See #735). Instruments can be thought of as a track group for their automation tracks.
• Associated automations enforce some restrictions:
  • Each associated automation track and their automation clips are dedicated to a single control
  • Only one associated automation track is allowed per control
  • Each control must originate from the associated instrument or one of its effects
  • Automation clips cannot overlap
• All associated automations are moved with and deleted with their instrument
• If an instrument's effect is removed, any associated automation tracks connected to that effect are also removed

Additional notes:

• The default name of each associated automation track is the same as the control they are dedicated to
• There are no unconnected automation clips in an associated automation track - creating a new clip creates it with its connection already set
• A new associated automation track can be created by \<Ctrl> + dragging the control of an instrument or one of its effects onto the instrument itself
• If a regular automation track meets the restrictions of associated automation tracks, it can be dragged to its instrument track to convert it into an associated automation track
• If a regular automation track DOESN'T meet the restrictions of associated automation tracks, there are still ways it can be at least partially converted
• When each automation clip is dedicated to a single control and the min/max range issues are fixed, it will be easier to enable custom y-axis labels in the Automation Editor for CLAP plugins and other plugins that support it.
• Associated automation tracks could serve as the foundation for future work on MIDI polyphonic expressions (MPE) in the Piano Roll. Just as associated automation tracks have a parent track whose controls they are responsible for, note expressions would have a parent note whose controls (volume, panning, pitch, etc.) they are responsible for. When a note is deleted, its associated automations would be deleted, just like instrument tracks.

Design considerations

• Should be fully backward-compatible
• Should be opt-in. Regular automation tracks still exist and no project upgrade routines are needed.
• Should encourage better project organization
• Should be intuitive and easy to use
• Track grouping/collapsing under instrument tracks should be implemented with the proposed general-purpose track grouping/collapsing in mind (#735).

Mockup

See #735.

[michaelgregorius]

If the automation system is revamped then the problems described in #6954 and #6209 should be considered as well. The underlying problem is that LMMS automates the (GUI) controls of instruments/effects instead of parameters which are exposed by the instruments/effects. So the implementation is [automation] -> [control] -> [parameter] instead of [automation] -> [parameter].

The following coarse steps would be necessary to fix this:

• Check for each internal instrument/effect which automatable controls it uses.
• Introduce a parameter for each control. This parameter might have a type (float, enum, int, ...) and some min and max values.
• Reimplement the GUI controls of the plugin so that they manipulate the exposed parameters.
• Provide a means to collect/inspect all parameters provided by an instrument/effect.
• Provide an upgrade routine which associates the automation track with the parameter instead of a control.

Adding an automation might then work as follows. Each track has a control, e.g. a combo box or menu, which lists all the available parameters of the instruments/effects that are associated with that track. Selecting a parameter will create an automation track that is associated with that parameter. I think this is somewhat how it is implemented in Ableton Live.

Before implementing this it would be a good idea to study all the parameter interfaces of plugin standards like VST 2.4, VST3, CLAP, LV2, etc. with the following questions in mind:

• How are the parameters discovered?
• What type of parameters are supported: float, enum, int, ...?
• How are multiple channels (mono, stereo, surround) handled/exposed? Are sidechain channels supported explicitly?