Pd-dev May 2007

pd-dev@lists.iem.at

13 participants
67 discussions

getting the full path for the CWD in pd
by Hans-Christoph Steiner 23 May '07

23 May '07

Anyone know how I might get the full path for the current working directory that the pd executable was launched in? I want to be able to embed the preferences file in the Pd.app. sys_libdir seems to return "../bin", which works for something apparently. But I need the full path for the preferences system to work. I tried getcwd(), but that returns "/" for me. Obviously, Pd is not finding it's helpfiles in "/../bin/../doc", so there must be a way... .hc ------------------------------------------------------------------------ ---- I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler

1 0

[ pure-data-Bugs-1723625 ] OSCx crashes with long messages
by SourceForge.net 22 May '07

22 May '07

Bugs item #1723625, was opened at 2007-05-22 19:00 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1723625&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Nobody/Anonymous (nobody) Summary: OSCx crashes with long messages Initial Comment: [dumpOSC] crashes when it receives long messages (more than 50 atoms) this is, because the maximum number of atoms in the output list is hardcoded to 50, but no check is done whether this limit is reached when filling the list, resulting in a segmentation fault. (btw, mrpeach's osc external works fine) ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2007-05-22 19:05 Message: Logged In: YES user_id=564396 Originator: YES added crash-patch File Added: crashtest.pd ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1723625&group_…

1 0

[ pure-data-Bugs-1723625 ] OSCx crashes with long messages
by SourceForge.net 22 May '07

22 May '07

Bugs item #1723625, was opened at 2007-05-22 19:00 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=1723625&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Nobody/Anonymous (nobody) Summary: OSCx crashes with long messages Initial Comment: [dumpOSC] crashes when it receives long messages (more than 50 atoms) this is, because the maximum number of atoms in the output list is hardcoded to 50, but no check is done whether this limit is reached when filling the list, resulting in a segmentation fault. (btw, mrpeach's osc external works fine) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1723625&group_…

1 0

[ pure-data-Bugs-1722844 ] pd.exe process keeps running after killing pd in WinXP
by SourceForge.net 21 May '07

21 May '07

Bugs item #1722844, was opened at 2007-05-21 18:36 Message generated for change (Settings changed) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1722844&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: v0.40.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) >Summary: pd.exe process keeps running after killing pd in WinXP Initial Comment: ** WINDOWS XP ** When a patch becomes unstable, for example because of an infinite loop or almost such, and you "kill" it with window's Task Manager (in the Applications panel), AFTER it is supposed to have been closed (and windows has already sent the error report to Bill Gate's personal trash can), sometimes the pd.exe process keeps running, without any window nor icon, and consuming a lot of cpu (since it keeps running the unstable patch). In the Task Manager, "processes" panel, you then can find and kill it. I often noticed that in windows PD has 2 main processes: pd.exe and one called "Wish84" or something like that, that I guess is the one with the main window and text output. I suppose the problem may be that when killing PD (I mean killing the PD application from the Applications panel of the task manager, NOT killing just the wish84 process from the processes panel), only the wish84 process is really killed - probably this only happens when the pd process is unstable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1722844&group_…

1 0

[ pure-data-Bugs-1722844 ] pd.exe process keeps running after killing the application
by SourceForge.net 21 May '07

21 May '07

Bugs item #1722844, was opened at 2007-05-21 18:36 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=1722844&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: v0.40.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pd.exe process keeps running after killing the application Initial Comment: ** WINDOWS XP ** When a patch becomes unstable, for example because of an infinite loop or almost such, and you "kill" it with window's Task Manager (in the Applications panel), AFTER it is supposed to have been closed (and windows has already sent the error report to Bill Gate's personal trash can), sometimes the pd.exe process keeps running, without any window nor icon, and consuming a lot of cpu (since it keeps running the unstable patch). In the Task Manager, "processes" panel, you then can find and kill it. I often noticed that in windows PD has 2 main processes: pd.exe and one called "Wish84" or something like that, that I guess is the one with the main window and text output. I suppose the problem may be that when killing PD (I mean killing the PD application from the Applications panel of the task manager, NOT killing just the wish84 process from the processes panel), only the wish84 process is really killed - probably this only happens when the pd process is unstable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1722844&group_…

