[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] fluidsynth~
From: |
Frank Barknecht |
Subject: |
Re: [fluid-dev] fluidsynth~ |
Date: |
Thu, 26 Feb 2004 17:36:47 +0100 |
User-agent: |
Mutt/1.5.4i |
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__