Pd-dev January 2004

pd-dev@lists.iem.at

24 participants
35 discussions

Re: [fluid-dev] fluid~ crashes
by Frank Barknecht 04 Jan '04

04 Jan '04

Hallo, Eric Van Buggenhaut hat gesagt: // Eric Van Buggenhaut wrote: > On Sat, Jan 03, 2004 at 01:40:54PM +0100, Frank Barknecht wrote: > > Disabling LADSPA in libfluidsynth indeed did the trick for fluid~: > > fluid~ is up and running again now. I do wonder: The fluid-settings I > > used inside fluid~ explicitly disabled ladspa (as copied over from the > > fluidsynth source code). Normally it shouldn't go that ladspa path > > anyway then, not? > > > > <fluidsynth debian package maintainer> > At the moment I build libfluidsynth packages with LADSPA enabled. > Do you think I should remove LADSPA support ? > </fluidsynth debian package maintainer> That's a hard one. On my machine fluid~ from pd-flext-ext does not work the way libfluidsynth currently is compiled i.e. with ladspa enabled. I cannot try this on another machine. This seems to be a bug not in pd-flext-ext, which Guenther Geiger maintains, but in fluidsynth. I don't know how many people use LADSPA plugins in fluidsynth or how many people use fluid~ in Pd on Debian... Maybe just wait a little and see, if Josh finds something? ciao -- Frank Barknecht _ ______footils.org__

2 1

Re: [fluid-dev] fluid~ crashes
by Frank Barknecht 03 Jan '04

03 Jan '04

Hallo, Josh Green hat gesagt: // Josh Green wrote: > Cool. From looking at the backtrace a quick fix would probably be to > disable LADSPA support in FluidSynth (you probably aren't using it > anyways?) Just don't explicitly enable it during configure time and it > should not be compiled. I did that now (BTW: --enable-ladspa=no and --disable-ladspa did *not* disable LADSPA, although that would be nice. But leaving out the option at all as you suggested worked). Disabling LADSPA in libfluidsynth indeed did the trick for fluid~: fluid~ is up and running again now. I do wonder: The fluid-settings I used inside fluid~ explicitly disabled ladspa (as copied over from the fluidsynth source code). Normally it shouldn't go that ladspa path anyway then, not? fluid~ normally disables all effect processing because users can do that in Pd, which is a modular synth, themselves if they want to. Pd is a LADSPA host. > There may be something more sinister going on > here though, since I really don't see how its getting to > delete_fluid_settings() from fluid_settings_getint(). Something might be > broken with the LADSPA code. I may have to get ~FluidSynth installed to > figure this out. Any quick pointers to getting things setup? If you're on Debian unstable the easiest way to get this up and running is to do: $ apt-get install pd-flext-ext or to get the source with build-dependencies $ apt-get build-dep pd-flext-ext ; apt-get --build source pd-flext-ext fluid~ is part of the pd-flext-ext package. The CVS way is to check-out the externals-tree from pure-data.sf.net and then first build externals/grill/flext and after that externals/footils/fluid with some editing of the respective config-pd-linux.txt files in both directories to match your paths. Of course you also need Pd installed. ciao -- Frank Barknecht _ ______footils.org__

1 0

Re: [fluid-dev] fluid~ crashes
by Frank Barknecht 03 Jan '04

03 Jan '04

Hallo, Josh Green hat gesagt: // Josh Green wrote: > Run Pd: > (gdb) r > > Do what you would normally do to get it to crash. After it crashes get a > back trace: > > (gdb) bt > > That should give you a list of all the function calls leading up to the > crash. Post that to this list, then I might be able to help more. So, here's the full backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 16741)] 0x40458abe in delete_fluid_hashtable () from /usr/lib/libfluidsynth.so.1 (gdb) bt #0 0x40458abe in delete_fluid_hashtable () from /usr/lib/libfluidsynth.so.1 #1 0x40458b0e in fluid_hashtable_lookup () from /usr/lib/libfluidsynth.so.1 #2 0x40467f28 in delete_fluid_settings () from /usr/lib/libfluidsynth.so.1 #3 0x404692ad in fluid_settings_getint () from /usr/lib/libfluidsynth.so.1 #4 0x4045aab2 in fluid_LADSPA_run () from /usr/lib/libfluidsynth.so.1 #5 0x4046d185 in fluid_synth_one_block () from /usr/lib/libfluidsynth.so.1 #6 0x4046cb80 in fluid_synth_write_float () from /usr/lib/libfluidsynth.so.1 #7 0x4042938a in fluid::m_signal(int, float* const*, float* const*) () from /usr/lib/pd/extra/fluid~.pd_linux #8 0x4033bdcd in flext_dsp_single::dspmeth(long*) () from /usr/lib/pd/extra/xsample.pd_linux (gdb) ciao -- Frank Barknecht _ ______footils.org__

1 0

Re: [fluid-dev] fluid~ crashes
by Frank Barknecht 03 Jan '04

03 Jan '04

Hallo Josh, Josh Green hat gesagt: // Josh Green wrote: > It seems you haven't received a reply to this problem, so I'll see if I > can help any. I haven't really used Pd that much or even tried the > FluidSynth binding for it, and I won't likely get around to tracking it > any time soon, so I don't think I can be of much help, but.. > If you want to try and track it down yourself here are some tips: > > Compile FluidSynth with debugging support enabled (./configure > --enable-debug I believe, --help to get a list of options). > Fire up Pd with GDB 'gdb pd'. > Tell GDB to not trap thread related signal SIG32: > (gdb) handle SIG32 nostop noprint > > Run Pd: > (gdb) r > > Do what you would normally do to get it to crash. After it crashes get a > back trace: > > (gdb) bt > > That should give you a list of all the function calls leading up to the > crash. Post that to this list, then I might be able to help more. > Cheers. Thank you very much for your instructions. I will build fluid with debug now, and I also tried to run pd under gdb now (still without the debugging symbols. After the crash I got this: -- fluid~ with flext --- (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 1726)] 0x4045bad0 in fluid_str_hash () from /usr/lib/libfluidsynth.so.1 (gdb) bt #0 0x4045bad0 in fluid_str_hash () from /usr/lib/libfluidsynth.so.1 #1 0xbfffe620 in ?? () (gdb) Debugg version following later. ciao -- Frank Barknecht _ ______footils.org__

1 0

partial recompilation of DSP graph
by Thomas Grill 02 Jan '04

02 Jan '04

Hi Miller, hi all, exploring the possibilities of avoiding clicks when creating/connecting/deleting DSP objects i found a short note in the PD source at d_ugen.c/ugen_done_graph: /* once the DSP graph is built, we call this routine to sort it. This routine also deletes the graph; later we might want to leave the graph around, in case the user is editing the DSP network, to save having to recreate it all the time. But not today. */ Hmmm, does this mean that there will be a chance to do only a partial recompilation of the graph (as a kind of diff) ? (At least) For me it is extremely it's extremely important to get PD to - load large patches - edit the DSP structure without having clicks in the audio - and for that i have been trying around in PD with several modifications (like multiple dsp chains) but none is fundamental enough to _guarantee_ click-freeness. Partial recompilation (preferably as a background thread) seems to be a real choice. Any other ideas? best greetings, Thomas

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev January 2004