Pd-dev January 2010

pd-dev@lists.iem.at

12 participants
161 discussions

[ pure-data-Bugs-2933376 ] [pd-gui-rewrite] [declare -stdpath] expands relative to patc
by SourceForge.net 17 Jan '10

17 Jan '10

Bugs item #2933376, was opened at 2010-01-16 13:14 Message generated for change (Comment added) made by reduzent You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2933376&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: [pd-gui-rewrite] [declare -stdpath] expands relative to patc Initial Comment: It seems, that a [declare -stdpath] of pd-gui-rewrite expands the search pathes relative to the patch's location instead of relative to pd's installation location. ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2010-01-17 11:03 Message: I don't quite see how a patch can help debug the problem, since a patch containing any [declare -stdpath <libdir-name>] [<object_from_libdir>] would expose the problem. More critical is the location of the patch, since - as I already said - the flag -stdpath seems to expand the searchpath relative to the patch's path instead of relative to pd-gui-rewrite's install location. Anyway, I attach the patch. And here the -verbose output, when patch is located in /home/roman: tried /home/roman/declare_-stdpath_pd-gui-rewrite_bug.pd and succeeded tried /home/roman/../extra/ext13/wavinfo.l_i386 and failed tried /home/roman/wavinfo.l_i386 and failed tried ../extra/wavinfo.l_i386 and failed tried /home/roman/../extra/ext13/wavinfo.pd_linux and failed tried /home/roman/wavinfo.pd_linux and failed tried ../extra/wavinfo.pd_linux and failed tried /home/roman/../extra/ext13/wavinfo/wavinfo.l_i386 and failed tried /home/roman/wavinfo/wavinfo.l_i386 and failed tried ../extra/wavinfo/wavinfo.l_i386 and failed tried /home/roman/../extra/ext13/wavinfo/wavinfo.pd_linux and failed ^ this indicates, that [declare] appends the value from the flag -stdpath to the patch's path '/home/roman' instead of the pd-gui-rewrite's install location, which is in /home/roman/pd-svn/pd-gui-rewrite/ tried /home/roman/wavinfo/wavinfo.pd_linux and failed tried ../extra/wavinfo/wavinfo.pd_linux and failed tried /home/roman/../extra/ext13/wavinfo.pd and failed tried /home/roman/wavinfo.pd and failed tried ../extra/wavinfo.pd and failed tried /home/roman/../extra/ext13/wavinfo.pat and failed tried /home/roman/wavinfo.pat and failed tried ../extra/wavinfo.pat and failed wavinfo ... couldn't create ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-01-17 01:52 Message: An example patch is always very helpful, especially if it triggers the problem every time that it is run. Ideally the example patch would have only enough objects to cause the problem, but nothing else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2933376&group_…

1 0

[ pure-data-Bugs-2924862 ] print help
by SourceForge.net 17 Jan '10

17 Jan '10

Bugs item #2924862, was opened at 2010-01-02 10:51 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2924862&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: pd-extended Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Hans-Christoph Steiner (eighthave) Summary: print help Initial Comment: print help crashes pd in vista ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2010-01-17 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-01-02 16:01 Message: Please provide as detailed information as possible including which operating system (OS), CPU type, specific hardware, and the exact distro and version of Pd itself, etc. For example: Pd version 0.41.4-extended Mac OS X 10.5.7/Intel built-in sound ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2924862&group_…

1 0

[ pure-data-Bugs-2933376 ] [pd-gui-rewrite] [declare -stdpath] expands relative to patc
by SourceForge.net 17 Jan '10

17 Jan '10

Bugs item #2933376, was opened at 2010-01-16 08:14 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2933376&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: [pd-gui-rewrite] [declare -stdpath] expands relative to patc Initial Comment: It seems, that a [declare -stdpath] of pd-gui-rewrite expands the search pathes relative to the patch's location instead of relative to pd's installation location. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-01-16 20:52 Message: An example patch is always very helpful, especially if it triggers the problem every time that it is run. Ideally the example patch would have only enough objects to cause the problem, but nothing else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2933376&group_…

1 0

Re: [PD-dev] Ignoring '5401': doesn't look like a Pd-file
by IOhannes m zmoelnig 16 Jan '10

16 Jan '10

