On Sun, Jun 8, 2014 at 2:50 AM, David Henningsson <di...@ubuntu.com> wrote:
> > Ok, thanks for the explanation. Is the note-on processing less than what's > currently used in FluidSynth? If so one could consider moving some > processing time from note-on time to preset selection time in FluidSynth as > well. Not sure if this would be a good idea, because we want FluidSynth to > do instrument switches fast too. > > The difference is that in FluidSynth it iterates over the presets, instruments and samples to calculate the generator values at note-on time. On the other hand, libInstPatch and the IpatchSF2VoiceCache object creates an array of possible voices and their trigger criteria. This array can be quickly iterated over when a note event occurs and all the matching voices created at that time (with the parameters already calculated). This should usually be quicker (at note on time) than iterating over the tree of items and makes a lot more sense too when converting between other instrument formats for SoundFont synthesis through FluidSynth. Indeed it probably takes a little more time during program change, but this is time that is spent once, instead of on each note-on event and likely doesn't equal much, since its pretty simple math. One thing it does mean though, is more memory consumption for the voice cache. In theory the voice selection could likely be made even quicker, from what it is now, through clever range indexing, rather than iterating over all the possible voices. > > I see libInstPatch/Swami as being an easy platform to leverage off of to >> achieve a lot of neat things. I don't necessarily suggest that >> libinstpatch becomes a required dependency though, so that it can still >> get built in a more stripped down form. >> >> A benefit from having libInstPatch support, is that as more instrument >> formats are added to libInstPatch, FluidSynth would benefit directly >> from it, without any extra work (as long as the synthesis constructs of >> said format can be mapped to SoundFont centric parameters). >> > > You might need to educate me a little on the history here, how come that > you made libInstPatch in the first place instead of writing the same > functionality inside FluidSynth? > > Sure. A brief history of FluidSynth, Swami and Smurf SoundFont Editor. I started Smurf SoundFont Editor back in the late 90s sometime.. Not sure exactly when now. The heart of this was the SoundFont load/save code, which I used some of Takashi Iwai's code as a reference. Smurf required a SoundBlaster AWE32 or 64 (the Linux driver also being a creation of Takashi). At some point I was contacted by Peter Hanappe who mentioned that he was working on a soft synthesizer (IIWU Synth at the time) and that he had borrowed the SoundFont loading source code from Smurf and adapted it to his synthesizer. We then began discussing the idea of having an API in his synthesizer which would allow Smurf to utilize it for synthesis on any soundcard. I met him in person in my travels in Europe and we discussed this more. Not long after returning from my trip, he had created an API for this purpose. I decided to rename Smurf to Swami at that point in time. The source code for Smurf/Swami went through several iterations of re-writes and I realized it would be advantageous to have the SoundFont processing code be a shared library, which other programs could utilize and to which additional instrument formats could be added. Thus was born libInstPatch. The focus of which was editing of instruments. Me and Peter had discussed the idea of keeping the projects separate, since they both had their own niche and didn't necessarily need to depend on one another. I dropped AWE hardware synth support from Swami though (due to some limitations with the driver), thus making FluidSynth a requirement more or less (at least if you want to hear anything ;-) The name FluidSynth came out of a brainstorm session between me and Peter, in response to his intent to make the old name "IIWU Synth" something more easy to pronounce (it stood for If I Was U Synth, which a lot of people tried to pronounce). I think FluidSynth was one of the names I threw over the wall (in a long list of ideas), but Peter ultimately chose it as his favorite. It might be nice to create a little history page on the Wiki, where others could contribute their part of the story too. Its an application that has made its way around and its nice to get a picture of who was all involved in its creation. > > // David > > Cheers! Element
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
