Re: [iiwusynth-devel] Proposition: Settings API

[M. Nentwig]

Hi,
...

> For version 1.0 ("on a computer near you very soon"), I'd like to keep

> the code for the reverb and plugins as it is now. As soon as we made a

> stable release, we split of a development branch where we can
> hack into
> the effects/plugin code.

Good plan.

> However, it would be good to think of a naming scheme that is
> consistent with what we'd like to do afterwards. The names of the
> reverb and chorus parameters should be what they will be after the
> changes. Something like:
>
>    plugin.reverb.roomsize
>    or
>    effects.reverb.roomsize
>    or
>    fx.reverb.roomsize

I'm in favour of 'fx' because it means less typing (like in
fx.reverb.roomsize).
Then we could 'reserve' the names reverb, tremolo, celeste, chorus,
phaser for default effects.
I will then make only 'fx.' parameters visible in the Fx unit:

Deleting settings:
Is there a way to delete a setting (do we need it?) If yes, removing
fx.something settings will only be allowed, when the Fx patch bay is
disabled, while non-'fx' settings can be removed anytime. Predefined
settings (reverb, chorus) can't be removed.
I could live without this, though.

>
> The current LADSPA API allows users to give the plugin a name. So the
> plugin's parameters could be accessible as
>  effects.<pluginname>.<paramname>
>

I think of each plugin parameter as a 'node' that appears in the Fx
unit. For example, fx.reverb.chorus.depth results in the node
'CHORUS.DEPTH' (capitalize ad lib :)
Now any number of plugins can get their parameters from that node, like
in

ladspa_add mylib.so mychorus Input <- (somewhere) Output -> (somewhere)
depth <- CHORUS.DEPTH

This allows to hook up several plugins to the same set of parameters.
For example, left and right (mono) equalizer usually share the same
settings.
LADSPA Plugins themselves don't have / need unique identifiers, they are
'anonymous'.

> If you all agree with that, I can make the changes this week. The
> {reverb|chorus} {API functions|shell commands} would be replaced
> with the settings {functions|commands}.

Great. Nice to see this go ahead.
Thinking about settings, we could include channels into this scheme some
day, to get rid of existing code and to implement features beyond SF2.
For example:

chan.1.polymode (mono, stereo)
chan.1.portamento.mode
chan.1.portamento.speed
chan.1.cc.91
chan.1.cc.pitchbend
chan.1.filter.mode (lpf6, lpf12, lpf18, ...)

Cheers

Markus