Hans-Christoph Steiner wrote: > Hey, > > Everytime I run pd 0.43 from the command line like ./pd, I get this: > > Ignoring '5401': doesn't look like a Pd-file yes, here too :-) and i even know where it comes from... when you call "./pd-gui.tcl <somefile.pd>", it will request somefile.pd to be opened (by calling "open_file{}" if you call "./pd-gui.tcl 5400" it will connect to a running Pd on port 5400, but it will _also_ think that "5400" is a file to open, and call "open_file 5400" then "open_file{}" will do a check whether and will only ask Pd-core to open the file if it ends with .pd/.pat/.mxt. since 5400 does not match this criterion it will be discarded. this is how it has been before i modified the source. nobody noticed, because open_file silently dropped the "illegal" file. what i did is, that i added a warning, if open_file{} discards a file (because it does not end with .pd/...) i think this is good, because it tells us, that we are using a bad hack here: we are mixing 2 concepts - the check in open_file{} is there to prevent "bad" files to be opened. - if we call "./pd-gui.tcl 5400" we don't want to specify a file, but instead a port! we know that this is a port, because it is a number. we should not call open_file{} with something which we already know is not a file. so the check has to be done way earlier in the process. in the meantime i prefer to see the warning (a constant reminder of the quirk) rather than drop it. one could use the new ::pdwindow::verbose{} rather than post{}. but really the underlying problem should be fixed sooner than later. fgmadsr IOhannes

3 3

[ pure-data-Bugs-2933376 ] [pd-gui-rewrite] [declare -stdpath] expands relative to patc
by SourceForge.net 16 Jan '10

16 Jan '10

Bugs item #2933376, was opened at 2010-01-16 13:14 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2933376&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: [pd-gui-rewrite] [declare -stdpath] expands relative to patc Initial Comment: It seems, that a [declare -stdpath] of pd-gui-rewrite expands the search pathes relative to the patch's location instead of relative to pd's installation location. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2933376&group_…

1 0

[ pure-data-Bugs-1186531 ] crash when using donecanvasdialog message
by SourceForge.net 16 Jan '10

16 Jan '10

Bugs item #1186531, was opened at 2005-04-20 09:13 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1186531&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: Closed Resolution: None Priority: 5 Private: No Submitted By: Tim Blechmann (timblech) Assigned to: Nobody/Anonymous (nobody) Summary: crash when using donecanvasdialog message Initial Comment: hi all ... pd crashes, if i send a donecanvasdialog message to a closed subpatch: |;pd-mysubpatch donecanvasdialog 0 0 1( works fine (switching on gop) |;pd-mysubpatch donecanvasdialog 0 0 0( results in: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 11495)] 0x0805f3d3 in glist_findrtext (gl=0x0, who=0x83dc7f8) at g_rtext.c:332 332 t_rtext *x = gl->gl_editor->e_rtext; (gdb) where #0 0x0805f3d3 in glist_findrtext (gl=0x0, who=0x83dc7f8) at g_rtext.c:332 #1 0x0805a23d in graph_vis (gr=0x83dc7f8, parent_glist=0x83dc718, vis=0) at g_graph.c:665 #2 0x0805a1e5 in graph_vis (gr=0x83dc718, parent_glist=0x84808d0, vis=138266616) at g_graph.c:804 #3 0x0806c81c in canvas_setgraph (x=0x83dc718, flag=0) at g_editor.c:830 #4 0x0806c8a7 in canvas_donecanvasdialog (x=0x83dc718, xperpix=-nan(0x7fffff), yperpix=1, fgraphme=-nan(0x7fffff)) at g_editor.c:872 #5 0x08085671 in pd_typedmess (x=0x83dc718, s=0x83dc8f8, argc=0, argv=0x8108428) at m_class.c:815 #6 0x080882a4 in binbuf_eval (x=0x0, target=0x83dc718, argc=1, argv=0xbff3d9b0) at m_binbuf.c:597 #7 0x0805bfd0 in message_float (x=0x83dc7f8, f=0) at g_text.c:300 #8 0x0808653d in outlet_float (x=0x0, f=0) at m_obj.c:431 #9 0x0807ca3e in toggle_bang (x=0x83de2e8) at g_toggle.c:250 #10 0x0807cbbe in toggle_newclick (z=0x0, glist=0x84808d0, xpix=511, ypix=328, shift=0, alt=0, dbl=0, doit=1) at g_toggle.c:282 #11 0x0806e14b in canvas_doclick (x=0x84808d0, xpos=511, ypos=328, which=1, mod=0, doit=1) at g_editor.c:1036 #12 0x0806eb6a in canvas_mousedown (x=0x0, xpos=511, ypos=328, which=1, mod=0) at g_editor.c:1209 #13 0x08085671 in pd_typedmess (x=0x84808d0, s=0x83dc8f8, argc=0, argv=0x8108408) at m_class.c:815 #14 0x080852b3 in pd_typedmess (x=0x83dcce0, s=0x83dc8f8, argc=4, argv=0x81083e8) at m_class.c:836 #15 0x080882a4 in binbuf_eval (x=0x0, target=0x83dcce0, argc=0, argv=0x0) at m_binbuf.c:597 #16 0x0808e7eb in socketreceiver_read (x=0x822b6a0, fd=5) at s_inter.c:537 #17 0x0808d9fa in sys_domicrosleep (microsec=0, pollem=138266616) at s_inter.c:177 #18 0x0808e404 in sys_pollgui () at s_inter.c:820 #19 0x0808c094 in m_scheduler () at m_sched.c:488 #20 0x0808d841 in sys_main (argc=2, argv=0xbff3f554) at s_main.c:354 #21 0x080918a6 in main (argc=0, argv=0x0) at s_entry.c:27 cheers ... t ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2010-01-16 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-01-02 01:28 Message: Using Pd-devel 0.43 on Mac OS X 10.5.8, I couldn't reproduce this. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2005-06-21 09:58 Message: Logged In: YES user_id=564396 i cannot reproduce this. could you post a patch ? (to pd-dev)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1186531&group_…

