Pd-dev September 2005

pd-dev@lists.iem.at

18 participants
48 discussions

loading externals/abstractions containing non-alphanumerics
by IOhannes m zmoelnig 11 Sep '05

11 Sep '05

hi all problem: ======== when i split the zexy-library into single externals i came to a point where it didn't work at all: with objects that contain non-alphanumeric characters. the only exception that currently works with pd are the ~-objects: if pd is searching for an object [foo~] and it finds a library foo~.pd_linux it will then try to jump to the function "foo_tilde_setup()" (instead of "foo~_setup()" which is illegal) unfortunately this does not work with other characters, so there is currently no way to do an object "my+" as an external (all compilers will have problems with the "my+_setup()"-function). of course we could replace "+" by "plus" when calling the setup()-function but i think, this only moves the problem and does not solve it. another (similar) problem is, that certain crude filesystems don't like certain non-ascii characters at all: e.g. ">~.pd" is quite impossible to create (and access) on certain systems. proposal: ========= so what i would like would be as simple as an alternative way of loading externals/abstractions that uses only standard alphanumeric characters for encoding the objects name. e.g. the "my+"-external could have a setup-function "setupHex_0x6d792b()" (with "6D 79 2B" being hexadecimal representations of "m y +") pd would then try to call "setupHex_0x6d792b()" if "my+_setup()" fails. similar, pd would try to find "3e7e.pd" (and prior to that "3e7e.pd_linux") if it wasn't able to find either ">~.pd_linux" or ">~.pd". i know this is not a very elegant solution, but i cannot think of a better one. anyone else ? mfg,a,sdr IOhannes

1 0

messresponder
by Mathieu Bouchard 11 Sep '05

11 Sep '05

anyone's got any clue of what [messresponder] is useful for? ____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada

1 0

another flext or readanysf segfault
by Georg Holzmann 09 Sep '05

09 Sep '05

