iiwusynth-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [iiwusynth-devel] FluidSynth release


From: Josh Green
Subject: Re: [iiwusynth-devel] FluidSynth release
Date: 27 Feb 2003 14:18:13 -0800

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

> 
> > iiwu_synth_alloc_voice
> > iiwu_synth_start_voice
> > iiwu_voice_add_mod
> > iiwu_voice_gen_set
> > iiwu_voice_update_param
> 
> Can I remove "iiwu_voice_query_ID" and "iiwu_voice_gen_incr" from
> the public header?
> 
> I did add "iiwu_voice_gen_get" as a complement to "iiwu_voice_gen_set".
> 

If you have iiwu_voice_gen_get then I don't see the need for
iiwu_voice_gen_incr (which I don't personally use anyways).

As far as iiwu_voice_query_ID.. I think this was created for real time
generator control sanity (I'm not using it right now, but perhaps that
says something :) For doing realtime generator control in Swami, I keep
track of the iiwu_voice_t pointers that belong to each voice for the
active sound (only the temporary selected audible at the moment). When a
generator is changed it is re-layered for that genrator only and the
value is updated for the affected voices with:

  iiwu_voice_gen_set (voice, genid, amount);
  iiwu_voice_update_param (voice, genid);

I think it was meant that the ID of the voice should be queried and
compared to the old ID to ensure that it was the same voice and still
active. I guess the side affect of it not being the same voice would be
that a different voice would get modulated or more likely, an inactive
voice would have an attempt to be modulated (is this bad?).

So for the simple case where one is just editing a sound and wants to
hear a generator change in real time, it seems to work okay. In a music
environment though, it might yield unexpected results. I don't really
like the ID querying, since while it does minimize the race condition
there still is a slight chance an inactive or different voice gets
changed.

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.

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

> 
> > Public version information would be nice. Something like:
> > FLUID_VERSION       "1.0.0"
> > FLUID_VERSION_MAJOR 1
> > FLUID_VERSION_MINOR 0
> > FLUID_VERSION_MICRO 0
> > 
> > I have this for Swami, I just created a version.h.in and substitute the
> > autoconf variables at configure time to create version.h which gets
> > installed. Would you like me to do this for FluidSynth?
> 
> Yes we should make the version available. Please go ahead if you feel
> like it.
> 

Sure thing. I'll just go ahead and commit it when done.

> Thanks, Josh!
> 

Glad to be able to help :)

> Cheers,
> P
> 

Cheerio,
        Josh





reply via email to

[Prev in Thread] Current Thread [Next in Thread]