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.
(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).
Larry
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__
On Wed, 10 Dec 2003, Frank Barknecht wrote:
Hallo,
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.
Yes, that was it! Sorry again for not taking more time to (re)dig into it.
(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).
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.
That would be a strange API if that were the case. One of these days I'll try to look into it. I'll also try with the command line app.
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.
For me, it seems more versatile to use PD for this. But that's just my opinion.
There's one feature I thought of implementing, but from what I remember of how fluid is structured, it would require modifications to the fluid library: that is, to have an external which has a seperate output for each voice. The reason for this, is I would like to use my large piano sound font and process each voice independently. I can't use multiple instances of fluid~ because the sound font is too large. Alternatively, if there could be a way of different fluid~ instances sharing a sound font, that would work too, but would also require fluid lib mods.
Because this feature probably wouldn't interest too many people, I've decided to give up on the idea for now.
Larry Troxler
Hallo, Larry Troxler hat gesagt: // Larry Troxler wrote:
On Wed, 10 Dec 2003, Frank Barknecht wrote:
Another thing: I briefly considered if it would be useful to include the internal effects of fluidsynth like reverb or chorus into fluid~.
For me, it seems more versatile to use PD for this. But that's just my opinion.
It's mine, too. So someone else would need to implement it, if there is need. ;) But I'm not opposed to including it in the "official" fluid~.
There's one feature I thought of implementing, but from what I remember of how fluid is structured, it would require modifications to the fluid library: that is, to have an external which has a seperate output for each voice.
Because this feature probably wouldn't interest too many people, I've decided to give up on the idea for now.
It's not that far out: IIRC there was a discussion on fluid-dev some time ago if and how to implement exactly that, or at least more than stereo out. It might be tricky, though.
I also would like to see that, if alone for independent panning of different instruments (like hihat left, conga right and bassdrum in the center, which is not possible with fluidsynth currently, as panning is always per channel, IIR)
ciao
Frank Barknecht _ ______footils.org__
On Wednesday 10 December 2003 08:14, Frank Barknecht wrote:
Hallo,
Larry Troxler hat gesagt: // Larry Troxler wrote:
There's one feature I thought of implementing, but from what I remember of how fluid is structured, it would require modifications to the fluid library: that is, to have an external which has a seperate output for each voice.
Because this feature probably wouldn't interest too many people, I've decided to give up on the idea for now.
It's not that far out: IIRC there was a discussion on fluid-dev some time ago if and how to implement exactly that, or at least more than stereo out. It might be tricky, though.
I also would like to see that, if alone for independent panning of different instruments (like hihat left, conga right and bassdrum in the center, which is not possible with fluidsynth currently, as panning is always per channel, IIR)
ciao
Tackling your last paragraph first, I don't understand why that wouldn't be possible already, unless perhaps fluid doesn't yet support all the soundfont features. I think I really don't understand your second sentence that is in the parentheses - I don't understand what you mean by "per channel" - what is a channel in this context? Certainly in a drum soundfont, each sound could be assigned to a certain pan angle, no?
At any rate, as per what I was wanting to do, I think I wasn't clear enough, or else there was some ambiguity about the definition of "voice". By voice, I did not mean a separate instrument, but rather, an instance of a a note synthesizer attached to a single soundfont zone. What I was thinking of, is a single soundfont zone attached to my large Piano soundfont. However, instead of letting fluid mix everything together, I would like a seperate output for each overlappling instance of note events. This is quite different then having a seperate output simply for different instruments.
Larry
Hallo, Larry Troxler hat gesagt: // Larry Troxler wrote:
Tackling your last paragraph first, I don't understand why that wouldn't be possible already, unless perhaps fluid doesn't yet support all the soundfont features. I think I really don't understand your second sentence that is in the parentheses - I don't understand what you mean by "per channel" - what is a channel in this context? Certainly in a drum soundfont, each sound could be assigned to a certain pan angle, no?
"Channel" is a midi channel in this context (1-16). AFAIR panning pans the whole midi channel in fluidsynth, and not single notes. As drums in the General Midi standard are all in one channel (10), this is bad.
ciao
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
Larry Troxler