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

[Peter Hanappe]

Josh Green wrote:

> It would be nice to add the issue relating to the handling of sample
> data in the sfloader API to that list, please? :) 

Yes, let's tackle that.


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


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

Yes, we can remove the 'name' field.

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

> The sample flags aren't really useful in this context
> either

Yes, we can remove the flags.

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

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


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

Agree.

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


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


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?

Cheers,
Peter


> > Cheers,
> > Peter
>
>
> Lates..
>         Josh
>
>
>
> _______________________________________________
> iiwusynth-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/iiwusynth-devel