Hallo! I just get this segfault in pdradio with readanysf~ with one mp3 file (I don't know what is special with that file, but it crashes when you try to open it ...) anyway, gdb gives the following backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1228211280 (LWP 21054)] 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x080a8baf in sys_lock () at m_sched.c:514 #2 0xb7e32d2d in flext_shared::Forward () from /usr/local/lib/libflext-pd.so.0.5 #3 0xb7e32268 in flext_base_shared::QWorker () from /usr/local/lib/libflext-pd.so.0.5 #4 0xb7e2df67 in flext_shared::ThrCond::TimedWait () from /usr/local/lib/libflext-pd.so.0.5 #5 0xb7fa0ccd in start_thread () from /lib/tls/libpthread.so.0 #6 0xb7f34b0e in clone () from /lib/tls/libc.so.6 anyone any idea ? LG Georg -- =%)!:?"§<§0&-"|>* http://grh.mur.at

1 0

[ pure-data-Patches-1217922 ] fix sendOSC string arg truncation
by SourceForge.net 09 Sep '05

09 Sep '05

Patches item #1217922, was opened at 2005-06-10 04:15 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1217922&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: bugfix >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: steven pickles (pixid) Assigned to: jdl (x75) Summary: fix sendOSC string arg truncation Initial Comment: for some reason, strings in outgoing osc messages are truncated to 80 characters, even when they are being read into a buffer that is 1000 characters long. i made this little fix so the buffer length being send to atom_string is actually the space remaining in the buffer. pd will segfault if you exceed this buffer, but that bug was there before this change. the osc spec doesn't seem to place a limit on the length of string arguments. ---------------------------------------------------------------------- >Comment By: IOhannes m zmÃ¶lnig (zmoelnig) Date: 2005-09-09 11:30 Message: Logged In: YES user_id=564396 fixed bz piotr majdak ---------------------------------------------------------------------- Comment By: Piotr Majdak (petibub) Date: 2005-09-08 19:03 Message: Logged In: YES user_id=1337411 This was fixed in the version 0.3, submitted by grholzi, labeled as "changes by piotr majdak". The binary for Windows can be downloaded from: http://www.majdak.com/piotr/download/ ---------------------------------------------------------------------- Comment By: IOhannes m zmÃ¶lnig (zmoelnig) Date: 2005-06-20 09:36 Message: Logged In: YES user_id=564396 assigned this to x75 (matt seems not to be available) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1217922&group_…

1 0

[ pure-data-Patches-1217922 ] fix sendOSC string arg truncation
by SourceForge.net 08 Sep '05

08 Sep '05

Patches item #1217922, was opened at 2005-06-10 04:15 Message generated for change (Comment added) made by petibub You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1217922&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: bugfix Status: Open Resolution: None Priority: 5 Submitted By: steven pickles (pixid) Assigned to: jdl (x75) Summary: fix sendOSC string arg truncation Initial Comment: for some reason, strings in outgoing osc messages are truncated to 80 characters, even when they are being read into a buffer that is 1000 characters long. i made this little fix so the buffer length being send to atom_string is actually the space remaining in the buffer. pd will segfault if you exceed this buffer, but that bug was there before this change. the osc spec doesn't seem to place a limit on the length of string arguments. ---------------------------------------------------------------------- Comment By: Piotr Majdak (petibub) Date: 2005-09-08 19:03 Message: Logged In: YES user_id=1337411 This was fixed in the version 0.3, submitted by grholzi, labeled as "changes by piotr majdak". The binary for Windows can be downloaded from: http://www.majdak.com/piotr/download/ ---------------------------------------------------------------------- Comment By: IOhannes m zmÃ¶lnig (zmoelnig) Date: 2005-06-20 09:36 Message: Logged In: YES user_id=564396 assigned this to x75 (matt seems not to be available) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1217922&group_…

1 0

[ pure-data-Patches-1285113 ] [print] cuts output, include this in help patch
by SourceForge.net 08 Sep '05

08 Sep '05

Patches item #1285113, was opened at 2005-09-08 18:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1285113&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Submitted By: Piotr Majdak (petibub) Assigned to: Nobody/Anonymous (nobody) Summary: [print] cuts output, include this in help patch Initial Comment: [print] cuts the output if the message is a list with two or more symbols. The second and following symbols are printed up to the length of 78 characters and an asterisk is added. This behaviour should be mentioned in the help patch print-help.pd, see the attachment as an example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1285113&group_…

1 0

[ pure-data-Bugs-1285041 ] writesf_open bug
by SourceForge.net 08 Sep '05

08 Sep '05

Bugs item #1285041, was opened at 2005-09-08 15:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1285041&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Submitted By: Georg Holzmann (grholzi) Assigned to: Nobody/Anonymous (nobody) Summary: writesf_open bug Initial Comment: in a construction like this [savepanel] | [open $1( | [writesf~] clicking directly on the [open( message kills Pd gdb output: 0x080e7512 in writesf_open (x=0x811af68, s=0x81137e8, argc=1, argv=0x80f92d0) at d_soundfile.c:2312 2312 x->x_filename = filesym->s_name; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1285041&group_…

1 0

standard c - Was:Re: PD-cvs Digest, Vol 7, Issue 8
by Thomas Grill 08 Sep '05

08 Sep '05

Hi Mathieu, > 3. pd/src m_conf.c,1.1.1.3.12.1,1.1.1.3.12.2 (Mathieu Bouchard) > > there's a problem with the latest changes here.... it's like this: #define S(name) void name##_setup(void); name##_setup(); void conf_init(void) { S(g_array) S(g_canvas) S(g_guiconnect) .... } in good old c standard variables or external functions have to be defined at the beginning of a code block. The preprocessor run yields something like void g_array_setup(void); g_array_setup(); void g_canvas_setup(void); g_canvas_setup(); where definitions are interspersed with code... gcc does swallow it, but MSVC doesn't. best greetings, Thomas

1 0

DesireData (fwd)
by Mathieu Bouchard 06 Sep '05

06 Sep '05

resending. ---------- Forwarded message ---------- Date: Tue, 6 Sep 2005 09:54:47 -0400 (EDT) From: Mathieu Bouchard <matju(a)artengine.ca> To: pd-dev(a)iem.at Subject: DesireData just a note to say that finally i'm back to working on ImpureData, now renamed to DesireData, and that I will add an option to the scons stuff so that some files get compiled instead of some other files. I will do that because else the staggering amount of if() statements would be in(s)anely confusing; and at the other extreme, i really don't want a separate branch anymore either. An advantage of separate files is that it will be really easy to remove old code (just "cvs remove") whenever the new code gets stable. To run DesireData, go in pd/src and do: wish desire.tk -nogdb but i recommend scons debug=yes and installing gdb and just doing: wish desire.tk Unlike pd-gui, desire.tk stays open when the server crashes, and you can type gdb commands at the bottom of the main window, and all gdb output is redirected to the console. (there's also a box for sending commands to the pd server and another for executing tcl/tk commands) Btw almost nothing works in desire.tk because I haven't committed any C code yet. Thanks to Chun Lee for kicking my butt _and_ for working on DesireData in the past few weeks. ____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada

1 0

Graph on Parent on Parent is seriously broken in 0.39
by Frank Barknecht 06 Sep '05

06 Sep '05

Hi, attached patch illustrates a really nasty bug with Pd's new GOP code. Using multiple levels of GOP will result in invisible parts of the underlying abstractions. This happens both with subpatch-GOPs as with abstraction-GOPs. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__

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 September 2005