morning all,

I take it all back and assert the opposite!

Regarding the following fluid~ error:

...

...

...

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210693952 (LWP 24068)] 0xb7dcb589 in free () from /lib/tls/i686/cmov/libc.so.6 (gdb) backtrace #0 0xb7dcb589 in free () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7d1e639 in delete_fluid_synth () from /usr/lib/ libfluidsynth.so.1 #2 0x08237bd0 in ?? () #3 0x0811ace0 in mstack.5434 () #4 0xbfd76828 in ?? () #5 0xb7d47366 in fluid::fluid_init (this=0x0, argc=-1210746848, argv=0xb7caf730) at fluid/main.cpp:251 Previous frame inner to this frame (corrupt stack?)

This is just a plain old initialization bug in fluid/main.cpp. It seems that fluid::fluid() calls fluid::fluid_init(), which calls libfluidsynth's delee_fluid_synth() if (this->synth != NULL), which is complete and utter hogwash at initialization time unless this->synth has been initialized to NULL, which (apparently) happens just in case we're using flext's new() and delete() (!defined(FLEXT_USE_CMEM)) rather than pd's getbytes() (defined(FLEXT_USE_CMEM)), sooooo:

Frank, would you have anything against my chaning line 51 of fluid/main.cpp in CVS from:

fluid(int argc, t_atom *argv)

to:

fluid(int argc, t_atom *argv) : synth(NULL)

?

Finding this one at least makes me feel somewhat better, although readanysf~ is still giving me headaches...

marmosets, Bryan