Re: [iiwusynth-devel] FluidSynth release

[Peter Hanappe]

Josh Green wrote:
> On Thu, 2003-02-27 at 04:05, Peter Hanappe wrote:
>
> > > Here is a list of functions I use related to voices/mods/gens:
> > >
> > > iiwu_mod_delete
> > > iiwu_mod_new
> >
> > Is it OK if I make the iiwu_mod_t structure opaque and define
> > accessor functions instead?
>
>
> Accessor functions, yuck.. 

LOL! Why not go straight for assembler, Josh!


> Seems like unnecessary overhead. A modulator
> is really just 5 short int fields (the transform field can be ommitted
> since it has only 1 defined value, linear). Why not omit iiwu_mod_t all
> together and just have:
>
> iiwu_voice_add_mod (iiwu_voice_t *voice, int source, int amt_source,
>                     int dest, int amount);
>
> (int could be "unsigned short")
>
> Then just adhere to the format defined for these fields in the SoundFont
> spec (rather than splitting the source enumerations into flags and
> control as it is now).

I like the object oriented approach: I like to call a cow a cow, and not
a horse with some extra bit flags! Seriously, I like to consider a
modulator as an separate entity - an object.
If I'd make a change it would be this: 1) the flag indicating whether
the source is a general controller or not should be part of the source
itself, and 2) the 'flags' field should be renamed to "mapping" because
that's what these flags indicate (they define 16 possible source
mappings, cfr. figure  8 in the SF specs). However, I wouldn't want to
make that change now because I'm too wary to introduce errors and it's
not that big of an issue, me think.


> The interface could be additionally simplified by ditching the different
> modes of adding modulators in which case the voice should be created
> with no modulators at all (not even the default ones, although maybe a
> iiwu_voice_add_mod_defaults() might be useful to someone). For myself I
> don't need the different modes, of course I'm doing my own modulator
> processing so perhaps this could be useful to others?

You're right about that. However, I've never been keen on making the
internal data structures of the synthesizer accessible. We opened it up
so you had a better access to it, but it's not something I want to
promote in the first version.


> As far as iiwu_voice_query_ID.. <cut>

I kept the function, but renamed it to iiwu_voice_get_id. Also
rename iiwu_voice_query_playing to iiwu_voice_is_playing.


> Setting an arbitrary generator in real time seems like nice
> functionality though (and isn't covered by NRPN or other channel based
> generator set methods), I just wish I could think of a less hackish way
> to achieve it. For Swami it basically involves mapping active voices to
> an audible and voice index (an audible being a Preset, Instrument or
> Sample) and keeping it in sync with FluidSynth.

In the next version, we can make the internal soundfont structures more
accessible. It might be interesting also to think of a more generic
notification system for various events (preset load/unload, sample
start/stop playing, ...).


> > > Is there some other way to set mods/gens? It seems fairly necessary for
> > > the sfloader API.
> >
> > You can use "iiwu_synth_set_gen" but that's it.
>
>
> Thats for an entire channel though. When using the sfloader for custom
> instrument management, that would not be sufficient.

You're right. Again, we can improve things in the next version.


Apple pie!
P

> Cheerio,
>         Josh