1 0

[ pure-data-Feature Requests-1722089 ] "Change name/args" field under "Hide object name and args"
by SourceForge.net 20 May '07

20 May '07

Feature Requests item #1722089, was opened at 2007-05-20 02:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=1722089&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 Priority: 5 Private: No Submitted By: Luke Iannini (lukeiannini) Assigned to: Nobody/Anonymous (nobody) Summary: "Change name/args" field under "Hide object name and args" Initial Comment: It would be great to have a field for accessing and changing the name and args of an object that has the "Hide object name and arguments" box ticked. As of now one must uncheck it, edit, and recheck the box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=1722089&group_…

1 0

[ pure-data-Bugs-1722081 ] [Editmode 0( toggles rather than turns off editmode
by SourceForge.net 20 May '07

20 May '07

Bugs item #1722081, was opened at 2007-05-20 02:27 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=1722081&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: Luke Iannini (lukeiannini) Assigned to: Nobody/Anonymous (nobody) Summary: [Editmode 0( toggles rather than turns off editmode Initial Comment: Hallo, Simple enough... sending [editmode 0( to a subpatch toggles the edit-mode state of the subpatch, rather than turning it off. [editmode 1( works fine, reliably enabling (and never disabling) editmode. Ah! That makes me realize the workaround is to send [editmode 1(, then [editmode 0(. Regardless, this should be fixed! Demonstration is attached (move mouse around to see the cursor change). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1722081&group_…

1 0

[ pure-data-Patches-1624018 ] MinGW Fixes for 0.40.1
by SourceForge.net 20 May '07

20 May '07

Patches item #1624018, was opened at 2006-12-28 19:25 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1624018&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: 7 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: MinGW Fixes for 0.40.1 Initial Comment: This patch has a number of minor fixes necessary for building Pd 0.40.1 on MinGW. It's used in the Pd-extended nightly builds. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2007-05-19 21:09 Message: Logged In: YES user_id=313747 Originator: NO Taken for 0.41... don't know what most if this does :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1624018&group_…

1 0

[ pure-data-Patches-1625445 ] extended character support
by SourceForge.net 20 May '07

20 May '07

Patches item #1625445, was opened at 2006-12-31 11:50 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1625445&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: feature Status: Open Resolution: None Priority: 8 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: extended character support Initial Comment: Enable support for more characters, like characters with umlauts and accents. Following this discussion: http://lists.puredata.info/pipermail/pd-list/2006-12/045571.html ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2007-05-19 21:04 Message: Logged In: YES user_id=313747 Originator: NO Taken for 0.41. I'll edit the comment to make it appropriately scary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1625445&group_…

1 0

[ pure-data-Patches-1638701 ] 2GB limit for reading!
by SourceForge.net 20 May '07

20 May '07

Patches item #1638701, was opened at 2007-01-18 07:15 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1638701&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: feature Status: Open Resolution: None Priority: 7 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: 2GB limit for reading! Initial Comment: my patch [1312885] fixed the problem with writing files with [writesf~] which are larger than 2GB. however, this does not work for reading soundfiles, since open_via_path() uses the non-largefile functions read() and fstat(). this patch (against current CVS 18.01.2006) for s_path.c allows to open huge files via open_via_path(), and therefore large files can be played back via [readsf~]. again, this only works on *nix's. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2007-05-19 20:53 Message: Logged In: YES user_id=313747 Originator: NO I applied this and changed one "lseek" (I think the only important one) to use "__off64_t" where appropriate. I don't see how this could do any harm, and who knows, perhaps it will actually work. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2007-01-18 12:03 Message: Logged In: YES user_id=564396 Originator: YES there is also a problem with the "skipframes" option, since pd uses "int" as return value from lseek() (and lseek64()), which is not recommended. it should be (off_t) and (__off64_t) resp. however there might be even more problems involved. i'll have to investigate... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1638701&group_…

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 May 2007