Hello Micah, On Fri, Jun 6, 2014 at 5:13 PM, Micah Fitch <fitchmi...@gmail.com> wrote:
> Hey there, > I recently tried Swami again for the first time in a few years and was > really happy to see how far it's come and how stable it is! > > Glad to hear this! I've been working the past several months (after several years of little development activity) to fix a file corruption bug which required a lot of underlying infrastructure changes. This work expanded out into a lot of improvements in functionality and many many bug fixes. At this point there are only a couple more items on my task list, lots more testing to do and then I'll be releasing Swami 2.1.0 and libInstPatch 1.1.0. One of the features now in the development branch is GObject Introspection support, development which was sponsored by a generous donation. This means libInstPatch bindings (and Swami too, eventually) for Python, Ruby, Javascript, C++, etc ;-) The binding still needs some cleanup, but its surprisingly functional already. Its slated for the next release after this coming one. > Backstory: I found this beautiful 1.8 GB sf2 library called Evanessense > (here: http://www.synthfont.com/punbb/viewtopic.php?id=167 ). Needless > to say, the Calf Fluidsynth player wants to load the entire file into RAM > and that's not working so well. Same goes for Qsynth, the DSSI fluidsynth > plugin, etc. LinuxSampler refuses to load it due to some errors I didn't > quite understand. I'm not super interested in using LinuxSampler anyway at > this point in time. The whole single host/daemon thing is confusing to me > right now. > > Well low and behold, Swami is the only way I was able to check this > library out. It worked very well. There is a slight delay between > switching patches, but that's way better than the whole computer locking up > while 1.8 GB of unused samples are loaded into memory! > > Indeed. Loading instruments on demand is a nice feature that Swami/libInstPatch adds to FluidSynth. It also adds support for some other formats, in particular Spectralis SLI, which a developer added last year. DLS and GigaSampler have much weaker synthesis support at this point, so I don't usually mention it. This could be improved, however. Currently this all works by "messaging" other formats into SoundFont style voices, which FluidSynth can consume during note-on events. One issue that I'm currently running into, is that Swami at the moment never frees any samples that have been loaded on demand (so memory consumption keeps growing). Reason being, that the FluidSynth API currently lacks the ability to tell when it is safe to release a sample in memory. This could of course be added to the FluidSynth API. I'm interested in adding other improvements as well, once Swami starts demanding additional features (24 bit audio support, streaming audio, etc). So after investigating I realize that Swami is doing this using > libinstpatch, and that there are plans from a while back to integrate > libinstpatch into fluidsynth. Very exciting! What's the scoop on these > plans? I'm tempted to try and hack libinstpatch support into the calf > fluidsynth LV2 plugin or something just so I can use this Evanessense > library. But if that would come automatically in a future fluidsynth > release, it'd be an unnecessary effort. > > So anyhow, I'm curious about this. Right now I can't even have multiple > instances of a 300 MB soundfont without really taking up lots of > unnecessary memory. It'd be nice to change that. > > P.S. Here's a totally off the wall idea... to make an LV2 plugin based on > Swami. That's kind of intriguing to me for some reason! But would > probably be a good amount of work. > > There hasn't been any direct work on this. However, the code is pretty much already there to adapt to a standalone version. It would basically mean lifting the FluidSynth plugin from Swami and creating a library out of it, which utilizes libInstPatch. This essentially creates a FluidSynth GObject, which has all of the settings available as GObject properties. An added benefit of this is GObject Introspection bindings almost for free. The other component that Swami adds is a MIDI event routing network, but it probably makes sense to do something independent from libSwami, rather than having the extra complexity that the whole SwamiControl event/value network subsystem adds (although it is a pretty cool system for model view controller routing of values and events - used heavily in Swami itself). Some other things to consider in regards to FluidSynth. I think it makes the most sense to have the GObject-ification be compile time optional. It could then either be a separate shared library (libgfluidsynth or something), which utilizes libfluidsynth or perhaps be integrated into the same library (although this presents issues as far as there being the potential to have both versions with or without GObject support floating around - although I'd imagine any distribution based packages would include support for it). One interesting possibility though with that route, is that FluidSynth could potentially add this additional functionality (on demand loading, support for other formats, etc) behind the scenes and remain compatible with existing front ends. Some exciting things to think about. Timely email by the way, in regards to where I'm at with my current development efforts. If you are interested in heading up adding libInstPatch support to FluidSynth, I'd welcome your enthusiasm and assistance! I would definitely be available to help with this effort (it will be a few weeks though before I can delve into it). We could create a separate development branch in the FluidSynth git repository for this project. Cheers! Element Green
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