1 0

[ pure-data-Bugs-2933148 ] [pd-gui-rewrite] 'vis 1' to canvas moves window
by SourceForge.net 16 Jan '10

16 Jan '10

Bugs item #2933148, was opened at 2010-01-15 23:17 Message generated for change (Settings changed) made by reduzent You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2933148&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: pd-devel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) >Assigned to: Hans-Christoph Steiner (eighthave) Summary: [pd-gui-rewrite] 'vis 1' to canvas moves window Initial Comment: When sending 'vis 0' and 'vis 1' repeatedly to a canvas, the window moves downwards with each cylce. The amount of the shift seems dependent on the height of the menu of the window. If the window is wide enough so that the whole menu fits into one line, the amount is significantly smaller (ca. 30px). With a narrow window and a menu splitted into three lines, the amount is bigger (ca. 60px). Could it be, that the stored window position refers to the patching area, whereas when drawn by the window manager, the patching area is shifted by the menu? I tested on Gnome and fluxbox. The shifting does not happen with pd-vanilla. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2933148&group_…

1 0

[ pure-data-Bugs-2933148 ] [pd-gui-rewrite] 'vis 1' to canvas moves window
by SourceForge.net 16 Jan '10

16 Jan '10

Bugs item #2933148, was opened at 2010-01-15 23:17 Message generated for change (Tracker Item Submitted) made by reduzent You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2933148&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: pd-devel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: Nobody/Anonymous (nobody) Summary: [pd-gui-rewrite] 'vis 1' to canvas moves window Initial Comment: When sending 'vis 0' and 'vis 1' repeatedly to a canvas, the window moves downwards with each cylce. The amount of the shift seems dependent on the height of the menu of the window. If the window is wide enough so that the whole menu fits into one line, the amount is significantly smaller (ca. 30px). With a narrow window and a menu splitted into three lines, the amount is bigger (ca. 60px). Could it be, that the stored window position refers to the patching area, whereas when drawn by the window manager, the patching area is shifted by the menu? I tested on Gnome and fluxbox. The shifting does not happen with pd-vanilla. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2933148&group_…

1 0

[ pure-data-Bugs-2932195 ] this crashes pd extended
by SourceForge.net 14 Jan '10

14 Jan '10

Bugs item #2932195, was opened at 2010-01-14 18:36 Message generated for change (Tracker Item Submitted) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2932195&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: pd-extended Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Hans-Christoph Steiner (eighthave) Summary: this crashes pd extended Initial Comment: Sorry for the generic title but I really can't isolate the problem. When I try to open this attached patch on Windows Vista, pd Extended immediately crashes. The patch has no loadbangs and does absolutely nothing without user input. 100% of the times I open it, it crashes. Since it first crashed when I was trying to create a [print] object, I have tried to remove all [print]s with a text editor (changing them for [pd]s just to avoid messing up connections) and could open it without crash. However, if I then go on editing the patch, creating and deleting objects, it usually crashes in a few minutes. I suspect the cause is in some of these objects: [dirpanel] [folder_list] and/or, possibly, [sys_gui] because I tried creating a new fresh patch with none of these and play around and I couldn't have it crash - while if I create some of these objects and then keep editing the patch, chances are that it crashes very soon. But it may be some generic problem with all externals... Windows vista, pd-extended 0.41.4 I have been using pd Vanilla for a long time and never had such a problem.on the same machine ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2932195&group_…

1 0

Re: [PD-dev] [flext] Fwd: fixing Flext for 64-bit?
by Spencer Russell 14 Jan '10

