[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] fluidsynth~
Re: [fluid-dev] fluidsynth~
Thu, 26 Feb 2004 17:36:47 +0100
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:
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"
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:
// list input calls fluid_note(...)
FLEXT_CADDMETHOD_(c,0, "list", fluid_note);
// some alias shortcuts:
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);
key = GetAInt(argv);
vel = GetAInt(argv);
The only creation argument I use is the full path to a soundfont file.
Frank Barknecht _ ______footils.org__