Re: [iiwusynth-devel] FluidSynth release

[Josh Green]

On Tue, 2003-03-11 at 03:53, Peter Hanappe wrote:
> 
> > Accessor functions, yuck.. 
> 
> LOL! Why not go straight for assembler, Josh!
> 

I wasn't saying yuck to accessor functions in general, only to the idea
of applying them to modulators.

> > 
> > 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.
> 

My point was, that you don't really need to have a structure, but only
an interface function. The definition of a SoundFont modulator is not
likely to change. Looking at the 16 bit source enumeration the CC bit is
part of the bottom 8 bits containing the controller index, so it is kind
of already part of the controller. I don't really have any objections to
splitting out the 2 bytes to mapping and controller, it just seems a
little unnecessary:

iiwu_voice_add_mod (iiwu_voice_t *voice, int src_ctrl, int src_map,
                    int amt_src_ctrl, int amt_src_map, int dest,
                    int amount);

Concerning cows and horses :) I don't see many problems with considering
a modulator source a single cohesive object that also defines its own
mapping. If someone is working with SoundFont files, its what they would
probably expect anyways. Since this function is also really just an
interface, it matters not how FluidSynth implements the actual
modulators underneath.

> 
> > 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.
> 

How did my comment there relate to opening up FluidSynth internals? I
think it is somewhat the opposite. Having an interface function, hides
the details of what FluidSynth itself uses.

> 
> > 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.
> 

Sounds good.

> 
> > 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, ...).
> 

Its very likely that the current amount of accessibility to FluidSynth
internals is adequate.

> 
> 
> Apple pie!
> P
> 

Hope I didn't offend in any way. I meant only the best by my comments,
and wasn't trying to criticize anyone. I think the FluidSynth API is
really cool, I was quite surprised at how quickly you came up with the
sfloader and how flexible it is. Cheers.
        Josh Green