14 Jan '10

Attached is a patch that should make flext buffer handling 64-bit compatible. It adds new wrapper functions buffer::Peek(int index) and buffer::Poke(int index, t_sample value) to access a buffer's data. New externals should uses these instead of accessing the data array directly, because with newer PDs that doesn't work. I've also updated the buffer1 example to use the new API wrappers. The issue is that arrays in PD are of type t_word, which is a union that can contain a variety of data, including pointers. In 32-bit architectures you can pretty much ignore that it's a union because floats and pointers are the same size, but on 64-bit architectures it's important to use the w_float member of the union to access stored floats. This patch shouldn't break any old externals unless they're used with PD > 0.41 (but then they'd be broken, anyways). I don't have access to an OS X machine or Max/MSP, so I've so far only tested this on 64-bit linux/PD. YMMV. Can someone explain to me why pd's arrays are arrays of t_word instead of t_sample? -s- On Thu, Oct 1, 2009 at 10:41 AM, dmotd <dmotd(a)gmx.net> wrote: > hi spencer, > > afaik there hasn't been any progress with > the 64bit translation, i was going to > attempt it last time i needed it but got > distracted along the way - and i sent a > similar message to thomas at the time, so > its going to be on his todo list, but > proabably not a priority. > > i'd be happy to test any changes you > make, and collaborate time permitted. > > ciao, > > dmotd > > Spencer Russell wrote: >> Thought this should probably go to the list: >> >> ---------- Forwarded message ---------- >> From: Spencer Russell <spencer.f.russell(a)gmail.com> >> Date: Tue, Sep 29, 2009 at 11:13 AM >> Subject: Re: fixing Flext for 64-bit? >> To: Thomas Grill <gr(a)grrrr.org> >> >> > >> > Am 29.09.2009 um 15:00 schrieb Spencer Russell: >> > >> >> Hi Thomas, >> >> >> >> I'm writing a Flext external to implement Iannis Xenakis's Dynamic >> >> Stochastic Synthesis, and running into some problems with buffer >> >> handling on my 64-bit system. >> >> >> >> It seems that currently flext uses the deprecated >> >> garray_getfloatarray() function and t_sample arrays, instead of the >> >> new garray_getfloatwords() function with t_word unions. >> >> >> >> Changing the code would make flext incompatible with older versions of >> >> PD, but some other external developers are currently using an #ifdef >> >> workaround to change to the newer API call for PD versions that >> >> support it. >> >> >> >> I was going to get in there and see if i can't get it working in the >> >> flext code, but I wanted to check with you first to see if you had >> >> already done any work on that front. I'll of course send you the diffs >> >> if i get it working. Shouldn't be that hard and i think it should >> >> really only effect the buffer-handling code, but I don't know the >> >> flext codebase that well so there might be some hidden gotchas. >> >> >> >> -spencer >> >> On Tue, Sep 29, 2009 at 9:08 AM, Thomas Grill <gr(a)grrrr.org> wrote: >> > Hi Spencer, >> > i know that this is something i should work on, but my schedule is insanely >> > tight and i don't get to it. >> > So, if you can make any contributions and testing on 64-bit systems i'd be >> > very grateful. >> > I'd also go for the Pd API selecton by #ifdef statements. >> > gr~~~ >> > >> >> As far as i can tell, PD since 0.41 changed arrays to be arrays of >> t_words instead of t_samples or t_floats. >> >> On 32-bit architectures they're all the same size, but on 64-bit >> architectures t_word is 64-bit, while t_sample and t_float are still >> 32-bit. >> >> For a normal PD external, it's pretty easy to just modify the external >> to use t_words, but I'm not sure the best way to modify flext to do >> this without breaking compatibility for externals. One problem is that >> when an external calls mybuffer.Data(), what should they receive? if >> the system is PD newer than 0.41, they should receive a pointer to >> t_word, but MAX or older PD should receive a pointer to t_sample. >> >> The other problem is that accessing an element for newer PD requires >> accessing the w_float member of the t_word union, but the others just >> use the element itself. >> >> There could be some sort of GetValue() wrapper for buffer elements >> that could be made cross-platform, but would break compatibility with >> existing flext externals, so that seems seriously sub-optimal. >> >> thoughts? >> >> -s- >> _______________________________________________ >> http://grrrr.org/ext/flext >> >> flext mailing list >> flext(a)grrrr.org >> http://www.parasitaere-kapazitaeten.net/mailman/listinfo/flext >

2 3

← Newer
1
...
4
5
6
7
8
9
10
...
17
Older →

Jump to page:

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 2010