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

[Josh Green]

On Wed, 2002-12-18 at 18:08, Peter Hanappe wrote:
> M. Nentwig wrote:
> > Hei,
> > 
> > The plan was:
> > 
> >>- Code freeze: wednesday, december 18th
> >>- Name change: thursday, december 19th
> >>- Xmas: wednesday, december 25th
> > 
> > 
> > Is the code freeze still on the schedule? In this case I'll leave the
> > 'iiwu' branch alone and start with 'fluid', as soon as it becomes
> > available.
> 
> Yep, today was supposed to be the code freeze. However, I'd like to call
> for a 'feature freeze'. There are many ideas that are still being
> discussed but I'd like to keep them for the next version.
> 
> In my opinion, what's most important for version 1.0 is that
> the synth is:
> 
> - compliant to the SoundFont 2.01 specs
> - compliant to the Midi specs
> - crickle-crackle and bug free
> - well documented and easy to use
> - readably coded
> 

It would be nice to add the issue relating to the handling of sample
data in the sfloader API to that list, please? :) I'm wracking my brain
to try and figure out a better way for things to be handled, but this is
really my only remaining issue now that the settings API has been solved
so eloquently.

Swami currently loads samples on demand. This is what I want the default
mode to be (nice when editing patch files), although it will be a bit
smarter than it is now (load samples when a preset gets selected instead
of when a note gets played!)...

Hmmm.. I just thought of a hack. I could just close the synth, expire
old cached samples, re-start synth again and re-load selected preset
from time to time, thereby insuring that I could clear out old samples..
Well if no solution arises, I think thats what I will do.

... Continuing with the idea of improving the API ...

I just realized that my old iiwusynth plugin in Swami creates a
iiwu_sample_t structure for every voice created (regardless if the
sample has been used before). Nice memory leak :) So I guess I need to
create a hash table to associate my own sample data objects
(IpatchSampleStoreRAM) with iiwu_sample_t structures, with the current
way of doing things.

A sample can be thought of as:

Parameters - (loop start/end, size, sample rate, root note, fine tuning)
Sample data - just a pointer

I left out the "name" field for parameters since I don't think it has a
use in current FluidSynth? The sample "start/end" parameters aren't very
useful outside the context of a SoundFont file, so a "size" parameter
can replace them. The sample flags aren't really useful in this context
either (indicates if sample is in ROM or that it is part of a stereo
pair), some way to handle stereo linked samples would still need to be
solved though, perhaps just another sample data pointer that if it was
set would then create a stereo voice (AFAIK this isn't handled yet in
FluidSynth).

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). This would probably
break the ability to cache the noise floor (although I realize that I
have been defeating this feature with the current plugin.. new
iiwu_sample_t every voice). This would cut down on the duration a sample
data reference is used (the life of a voice) and remove the requirement
of having to associate ones own structures with iiwu_sample_t's.

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.. 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.. Any
ideas??? I've rambled on enough..


> 
> Cheers,
> Peter
> 

Lates..
        Josh