[iiwusynth-devel] Re: Libsoundfont version of iiwusynth

[Peter Hanappe]

On Wed, 2002-03-06 at 02:23, Josh Green wrote:
> Well things are progressing rather well with Swami (new name for the
> Smurf Sound Font Editor). Its rapidly coming back to its old Smurfy self
> (with the nice new architecture of course). I'm at a stage now where I
> would like to start on the wavetable sub system. I've started porting
> iiwusynth over to libsoundfont just last night. I'm convinced that this
> is the best way to add support for iiwusynth to Swami. I don't recall
> what your own thoughts were on this. 

I'll explain below.

> I'm currently going with the
> thought of getting it working directly with Swami and then worrying
> about the details of how and if these changes will be put back into the
> iiwusynth source tree.
> Current thoughts on using libsoundfont with iiwusynth:
> 
> - Remove all iiwusynth sound font related structures and use the
> libsoundfont ones instead to store and manage sound font data
> - Keep the iiwusynth "synth" related structures for the iiwusynth
> synthesis engine and add other performance related structures
> - Load preset synth and performance structures (at channel preset
> selection time) from libsoundfont structures
>      a. switch to libsoundfont array generator storage mode
> - Use libsoundfont sample management to dynamically manage sample data
> and perhaps enable on demand loading of data (to conserve memory and for
> cases where sound font size exceeds system memory size).
>
> For the most part I don't see any performance related issues with using
> libsoundfont directly in the synthesis engine. The main thing is using
> array storage of generators (which I'm implementing support for in
> libsoundfont). This conversion, as well as loading of other iiwusynth
> performance related structures, would occur at channel preset selection
> time. 

Any thing that has to do with the selection of presets probably would
not be too crucial for performance. But we still have to be careful
though, since this might happen on a ProgramChange event during the
playback of a song. 




> Once this is done all synthesis would occur using iiwusynth's
> floating point type with the structures already defined.
> I was curious about a couple things:
> 
> 1. Is it absolutely necessary to have the generators as floats?
> SoundFont's themselves use 16 bit signed integers which I'm sure you
> know. Seems like sticking to this format up until the actual synthesis
> makes the most sense?

The synthesis is done in float and all the synthesis parameters are in
float. So at some point the generator values have to be converted to
float and it's best to do this once when a noteon events arrives than
every time in the synthesis loop.

> 2. I think I mentioned this before. But I believe there are some
> performance issues with converting floats to ints or the other way
> around on intel architectures? Perhaps this was only an issue with
> certain models of the x86 family, donno. 

There are macros that handle the conversion. But it is a subject of
discussion. Some say you need it, other say not to bother. I prefer the
simple standard float to int cast.

> Have you done any profiling yet?

Not yet.

> Anyways. I'll keep you up to date on whats going on with the
> libsoundfont port of iiwusynth. If you would like to help in the process
> let me know, I can put it in CVS. Cheers!

Now here comes the big part of my mail. This morning I made the changes
I had in mind to support soundfont loaders. It's quite a big change. I
haven't commited it yet because I'd like your opinion first. I attached
the new iiwusynth.h header file to this mail. The important part is the
section on SoundFont plugins starting at line 342.

Basically, you can dynamically add new SoundFont loaders. I changed the
current code so that the existing soundfont loader is added as the
default one. 

You can change the default loader by adding a new soundfont loader based
on libsoundfont. 

It would be useful to write an other "soundfont" loader, based on
libsoundfile that can load soundfiles and assigns them to key 60.

I defined a number of "interfaces" or structures with callback functions
for the interaction between the synthesizer and the soundfont
structures. The synthesizer needs to access a soundfont to get a preset.
It needs to access a preset to handle a note on event.

When a noteon event arrives the preset has to allocate a voice (or
voices) and set the generator values of the voice. I provided api
functions for that.

The use of the structures with function callback introduces a layer of
indirection. This should not introduce any performance penalty except
perhaps for the noteon event. 

The real data structures that are used to implement a soundfont are
completely opaque to the synthesizer. This means that Swami can use any
internal bookkeeping it likes, including editing the soundfont. 

Take a look at the header. I hope you like it. Give me a signal and I
can commit everything so you can see the full implementation.

Cheers!

Peter

>       Josh Green
> 
>

iiwusynth.h
Description: Text Data