[PD] Re: multiple fluid~'s sharing large soundfonts

Larry Troxler lt at westnet.com
Sun Mar 21 15:37:08 CET 2004


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





More information about the Pd-list mailing list