On Sun, Nov 14, 2010 at 2:00 AM, David Henningsson <di...@ubuntu.com> wrote: >> >> libInstPatch also has a SoundFont voice cache system >> (IpatchSF2VoiceCache), which converts SoundFont presets, instruments >> or samples into an array of potential SoundFont voices (selected by >> MIDI note and velocity values). This means faster note-on >> calculations (than current FluidSynth), since a simple array of >> potential voices needs only to be searched, rather than doing >> calculations on the SoundFont tree at note-on time (its done at preset >> selection time instead). > > Hmm, interesting, but wouldn't this make preset selections very slow? >
I suppose the actual preset selection operation would be slower than FluidSynth's existing implementation, but "slower" is a pretty relative term here. Rather than re-calculating the voice parameters every note-on, its done only once when a preset selection occurs. I think its much better to do this during preset selection (a relatively infrequent operation compared to note-ons) than every note-on. This calculation is likely very fast to begin with, but that of course depends on the complexity of the instrument. Besides, theoretically libinstpatch would be just as fast with the first note (1 preset calculation done in both cases) and faster with any notes afterwards. In practice, this probably just means less CPU consumed per note-on. >> The way forward for adding this functionality into FluidSynth: >> - Create a new SoundFont loader using the Swami plugin as a basis >> (I'll contribute it as LGPL to FluidSynth, since its GPL in Swami). >> - Add 24 bit sample support to the FluidSynth SoundFont loader API >> - Probably some other things that aren't occurring to me at the moment > > We must also change/rewrite the interpolation routines as well to handle > sample data of different sizes, right? That's where the actual data comes > in. > True. I think it makes the most sense to duplicate the existing routines and adapt them to whatever format we decide on (rather than trying to make them handle multiple formats). Using real 24 bit (3 byte) samples doesn't really make sense from a synthesis standpoint, so I suggest we either go with 32 bit integers and/or floating point audio. >> Perhaps at some point FluidSynth might want to be GObject oriented, or >> it could add that as a wrapper around existing FluidSynth. The Swami >> plugin could be used as a basis for that purpose as well. > > I'm a little hesitant to adding GObject stuff to FluidSynth as I don't see > what we would gain from it. > I agree. >> So actually really not that much needs to be done. Since most of the >> code is already there, just needs to be properly integrated into >> FluidSynth as another loader option. Could even be made build time >> optional. I'd be happy to do this work! > > Contributions are welcome :-) But as you say, libInstPatch should probably > be a build time option. And we might want to split fluid_sample_t into an > fluid_rsample_t for the hard real-time side. It needs some design work. > Sounds good. It may be that we can do some minor changes though (addition of a new sample format) without breaking the binary compatibility of the API. Some analysis could then be done of the existing limitations for future changes of the SoundFont loader. >> I don't think it is possible though to get access to a single voice's >> current sample playback position, even if handling the rendering, from >> the public API though. Or am I overlooking something? > > You're correct, this is more of a discussion on how such a thing > could/should be implemented. > Ahh, ok, understood. >> I didn't understand what callbacks you are referring to. Was this >> related to the voice sample playback position item? > > I'm referring to the original question, which was "is there any way to > receive callbacks when voices finish/loop etc". > Understood. >> >> So fluid_sample_decr_ref() ultimately calls the "notify" method of the >> fluid_sample_t structure. So as long as that is thread safe, as you >> mention, that method could be used to do garbage collection. Assuming >> the sample wont somehow get used again. > > Could you elaborate on what "thread safe" means for you here? I think I was just referring to your original statement about there being a race condition where it could get called twice. > > // David Element _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
