Re: [iiwusynth-devel] Success!

[Josh Green]

On Tue, 2002-03-12 at 04:41, Peter Hanappe wrote:
> > 
> > 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.
> 

I'll think about it too, and give you suggestions should I have any.

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

I think a char * in a structure is okay in the case of samples, since
there is a lot of fields in it. I wouldn't want a callback for each item
in it :-) Death by callbacks.. Just need a way to know when the sample
structure isn't needed anymore.

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

Sounds fine to me, thats how Takashi Iwai's OSS based AWE/Live sound
font loader does things. And it does seem the most flexible.

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

Yes, this would be really cool and would get over memory space
limitations.

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

Nice hack * quality/hr ratio :)

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

That was the earliest for-warning I could think of. Any other ideas? I
wonder if there is anything in the MIDI standard that mentions waiting a
small amount of time after a program change before using the instrument?
Maybe not.

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

Cool..

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

The latter, drums use bank 128. The problem I saw wasn't the request for
a bunch of presets after load, it was that the preset loader gets called
with apparently corrupted bank numbers (completely out of range of
0-128). It occurs right after (or before, can't remember?) Bank 0:Preset
9 is fetched.

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

Cool. I'll let you know when I have Swami in CVS (along with
libsoundfont). Should be real soon now (TM).

> 
> Cheers! 
> Peter
> 

Things are getting exciting :) Cheers!
        Josh Green