search

igorski / MWEngine

Audio engine and DSP library for Android, written in C++ providing low latency performance within a musical context, while providing a Java/Kotlin API. Supports both OpenSL and AAudio.
MIT License
259 stars 45 forks source link

Automation Parameters #83

Open teotigraphix opened 5 years ago

teotigraphix commented 5 years ago

Hi,

I don't know if the current framework can handle it but having an automation framework that can use a table or linked list for key/value pairs that real-time adjust synth parameters or audio event parameters.

Have you daydreamed about this before in context of MWEngine?

igorski commented 5 years ago

I have actually. But not taking action on anything yet as I have to think the design through, let's use this issue to ponder the implementation:

What I'm thinking is that both BaseProcessor and BaseAudioEvent should implement a handleAutomation( int paramId, float value )-type function where paramId identifies which parameter to automate and value specifies the target value it should move to. Each class can override this method for their specific parameters and behaviour. I'm thinking value should be in the 0.f - 1.0f range - similar to the VST spec - where depending on the paramId this can be scaled to a value in the range appropriate to the parameter that is being automated.

A parameter change can be checked in by using a Sequencer function like:

int addAutomation( int bufferPosition, Automatable* target, int paramId, float value )

Where bufferPosition determines when in the current sequence the change occurs and target defines the object that will be automated. The return can be a token id for the automation (so it can be removed individually).

The Sequencer can then inform the engine when to execute said action.

This leaves me to ponder how to deal with gradual changes, we could specify a range of "automation start" to "automation end" and calculate all changes in between, but this would only work for linear transitions. In the VST spec, the VST host is responsible for sending the parameter change on every step of the transition, we could consider a similar approach (it means that the implementing application has the responsibility for registering all points within a transition, but it comes at the benefit that you can create arbitrary transition functions).