Bugs item #1678373, was opened at 2007-03-11 17:31
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1678373&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.2
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: GUI elements depth error
Initial Comment:
When two gui elements (for example sliders) overlap, and you try to "click" on them (i.e. move the slider) within the overlapping region, the correct behaviour would be that the front-most element "receive" the mouse click, since that is the one you're visibly "clicking on". However, the opposite happens: the gui element which is behind is the one that you move.
This happens both in editmode and not.
At least on Windows XP.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2007-10-16 15:21
Message:
Logged In: YES
user_id=564396
Originator: NO
as ed kelly has demonstrated so beautifully at the pd~con07, this is
really a feature and not a bug:
it gives you the possibility to add hidden guiobjects that control the
behaviour of the visible ones.
e.g. you can create a symbol-box where you can select the symbols by
click-n-drag (just like you are used to do it with numberboxes)
see attached patch for examples
File Added: backguis-rule.pd
----------------------------------------------------------------------
Comment By: Luke Iannini (lukeiannini)
Date: 2007-07-02 01:06
Message:
Logged In: YES
user_id=1541432
Originator: NO
Hi, I tried tried to make a slider-based virtual clavier and this bug kept
all of the black keys from working. The workaround would have been to
surround the black keys with 3 white sliders of various sizes, then cover
discontinuities with a 1-pixel white canvas, all to ensure a single-layer
of GUI elements. I definitely said the hell with it. So I agree it's
terribly annoying! Maybe I'll have a look at the source sometime, but it
would be a miracle if I found it.
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2007-03-14 21:25
Message:
Logged In: YES
user_id=1709568
Originator: YES
> Isn't it intended to let access GUI elements which are on the bottom of
> stack, thus taking them to the top (in rotation)? Because if
The bottom element is not taken to the top. It remains on the bottom, and
it keeps receiving the events; the front-most element never receives the
event.
Furthermore, I am concerned especially about non-edit mode, and I don't
think that anything should rotate when not editing.
Have a look at the attached patch (depth_bug.pd).
By the way, sorry for not attaching an example before.
It just makes no sense that you are clicking on what is hidden rather than
on what is visible.
File Added: depth_bug.pd
----------------------------------------------------------------------
Comment By: inn0c (inn0c)
Date: 2007-03-14 11:09
Message:
Logged In: YES
user_id=1493916
Originator: NO
> However, the opposite happens: the gui element which is behind is the
one that you move.
Isn't it intended to let access GUI elements which are on the bottom of
stack, thus taking them to the top (in rotation)? Because if
> the correct behaviour was that the front-most element "receive" the
mouse click
then the front-most element would be the only one that receives while the
others stayed intact.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1678373&group_…
Bugs item #1795369, was opened at 2007-09-15 05:47
Message generated for change (Comment added) made by stffn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1795369&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: marius schebella (mariusschebella)
Assigned to: Nobody/Anonymous (nobody)
Summary: red border GOP
Initial Comment:
hey,
when I have a subpatch that contains no element in it, but is a GOP, then I don't see the red GOP border.
that does not seem to be a problem. BUT...
when I use this empty subpatch and create an object in it via message command, then that red border suddenly is visible in the parent patch.
see attached file.
marius.
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2007-10-16 15:58
Message:
Logged In: YES
user_id=1658640
Originator: NO
This seam very similar to the report #1351274 called "pd 0.39-1 GOP
bounding box doesn't appear if no objects".
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1795369&group_…
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_…