Re: [iiwusynth-devel] Success!

[Peter Hanappe]

On Sat, 2002-03-09 at 03:32, Josh Green wrote:
> Yes! I finally got all the bugs worked out of my sfloader iiwusynth
> plugin for Swami. It works but isn't clean yet (still using a copy of
> Smurf to sequence it by connecting via ALSA :). This is real cool. In a
> day or so it should be really worthy of coolness. I will then check it
> in to CVS so anyone who wants can take part in the Swami mayhem.

Great!

> While working with the sfloader API I found some things that could use
> some improving:
> 
> 1. Preset iteration functions require sfloader to store the
> iiwu_preset_t data, which is a pain. It would be nice if these functions
> were changed to require the caller to pass in a iiwu_preset_t structure,
> which could then be filled and passed into successive invocations of the
> function. I've got it disabled for now, cuz I saw that it was just used
> for the command line interface.

Abslutely. I changed it.

> 2. I would like to do some more advanced sample management. Right now
> I've just got it hacked to load the samples at note on time (yes this is
> really really bad of course). I will eventually want to give the user an
> option of loading all the samples or loading on demand with a settable
> value for the max size of cached samples.
> 
> I need to be able to know when iiwusynth isn't using a sample anymore.
> I'm sure this is just something you haven't completed yet. It would be
> nice to tag sample data with a last used tick value which could be used
> when cleaning up old unused cached samples. 

Good point. Would like to think about how to do it.

> The iiwu_sample_t structure
> seems a bit messy still (have to copy name, 

Yep. I'll change that. Should be use a callback or a char* pointer?

> start isn't necessary, end
> could be size instead, cents?,

I know you convert (start, end) to (0,size) and update the sample data
pointer. That's because you edit the samples individually. I load all
the samples in one block so the (start,end) points are more convenient.
Since its more general I'll keep it that way. Just set start to 0 and
end to size.

> perhaps a user definable pointer like the
> other structures), 

Could do.

I'm also thinking that maybe the sfont doesn't have to give all the
samples at once. It gives a pointer to a buffer and tells the synth what
section of the sample data the buffer corresponds to. Whenever the
synthe needs the next section, it asks the sfont to load it. 

This would allow to stream large sample files without loading them into
ram. If we have a loader that handles wav files, we could sample large
soundfiles for disk with pitch control, pan, reverb, etc... all
controllable thru MIDI. File IO could be done in the background using a
thread pool. I'd love to start on it but I have some other stuff to work
on first. 

I'm sure this is also because the sfloader API is not
> quite finished yet :)

I was basically a 2 hour hack (add one hour for documentation and
email).

> I would like to get notification of when a Preset Change occurs so the
> samples can be loaded. Now that I think about it I could probably just
> do this in Swami.

Well, it might be useful for the large file streaming as well. However,
you might receive a ProgramChange, immediately followed by a NoteOn so
the ProgramChange is not sufficient to decide whether or not to preload
a sample. 

> I've decided to use iiwusynth as a plugin synthesizer
> and use my own audio and MIDI drivers (makes sense since I have to
> implement them anyways for other wavetable back ends). How does
> iiwusynth handle the noteon callbacks? What happens if the thread starts
> waiting because of loading sample data on demand?

The audio thread does not handle the noteon events. The thread that call
iiwu_synth_noteon does (your thread that is). So if the noteon request
takes too long (sample loading) the note will be played late, but the
sound is not interrupted.

> 3. After a sound font is loaded I get a series of sfloader_get_preset
> calls for bank 0 preset 0-8 followed by a couple of calls with a
> seemingly random bank number (out of range) preset number 0, then a
> get_preset for 128:0 then it continues with bank 0 preset 10-15.
> Strange. I haven't tried tracking it down yet, but this could probably
> confuse some peoples sfloaders :)

Ah! Well, when a user loads a soundfont, he expects to see piano 1 on
channel 1, ... So that's why I call sfloader_get_preset after a new
sfont has been loaded. The weird ones (128:0) are me looking for the
drum preset. I could have things totally wrong (I think I even send you
a mail about that a year ago) but I thought all the drum instruments are
either on bank 0, preset 128, or bank 128? Correct me if I'm wrong.

> Anyways. Despite these couple of issues, I'm really really happy and
> excited about getting iiwusynth finally connected to Swami :) It is
> really a nice API too. I think I might look into a similar type
> interface to some of the functions in libsoundfont. Pluggable object
> allocation and destruction would be nice to use MemChunks with Swami.
> Pluggable sample management would be neat too (already implimented but
> not very cleanly). Cheers!

Tell me when I should do a CVS checkout. When it's time I'll add the
compilation with libsoundfont to iiwusynth. Maybe I could include a
command that fires up Swami when the user wants to edit a sfont.


Cheers! 
Peter

>       Josh Green
> 
> 
> _______________________________________________
> iiwusynth-devel mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/iiwusynth-devel
>