Re: [fluid-dev] fluidsynth~

[Frank Barknecht]

Hallo,
Norbert Schnell hat gesagt: // Norbert Schnell wrote:

> Well, sorry I knew... I had a look at this nice piece of code of fluid~.
> 
> Don't take that wrong but I am happy to have something which depends 
> already on FluidSynth and Max/MSP and CodeWarriror and MacOS X and my 
> abilities of getting this done in some hours and didn't want to handle 
> one more thing such as flext.

Yes, this probably is exactly the problem, several others ran into:
dependency hell. 

A very early version of fluid~ (iiwu~ at that time, written by Larry
Troxler initially) did not use the library of iiwusynth - because it
wasn't written then -, but instead just copied the central source
files of iiwusynth into the external code directly. This way, the old
iiwu~ external was a stand-alone external not dependent on any
library. In the long run I am a fan of using libraries, though. They 

> Nevertheless: flext is a great thing!
> 
> Than there are some funny details in doing something which integrates 
> really well with Max/MSP (like the file open box), which I didn't see 
> how to get into flext.

I know, that flext-author Thomas Grill is actually using Max/MSP on
Mac more than he uses Pd (at least live), so he probably is open for
such suggestions. In Pd, I just use the [openpanel] approach. 

> On the other side I am absolutely in favor of keeping those FluidSynth 
> incarnations compatible concerning the accepted messages (and their 
> effect). To get one step further in the "have a look to my source code" 
> business 

I now found, that I cannot find the source?! Anyways, the source
probably isn't that important, it's the interface we should agree on.
All else is a matter of taste. ;) 

> I'll make sure that fluidsynth~ will implement the same 
> messages as fluid~ and try to post a summary of the other few messages 
> for the FX and the modulation (generators) to this mailing list.

Cool. I'd then just take these as a base when implementing them in
fluid~ eventually. I think, that interface compatibility is the most
important issue, using different implementations on Max, Pd or jMax
then doesn't matter to the user. In my choices for interfacing
libfluidsynth I generally followed the naming conventions used in
fluidsynth.h with some abbreviations for convenience and to save
typing in patches. 

Here is a relevant part: 

FLEXT_CADDMETHOD_(c,0,"init",  fluid_init);
FLEXT_CADDMETHOD_(c,0,"load", fluid_load);
FLEXT_CADDMETHOD_(c,0,"note", fluid_note);
FLEXT_CADDMETHOD_(c,0,"prog", fluid_program_change);
FLEXT_CADDMETHOD_(c,0,"control", fluid_control_change);
FLEXT_CADDMETHOD_(c,0,"bend", fluid_pitch_bend);
FLEXT_CADDMETHOD_(c,0,"bank",  fluid_bank);

// list input calls fluid_note(...)
FLEXT_CADDMETHOD_(c,0, "list",  fluid_note);

// some alias shortcuts:
FLEXT_CADDMETHOD_(c,0,"n",  fluid_note); 
FLEXT_CADDMETHOD_(c,0,"p",  fluid_program_change);
FLEXT_CADDMETHOD_(c,0,"c",  fluid_control_change);
FLEXT_CADDMETHOD_(c,0,"cc", fluid_control_change);
FLEXT_CADDMETHOD_(c,0,"b",  fluid_pitch_bend);

Those fluid_X methods are just wrappers around the libfluidsynth
methods, which are called like:

void fluid::fluid_note(int argc, t_atom *argv)
                // ...
                int   chan, key, vel;
                chan  = GetAInt(argv[0]);
                key   = GetAInt(argv[1]);
                vel   = GetAInt(argv[2]); 
                fluid_synth_noteon(synth,chan-1,key,vel);
                // ...

The only creation argument I use is the full path to a soundfont file.

ciao
-- 
 Frank Barknecht                               _ ______footils.org__