19.09.2014 14:38, Tanu Kaskinen wrote:
> Hi,
>
> I was thinking how ladspa controls could be implemented and exposed in
> the client API with the upcoming control framework. Not that I have
> plans to implement a client API for ladspa controls any time soon, but I
> want to have this some day, and the current control API doesn't seem
> optimal for supporting this functionality.
>
> The current plan for the definition of pa_control_info is the following:
>
> typedef struct pa_control_info {
> uint32_t index; /**< Index of this control. */
> const char *name; /**< Name of this control. */
> const char *description; /**< Description of this control. */
> pa_proplist *proplist; /**< Property list for this control. */
>
> pa_control_type_t type; /**< Type of this control. */
> void *data;
> /**< Type-dependent data. See pa_control_type_t for information
> * about what data each type has. */
> } pa_control_info;
>
> It seems to me that the type field should be changed from an enumeration
> to a string, so that modules would be free to introduce new control
> types without modifications to the core.
>
> It would also be nice to be able to associate arbitrary controls
> directly with e.g. a sink. For that I propose to add an array of
> controls to pa_sink_info and friends:
>
> struct pa_sink_info {
> ...
> struct {
> const char *key; /* e.g. "volume" or "ladspa" */
> uint32_t control; /* index of the control */
> } *controls;
> unsigned n_controls;
> };
>
> This would make the planned volume_control field redundant. However,
> this would also make accessing the volume control more complicated,
> because applications would have to search the array. If we drop the
> volume_control field, we could add a convenience function for doing the
> search:
>
> uint32_t pa_sink_info_get_control(const pa_sink_info *info,
> const char *key);
>
> Any opinions? If nobody will complain, I will implement these proposals.
No objections, just questions.
Let me ask them using a hypothetical one-channel de-esser plugin as an
example. Let's assume that threshold, frequency and attenuation can be
controlled on this plugin.
1. Some LADSPA plugins may need to be "repeated" in multichannel setups
due to their inability to process more than one audio channel. Do we
intend to store per-channel settings (e.g. be able to say "apply a
strong de-esser to the left channel and a weak de-esser to the right
channel"), or just assume that all channel-related copies of the plugin
will use the same settings?
2. Do I understand correctly that the whole block of the settings
(threshold, frequency and attenuation in the example) goes into one
pa_control_info instance?
--
Alexander E. Patrakov
