I've made a modifcation to fluid~ that solves a problem I had been having. I thought I would mention this here in case there's interest in making this a part of the official fluid.
The problem I had with fluid~ was this: I wanted to load a large piano soundfont, but be able to process different voices (piano tones) seperately. For example, I might want to apply a filter envelope to each piano tone seperately.
Initially I thought of modifiying fluid~ to provide a seperate audio for each fluidsynth voice, but this doesn't seem possible without actually modifying the fluidsynth code.
Then I thought of using multiple fluid~ objects, with incoming notes routed to different fluid~'s using some algorithm to split up the voices. However, because of the size of the soundfont I wanted to use, it wouldn't be practical to load a copy of the sounfont in to each of the fluid~'s.
So, what I have done is modify fluid~ so that if you send a "[ load sounfont.sf2 share (", it uses the fluid API to load a single instance of the sounfont, and then add that one object to all the active fluid~'s. Naturally, this API could be refined, but the concept seems to work so far.
So, if anyone is interested in this kind of application, I could post the modifactions to fluid/main.cpp. I would do this now, except that it's probable that nobody but me has an application for this feature, and also because I'd want to hear ideas about the PD client interface - certainly it would be nicer to have something better than a message that blindly adds a sounfont to all of the active fluid~'s - but maybe this is fine after all.
Larry Troxler
Larry Troxler lt@westnet.com writes:
So, if anyone is interested in this kind of application, I could post the modifactions to fluid/main.cpp. I would do this now, except that it's probable that nobody but me has an application for this feature, and also
I would, actually, be interested in this...
Hallo Larry, Larry Troxler hat gesagt: // Larry Troxler wrote:
The problem I had with fluid~ was this: I wanted to load a large piano soundfont, but be able to process different voices (piano tones) seperately. For example, I might want to apply a filter envelope to each piano tone seperately.
Then I thought of using multiple fluid~ objects, with incoming notes routed to different fluid~'s using some algorithm to split up the voices. However, because of the size of the soundfont I wanted to use, it wouldn't be practical to load a copy of the sounfont in to each of the fluid~'s.
So, what I have done is modify fluid~ so that if you send a "[ load sounfont.sf2 share (", it uses the fluid API to load a single instance of the sounfont, and then add that one object to all the active fluid~'s. Naturally, this API could be refined, but the concept seems to work so far.
So, if anyone is interested in this kind of application, I could post the modifactions to fluid/main.cpp. I would do this now, except that it's probable that nobody but me has an application for this feature, and also because I'd want to hear ideas about the PD client interface - certainly it would be nicer to have something better than a message that blindly adds a sounfont to all of the active fluid~'s - but maybe this is fine after all.
I am *very* interested in this, because I tend to do things similar to your use case, which also would profit from shared soundfont-memory.
I have another idea in regard to the API. Would it be apt, to make the sharing explicit in a second creation argument to fluid. I'm thinking of the way, that the "pool" external make a shared data space that is named by creation argument or changed through a "set somepool" message.
A similar case would be the table family like [tabread tablename] which get the name of a shared array as creation arg, or with "set".
This would look so, that [fluid~ /soundfonts/nskit.sf2 DRUMS] will share its data with another [fluid~ /soundfonts/nskit.sf2 DRUMS] instance, but not with [fluid~ /soundfonts/fluid.sf2 PIANO]
A message "load /soundfonts/tb303.sf2" to the "DRUMS"-tagged fluid~s will change them all, but not the "PIANO"-tagged. Doing a "set DRUMS" to the PIANO-fluid~ could set the soundfont of that one to tb303.sf2.
Does this make sense?
ciao
Frank Barknecht _ ______footils.org__
On Sunday 21 March 2004 06:30, Frank Barknecht wrote:
I have another idea in regard to the API. Would it be apt, to make the sharing explicit in a second creation argument to fluid. I'm thinking of the way, that the "pool" external make a shared data space that is named by creation argument or changed through a "set somepool" message.
A similar case would be the table family like [tabread tablename] which get the name of a shared array as creation arg, or with "set".
This would look so, that [fluid~ /soundfonts/nskit.sf2 DRUMS] will share its data with another [fluid~ /soundfonts/nskit.sf2 DRUMS] instance, but not with [fluid~ /soundfonts/fluid.sf2 PIANO]
Ah, that's the idea I was looking for. This seems logical and consistent with the rest of PD, but I think there are some details missing.
In your example, what should happen if an object [fluid~ /soundfonts/trumpet.sf2 DRUMS] is added? Should/can this be undefined behavior?
Also, using this method, how would you create a fluid~ object that is in a group with out initially loading a soundfont? For this reason should we instead use an option syntax like "fluid~ [sounfont] group=<groupname>"?. If done this way, this syntax could also be handing for specifying fluidsynth parameters like number of voices.
A message "load /soundfonts/tb303.sf2" to the "DRUMS"-tagged fluid~s will change them all, but not the "PIANO"-tagged.
By "change", don't you really mean "add"? The way load currently works is that the soundfont is added to the synthesizer; it doesn't replace any currently loaded soundfonts.
Doing a "set DRUMS" to the PIANO-fluid~ could set the soundfont of that one to tb303.sf2.
This one also isn't clear to me because I don't know what you mean by "the soundfont" if there is more than one loaded. Also, just to be clear, you're suggesting a new "set" message?
Does this make sense?
Overall, yes, except for those details.
Larry Troxler
Hallo, Larry Troxler hat gesagt: // Larry Troxler wrote:
On Sunday 21 March 2004 06:30, Frank Barknecht wrote:
I have another idea in regard to the API. Would it be apt, to make the sharing explicit in a second creation argument to fluid. I'm thinking of the way, that the "pool" external make a shared data space that is named by creation argument or changed through a "set somepool" message.
A similar case would be the table family like [tabread tablename] which get the name of a shared array as creation arg, or with "set".
This would look so, that [fluid~ /soundfonts/nskit.sf2 DRUMS] will share its data with another [fluid~ /soundfonts/nskit.sf2 DRUMS] instance, but not with [fluid~ /soundfonts/fluid.sf2 PIANO]
Ah, that's the idea I was looking for. This seems logical and consistent with the rest of PD, but I think there are some details missing.
In your example, what should happen if an object [fluid~ /soundfonts/trumpet.sf2 DRUMS] is added? Should/can this be undefined behavior?
Uhm, that's a hard one. Undefined behaviour should be avoided, at least undefined API behaviour. We will have to think deeper about this, but I won't find more time for this today anymore.
Also, using this method, how would you create a fluid~ object that is in a group with out initially loading a soundfont? For this reason should we instead use an option syntax like "fluid~ [sounfont] group=<groupname>"?. If done this way, this syntax could also be handing for specifying fluidsynth parameters like number of voices.
This looks like a case for flext-attributes. But I'd like to mention, that Norbert Schnell of ICRAM recently developed a fluidsynth~ object for Max/MSP (OS9 and -X), which I would like to be compatible with. See http://www.ircam.fr/equipes/temps-reel/maxmsp/fluidsynth.html for source code. This might rule out attributes.
A message "load /soundfonts/tb303.sf2" to the "DRUMS"-tagged fluid~s will change them all, but not the "PIANO"-tagged.
By "change", don't you really mean "add"? The way load currently works is that the soundfont is added to the synthesizer; it doesn't replace any currently loaded soundfonts.
Yes, I was unclear here. Of course it adds.
Doing a "set DRUMS" to the PIANO-fluid~ could set the soundfont of that one to tb303.sf2.
This one also isn't clear to me because I don't know what you mean by "the soundfont" if there is more than one loaded.
s/soundfont/soundfonts/g
I often forget that more than one soundfonts get loaded with load.
Also, just to be clear, you're suggesting a new "set" message?
It doesn't have to be "set", but basically: yes. Or we could enforce, that soundfont-sharing *has* to be specified by creation argument. This would also free us a bit from some of above problems. But adding a "set" message should probably be discussed with Norbert as well. Maybe we should take this discussion over to fluid-dev (as well)?
Now I'm off for the rest of (Europe) day.
ciao
Frank Barknecht _ ______footils.org__
This looks like a case for flext-attributes. But I'd like to mention, that Norbert Schnell of ICRAM recently developed a fluidsynth~ object for Max/MSP (OS9 and -X), which I would like to be compatible with. See http://www.ircam.fr/equipes/temps-reel/maxmsp/fluidsynth.html for source code. This might rule out attributes.
Thanks, I didn't know about that. I'll write Norbert a note about this. At first glance, it looks like this wouldn't cause any incompatibilities, but it's difficult to say just by looking at the source code. And the help patch is apparently in some kind of non-ascii format.
Doing a "set DRUMS" to the PIANO-fluid~ could set the soundfont of that one to tb303.sf2.
Oh, now I understand. The "set" message would change the group tag of the soundfont. So you would want to unload all the PIANO soundfonts and load the DRUM fonts? If so, I'm inclined to wait on this one; remember that there is not even a message to unload sound-fonts yet (although this would be easy to add).
It doesn't have to be "set", but basically: yes. Or we could enforce, that soundfont-sharing *has* to be specified by creation argument. This would also free us a bit from some of above problems.
I'm not exactly sure what you mean here - not allow the use of the load message for sharing soundfonts? If so, we'd have to then decide how to specify multiple soundfonts at creation time.
Maybe we should take this discussion over to fluid-dev (as well)?
Frank, are you already on that list by any chance? If so, maybe you'd be the better person to bring it up(?)
Hallo, Larry Troxler hat gesagt: // Larry Troxler wrote:
Doing a "set DRUMS" to the PIANO-fluid~ could set the soundfont of that one to tb303.sf2.
Oh, now I understand. The "set" message would change the group tag of the soundfont. So you would want to unload all the PIANO soundfonts and load the DRUM fonts?
Yes, for consistency it should work like that. That would be another reason to enforce static soundfont groups by only allowing creation arguments.
It doesn't have to be "set", but basically: yes. Or we could enforce, that soundfont-sharing *has* to be specified by creation argument. This would also free us a bit from some of above problems.
I'm not exactly sure what you mean here - not allow the use of the load message for sharing soundfonts? If so, we'd have to then decide how to specify multiple soundfonts at creation time.
No, I mean not allow the "set" message above. So if you'd want to use shared soundfonts, you would have to use the creation argument. You would not be allowed to change that share groups later.
ciao
Frank Barknecht _ ______footils.org__
Hallo,
while we're at it, I have commited a tiny, but very important change to fluid~ in CVS: I added:
fluid_synth_program_reset(synth);
to the soundfont load routine, which resets banks and program changes after loading a new soundfont. This does fix the problem, that you needed to send bank/prog messages by hand to hear sounds.
ciao
Frank Barknecht _ ______footils.org__
On Sunday 21 March 2004 08:28, Frank Barknecht wrote:
Hallo,
while we're at it, I have commited a tiny, but very important change to fluid~ in CVS: I added:
Mine isn't/won't be tiny :-) I'm not changing much of what's there but a lot is being added. Considering then, that the diff won't be too usefull anyway, do you object to me de-inlining those public member functions of the fluid class? It would make this easier to read I think.
Larry Troxler
Hallo, Larry Troxler hat gesagt: // Larry Troxler wrote:
Mine isn't/won't be tiny :-) I'm not changing much of what's there but a lot is being added. Considering then, that the diff won't be too usefull anyway, do you object to me de-inlining those public member functions of the fluid class? It would make this easier to read I think.
Yep, jus' do it, mate.
ciao
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
Larry Troxler -
Michal Seta