Hallo, Larry Troxler hat gesagt: // Larry Troxler wrote:
I apologize for not having more time to look in to the following, but thought I'd mention a copule of glitches as a heads up -
(1) The "post" that a soundfont is loaded actually only happens for the _first_ soundfont loaded. I remember this from a while back, it's a bug in how fluid~ is interpreting a return value from some fluid function - don't remember the details now.
I looked it up now at http://www.fluidsynth.org/api/synth_8h.html#a35
fluid_synth_sfload returns the ID of the loaded SoundFont, or -1 in case of error.
Quickly guessed, this in around line 159:
if ( fluid_synth_sfload(synth, filename, 0) == 0)
should be that
if ( fluid_synth_sfload(synth, filename, 0) >= 0)
I tested it, it works, and I've put it in the CVS now.
(2) The following sequence hogs my machine: instantiate fluid~ , load a large soundfont, close the fluid~ patch, instantiate fluid~, load a large soundfont. I checked, and the appropriate fluid API function _is_ being called on deletion. Sure seems as if my soundfont isn't getting back to the free store somehow (it's about 50% of my RAM).
Hm, as you probably saw, I don't do any deleting or unloading besides calling delete_fluid_synth in the destructor of the external. The implementation of delete_fluid_synth in libfluidsynth does a lot of housekeeping then. Does this hangup also appear with the fluidsynth commandline app? Maybe it's a bug in libfluidsynth? Or maybe I need to keep track of all loaded soundfonts and call something like the func "fluid_synth_sfunload (Remove a SoundFont from the stack.)" accordingly.
Another thing: I briefly considered if it would be useful to include the internal effects of fluidsynth like reverb or chorus into fluid~. Until now I think this is better done outside the external, so all effects are disabled. But maybe there's a need for them, and it shouldn't be hard to implement.
ciao
Frank Barknecht _ ______footils.org__