[iiwusynth-devel] Recent CVS changes

[Josh Green]

Some notes and thoughts on recent CVS changes:

Missing a parameter in call to new_iiwu_timer in src/iiwu_seq.c:354, I
just put a 0 for the last parameter to get on with things.

Most of the stuff that broke the Swami iiwusynth plugin were related to
the changes to the settings system. I don't think the use of directly
accessed fields is such a good idea for a long term API. Too much
breaking of binary and backwards code compatibility. The API for
iiwusynth probably doesn't matter so much, since it will be changed with
FluidSynth.

A good system I have seen of being able to set a lot of settings in a
backward compatible manner (when not using GObject properties and
ParamSpecs :) would be to make iiwu_settings_t opaque (no direct access
by library users, make it a void *) and then provide accessor functions
to it. The iiwu_synth_settings_init() function could then be applied to
it to initialize to default system values. There would then be functions
like:

fluid_settings_set_reverb_active (settings, TRUE/FALSE)
bool fluid_settings_get_reverb_active (settings)

The advantage to this is that adding new parameters/functions would not
break backwards compatibility and the internals of the iiwu_settings_t
structure could be messed with as much as one desires :)

Perhaps we could then have a way of fetching the iiwu_settings_t
structure associated with an active iiwu_synth_t to be able to query
settings (or perhaps modify them?). Or maybe just integrate the settings
structure with the iiwu_synth_t context and have a function to create a
new iiwu_synth_t and then a function to activate it when the settings
are to ones liking. The settings accessor functions would then deal with
the iiwu_synth_t context instead.

This brings me to realize another thing missing from the current way of
dealing with settings. Ways to determine min/max/default values for
different parameters.

It seems to me GObject does have a lot of nice facilities to handle
these things. A GObject interface to FluidSynth is essentially what I
will be turning the Swami plugin into. Each FluidSynth parameter will be
a GObject property. GObject properties use the GType system and
GParamSpec structures to define what values (valid range) a parameter
can have. Creating a new FluidSynth context might look something like
this in Swami:

g_object_new (WAVETBL_TYPE_FLUID_SYNTH,
              "audio-driver", "alsa",
              "midi-driver", "alsa-seq",
              "reverb-enable", TRUE,
              "chorus-enable", FALSE,
              "reverb-room-size", 0.2,
              .. etc)

As things are now I have to hard code what ranges I think FluidSynth
allows (by looking at the code) but what happens if these ranges change
in the future? What I'm really wondering, is should facilities be
provided in FluidSynth to be able to query this type of information, or
should I just try and keep the Swami plugin up to date with the latest
FluidSynth (could be nightmarish).

A lot of thoughts, perhaps not worth much :) Cheers.
        Josh Green