Optimizing the parameter automations

[abique]

Optimizing the event queue for param automation/modulation

The current design is very good because of its simplicity.
I think it is good to require to support it for both host and plugins.

Yet it does not scale very well when it comes to voice stacking and polyphonic modulations. So it could be useful to have more advanced options.

Here is a proposal:

• Add new events:
  • CLAP_EVENT_PARAM_{VALUE,MOD}_RASTER
  • CLAP_EVENT_PARAM_{VALUE,MOD}_VECTOR

We would introduce flags in parameter info to know if raster and vector are supported.
We can add a suggested_raster_period to the param info, that way the plugin can indicates the host how many points to generate per process call.

Raster

The raster approach is simple: you get an array of values in the event and all the points are periodic. It is simply a periodic sampling of the automation or modulation signal and the plugin should handle them in the very same way as if it was multiple distinct events.

Vector

This is the VST3 approach, you get a set of points: value and time, which then describe the vector shape of the signal by drawing lines between points.

C structs

typedef struct clap_event_param_value_raster {
   clap_event_header_t header;

   // target parameter
   clap_id param_id; // @ref clap_param_info.id
   void   *cookie;   // @ref clap_param_info.cookie

   // target a specific note_id, port, key and channel, -1 for global
   int32_t note_id;
   int16_t port_index;
   int16_t channel;
   int16_t key;

   uint16_t value_period; // number of samples between two points
   uint32_t value_count;
   double *values;
} clap_event_param_value_raste_t;

typedef struct clap_param_vector_point {
   uint32_t time;
   double   value;
} clap_param_vector_point_t;

typedef struct clap_event_param_value_vector {
   clap_event_header_t header;

   // target parameter
   clap_id param_id; // @ref clap_param_info.id
   void   *cookie;   // @ref clap_param_info.cookie

   // target a specific note_id, port, key and channel, -1 for global
   int32_t note_id;
   int16_t port_index;
   int16_t channel;
   int16_t key;

   uint32_t point_count;
   clap_param_vector_point_t *points;
} clap_event_param_value_vector_t;

Benefits

• Improve our compatibility with VST3
• Needs less memory for events and reduce the number of round trips between the event queue and parameter rendering
• Saves some "sorting" of the event queue for the host
• Raster with period = 1 is perfect audio rate modulation/automation

Problems

• Adds 2 new ways to do the "same thing"
  • those options are not mandatory and can be 100% ignored

[defiantnerd]

How should compatibility be signalled?

[baconpaul]

In raster let’s say you set a raster period of 64 and get a block which isn’t a multiple of 64. Do you have to bookkeep the offset from last stub?

Generally: the non inter leaved queues are one of the more painful things about vst3. You’ve basically moved the sorting to the plugin haven’t you? I don’t see a way to use vector without scanning all your queues for next at every internal sample or block. Have we tried to convert a plugin from the current queue to a vector or raster format, especially one which interleaves param automation and midi, say

[baconpaul]

Oh I just saw this is a year old! Sorry I thought it was from this may. Lol