Re: [Swami-devel] Re: [iiwusynth-devel] Samples in sfloader API - revisited (was: Code freeze?)

[Josh Green]

On Fri, 2002-12-20 at 02:07, Peter Hanappe wrote:
> Josh Green wrote:
> 
> > The sample "start/end" parameters aren't very
> > useful outside the context of a SoundFont file, so a "size" parameter
> > can replace them. 
> 
> No, the default soundfont uses them. Let's keep that for the time being.
> 

Sure thing.. The start parameter is only an offset into the sample data
chunk in the original SoundFont file though. So outside of the file it
has no useful context (will always be 0). The End is equivelent to the
sample's size (once normalized by subtracting the Start).

> 
> > I'm not real familiar with the internals of FluidSynth, so this idea
> > might be stupid.. But.. What if sample info was property of a voice?
> > This would require the copying of the sample parameters and data pointer
> > into the voice when it is created (6 parameters, 1 pointer). So the
> > iiwu_sample_t passed to iiwu_synth_alloc_voice would then be just a
> > container for the values that get copied (allowing Swami to just have 1
> > iiwu_sample_t on the stack that it initializes). 
> 
> That's not a bad idea!
> 

Cool :)

> > This would probably
> > break the ability to cache the noise floor
> 
> That would be a problem indeed. Maybe we can replace that with a
> 'maximum' field, that indicates the maximum amplitude of the sample.
> This could be provided by the soundfont. In the worst case, it sets
> the maximum to 32767. For samples that loop during the release, the
> maximum should be the maximum of the loop.
> 

Perhaps FluidSynth could provide a function that would do the
calulations for us? So you might have something like:

iiwu_sample_calculate_noise_floor (iiwu_sample_t *sample);

Or maybe call it something more generic in case other optimizations are
added (iiwu_sample_cache_optimize.. Donno). This could be run on the
sample when it gets selected.

> 
> > The next thing to solve is then related to determining when sample data
> > can be freed. Now that I think about it my above suggestion doesn't
> > really improve this situation (may make it worse actually). The ideal
> > would be to know exactly when sample data is no longer being accessed (a
> > voice termination callback for instance), there are probably issues
> > relating to calling an unknown external function from within the
> > synthesis process though.
> 
> A function callback is acceptable if the it guarantees that it executes
> within a maximum delay.
> 

Cool, that would work then. All it would be doing is decrementing a
refcount (the sample data would still have other ref's on it by its
parent structures so it would just be calling a function and
decrementing a variable).

> 
> > So the next best thing would be to know when
> > a note ends (a noteoff event to compliment the noteon handler). A grace
> > period (say 20 seconds) could be allowed for volume envelope decay in
> > order to consider it safe to remove sample data... Hack hack.. 
> 
> Exactly: hack, hack. That's not the good solution, I think.
> 

Right, and not necessary if there is a voice off callback :)

> 
> So, if I make a short resume of all these propositions, iiwu_sample_t
> would look like this:
> 
> struct _iiwu_sample_t
> {
>    unsigned int start;
>    unsigned int end;
>    unsigned int loopstart;
>    unsigned int loopend;
>    int origpitch;
>    int pitchadj;
>    short* sample_data;
>    unsigned int samplerate;
>    short maximum;
>    void* user_data;
>    void (*notify)(void* user_data, int reason);
> };
> 
> When a 'noteon' event arrives, a preset calls 'iiwu_synth_alloc_voice'
> with a pointer to a sample structure. The sample structure is copied
> into the voice so the preset can reuse the sample structure immediately.
> 
> When the voice is finished, it calls
>    sample->notify(data, IIWU_SAMPLE_FREE).
> 
> This notify message is a real-time message and should be handled
> in a fixed, minimum time (just setting a flag, I would say).
> 
> The preset structure gets an additional function:
> 
>    void (*notify)(void* data, int reason);
> 
> When the preset is selected, the synthesizer calls
>    preset->notify(preset, IIWU_PRESET_SELECT);
> When the preset is unselected, the synthesizer calls
>    preset->notify(preset, IIWU_PRESET_UNSELECT);
> 
> The 'free' function in the soundfont structure
> should return a non zero value, if it can't be unloaded
> because samples are playing.
> 
> Is that about right?
> 

Yes yes yes! :) I like the preset notify callback. That will ease things
for determining when samples should be loaded (rather than watching MIDI
data, which isn't possible yet).

> Cheers,
> Peter
> 
> 

I was working with the new settings a little bit (haven't jumped into it
thoroughly yet). But I was wondering if it might be worth it to add an
integer type? This could take over boolean values and make adding
controls to things that should really be integer a lot easier. Or
perhaps even better would be to add a precision hint that says how many
decimal places after the decimal point are useful (so 0 for integers)?

Cheers! Keep up the good work.. :)
        Josh Green