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_…
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_…
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_…
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_…
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_…
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_…
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_…
Patches item #1651283, was opened at 2007-02-03 08:04
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1651283&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
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Miller Puckette (millerpuckette)
Summary: documentation error in cos~-help.pd
Initial Comment:
(This is a DOCUMENTATION bug, not a bug of the program, but I can't find such a category here)
The description of the cos~ object in its help patch says:
"The cos~ object outputs the cosine of its signal input"
while it should read:
"The cos~ object outputs the cosine of 2*pi times its signal input"
I attach the updated cos~-help.pd file
Note that the "cos" (without ~) object does NOT believe the same way, since it does output the cosine of the input in radians. This situation is not ideal, but correcting it would be a disaster for the portability of pathces. However, it must be documented.
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2007-05-19 16:28
Message:
Logged In: YES
user_id=313747
Originator: NO
the doc is fixed for 0.41 ... the fact that cos~ acts differently from
cos is ugly but it's hard to see what else to name "cos~"...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1651283&group_…
Bugs item #1721409, was opened at 2007-05-18 10:55
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=1721409&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: kyleklip (kyleklip)
Assigned to: Nobody/Anonymous (nobody)
Summary: rlshift~-help file for lrshift~ external
Initial Comment:
Another Pd-0.39.2-extended-rc2 bug, but it's just a name thing. I submitted a file with the renamed help file, I hope that helps!
I'm trying to get dilligent about reporting things that I notice on random inspections for other things (this time trying to find xsample).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1721409&group_…
Bugs item #1721404, was opened at 2007-05-18 10:50
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=1721404&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: kyleklip (kyleklip)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: xsample lib not loading
Initial Comment:
The xgroove~ and xplay~ objects are not working for me on
Pd-0.39.2-extended-rc2 (OS X 10.4.9). The *.pd_darwin files are in the /extra folder, and other objects are loading fine from there (tested vasp and it loads).
Could this be an issue with the actual compiled externals? I know that flext can be a bit tricky on OS X (at least for me).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1721404&group_…