Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automation Parameters #83

Open
teotigraphix opened this issue Nov 13, 2018 · 1 comment
Open

Automation Parameters #83

teotigraphix opened this issue Nov 13, 2018 · 1 comment
Labels
feature request Request for a missing feature

Comments

@teotigraphix
Copy link
Contributor

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
Copy link
Owner

igorski commented Nov 13, 2018

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Request for a missing feature
Projects
None yet
Development

No branches or pull requests

2 participants