Bugs item #1072763, was opened at 2004-11-24 21:33
Message generated for change (Comment added) made by stffn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1072763&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.39.2
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: B. Bogart (bbogart)
Assigned to: Nobody/Anonymous (nobody)
Summary: .gfxstub41d8c0.f?: no such object in console w/ pd.38-test10
Initial Comment:
When pasting (Apple-V) into "pd search path entry boxes":
error: .gfxstub41d8c0.f?: no such object
Where "?" is 0-9 corrseponding to the entry field
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2007-10-16 15:44
Message:
Logged In: YES
user_id=1658640
Originator: NO
This is still the case in Pd-0.40-2.
Note that the pasted text does get it way into the "pd search path entry
boxes".
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2004-12-10 04:19
Message:
Logged In: YES
user_id=313747
This seems mot to happen in linux, will try on a mac later.
Same for previous bug.
-M
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1072763&group_…
Bugs item #1122560, was opened at 2005-02-14 19:15
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1122560&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: Pending
>Resolution: Fixed
Priority: 8
Private: No
Submitted By: thewade (pdman)
Assigned to: Nobody/Anonymous (nobody)
Summary: writesf~ 64-bit distorted files
Initial Comment:
It sounds like writesf~ .wav files in 64-bit PD are
written at twice the sampeling rate.
If I writesf~ a .wave file, the readsf~ that file back
in (using 0 200 2 2 l as part of the open message, as
readsf~ complains about bad .wav headders even from
writesf~) it plays twice as fast as it should. I cannot
fix this by adding the -rate message.
AMD64 laptop
2.6.10-lsm kernel
PD from CVS as of late January, early Febuarary I think
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2007-10-16 15:40
Message:
Logged In: YES
user_id=564396
Originator: NO
at least on my laptop (amd64, 2.6.22) it works fine.
if the original poster does not reject, i will close this bug now.
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2007-10-16 15:23
Message:
Logged In: YES
user_id=1658640
Originator: NO
This has been fixed in 0.41-x, hasn't it?
----------------------------------------------------------------------
Comment By: thewade (pdman)
Date: 2005-02-28 21:53
Message:
Logged In: YES
user_id=1179250
I have uploaded a test file created using the broken
writesf~ to my website:
http://www.aproximation.org/test.wav
As sourceforge apparently wont allow files of that size
(approx 1900kb) to be uploaded.
----------------------------------------------------------------------
Comment By: thewade (pdman)
Date: 2005-02-28 04:02
Message:
Logged In: YES
user_id=1179250
I guess I can read in files and write files out, provided I
override headers (I got aplay to play the audio file by
specifying -f dat) but I still think this is a bug. I should
be able to send [open /myfile.wav< to writesf/readsf and
write/read a file with valid headers. I have attached a mono
wave file written with pd to this ticket.
Thanks!
-thewade
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1122560&group_…
Bugs item #1072765, was opened at 2004-11-24 21:35
Message generated for change (Comment added) made by stffn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1072765&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.39.2
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: B. Bogart (bbogart)
Assigned to: Nobody/Anonymous (nobody)
Summary: .printout.text: no such object in console for pd.38-test10
Initial Comment:
When Copying in console widget: (Apple-C)
error: .printout.text: no such object
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2007-10-16 15:39
Message:
Logged In: YES
user_id=1658640
Originator: NO
This is still the case in Pd-0.40-2.
Note that the selected text from the console window does get copied --
ready for pasting (apple-v).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1072765&group_…
Bugs item #1176416, was opened at 2005-04-04 17:01
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1176416&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: Fixed
Priority: 6
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: Prefs and Help Menus don't work until a window is opened
Initial Comment:
On Mac OS X, when you start Pd.app, the Preferences and
the Help menus do not open at all. In order to get
them to open, you need to open a new window or open a
patch. Then the menus work fine whether or not any
windows are open.
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2007-10-16 15:22
Message:
Logged In: YES
user_id=1658640
Originator: NO
As this is fixed, at least in Pd-0.40-2, i think this bug report can be
closed.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2005-04-04 17:03
Message:
Logged In: YES
user_id=27104
I forgot to mention that this happens on 0.38-3. Under
Windows, this does not happen.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1176416&group_…
Bugs item #1122560, was opened at 2005-02-14 19:15
Message generated for change (Comment added) made by stffn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1122560&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: 8
Private: No
Submitted By: thewade (pdman)
Assigned to: Nobody/Anonymous (nobody)
Summary: writesf~ 64-bit distorted files
Initial Comment:
It sounds like writesf~ .wav files in 64-bit PD are
written at twice the sampeling rate.
If I writesf~ a .wave file, the readsf~ that file back
in (using 0 200 2 2 l as part of the open message, as
readsf~ complains about bad .wav headders even from
writesf~) it plays twice as fast as it should. I cannot
fix this by adding the -rate message.
AMD64 laptop
2.6.10-lsm kernel
PD from CVS as of late January, early Febuarary I think
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2007-10-16 15:23
Message:
Logged In: YES
user_id=1658640
Originator: NO
This has been fixed in 0.41-x, hasn't it?
----------------------------------------------------------------------
Comment By: thewade (pdman)
Date: 2005-02-28 21:53
Message:
Logged In: YES
user_id=1179250
I have uploaded a test file created using the broken
writesf~ to my website:
http://www.aproximation.org/test.wav
As sourceforge apparently wont allow files of that size
(approx 1900kb) to be uploaded.
----------------------------------------------------------------------
Comment By: thewade (pdman)
Date: 2005-02-28 04:02
Message:
Logged In: YES
user_id=1179250
I guess I can read in files and write files out, provided I
override headers (I got aplay to play the audio file by
specifying -f dat) but I still think this is a bug. I should
be able to send [open /myfile.wav< to writesf/readsf and
write/read a file with valid headers. I have attached a mono
wave file written with pd to this ticket.
Thanks!
-thewade
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1122560&group_…
Bugs item #1176416, was opened at 2005-04-04 17:01
Message generated for change (Comment added) made by stffn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1176416&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: 6
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: Prefs and Help Menus don't work until a window is opened
Initial Comment:
On Mac OS X, when you start Pd.app, the Preferences and
the Help menus do not open at all. In order to get
them to open, you need to open a new window or open a
patch. Then the menus work fine whether or not any
windows are open.
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2007-10-16 15:22
Message:
Logged In: YES
user_id=1658640
Originator: NO
As this is fixed, at least in Pd-0.40-2, i think this bug report can be
closed.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2005-04-04 17:03
Message:
Logged In: YES
user_id=27104
I forgot to mention that this happens on 0.38-3. Under
Windows, this does not happen.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1176416&group_…
Patches item #1242459, was opened at 2005-07-21 19:29
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1242459&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: Hans-Christoph Steiner (eighthave)
>Assigned to: Miller Puckette (millerpuckette)
Summary: [bonk~] reads and writes to / by default
Initial Comment:
When reading and writing files with [bonk~], it
defaults to / if no directory is specified. [qlist]
and [textfile] default to the current directory of the
patch. This seems to me to be the correct behavior.
To see this bug in action, save the attached patch to
/tmp and open it.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2007-10-16 15:04
Message:
Logged In: YES
user_id=564396
Originator: NO
however it might be that this my correct behaviour is specific to
linux...
attached is a unified diff against bonk~.c that uses canvas_makefilename()
for writing and canvas_open() for reading; this should behave exactly the
same as qlist/textfile
File Added: bonk~.diff
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2007-10-16 14:32
Message:
Logged In: YES
user_id=564396
Originator: NO
hmm, on pd-0.40 (linux), bonk~ correctly reads from/writes to the current
directory.
can you confirm whether the bug still exists?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1242459&group_…
Bugs item #1749885, was opened at 2007-07-08 14:16
Message generated for change (Comment added) made by stffn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1749885&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: 7
Private: No
Submitted By: Frank Barknecht (fbar)
Assigned to: Nobody/Anonymous (nobody)
Summary: zl nth from cyclone crashes on lists with more than 32 items
Initial Comment:
The object [zl nth] from cyclone crashes Pd when dealing with lists of more than 32 items. See attached patch.
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2007-10-16 14:47
Message:
Logged In: YES
user_id=1658640
Originator: NO
I can not reproduce. Instead it works as expected.
This is Pd-extended (0.39.3) of the 13th of October 2007 autobuilds on
core due macbook running mac os x.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1749885&group_…
Bugs item #1702883, was opened at 2007-04-18 14:08
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1702883&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: frey (freynz)
Assigned to: Nobody/Anonymous (nobody)
Summary: zexy's >~, <~, ==~ etc objects not loading - OSX
Initial Comment:
On both pd-0.39.2-extended-rc2 and Miller's vanilla pd-0.40-2 under OSX on an Intel MacBook, >~, <~, ==~ objects are not loading, even though the 0x2e0x7e.pd &c. files are present in the path.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2007-10-16 14:36
Message:
Logged In: YES
user_id=564396
Originator: NO
hmm, pd-0.40 has no hexloader anymore.
you have to use the "hexloader"-external (to be found in
loaders/hexloader) in order to enable it.
does it work then?
----------------------------------------------------------------------
Comment By: Luke Iannini (lukeiannini)
Date: 2007-07-02 00:55
Message:
Logged In: YES
user_id=1541432
Originator: NO
Hi, I can confirm that they are working with Pd-Extended 0.39.2 RC4 on
Mac/Intel. But! That is not my platform; I am using 0.40.2 autobuilds.
Any idea what's necessary to get them working there? If it's informative,
the mtx_* etc. object only work after spawning e.g. mtx_mul still (I know
this is a known issue). But >~ and friends do not have alphabetic
equivalents, so that workaround is not available.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-04-20 04:32
Message:
Logged In: YES
user_id=27104
Originator: NO
I can reproduce this on pd-0.39.2-extended-rc1 on Mac/PowerPC with the
namespace prefix. But if I use [import zexy], then they work. I attached
a patch.
File Added: zexy_hexloader.pd
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1702883&group_…
Bugs item #1242459, was opened at 2005-07-21 19:29
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1242459&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: 6
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: [bonk~] reads and writes to / by default
Initial Comment:
When reading and writing files with [bonk~], it
defaults to / if no directory is specified. [qlist]
and [textfile] default to the current directory of the
patch. This seems to me to be the correct behavior.
To see this bug in action, save the attached patch to
/tmp and open it.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2007-10-16 14:32
Message:
Logged In: YES
user_id=564396
Originator: NO
hmm, on pd-0.40 (linux), bonk~ correctly reads from/writes to the current
directory.
can you confirm whether the bug still exists?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1242459&group_…