Patches item #1094912, was opened at 2005-01-03 11:56
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1094912&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: wishlist
>Status: Open
Resolution: None
Priority: 6
Submitted By: Tim Blechmann (timblech)
Assigned to: Miller Puckette (millerpuckette)
Summary: message-based access to the audio api
Initial Comment:
attached is a patch that simplifies message-based
access to the audio api:
pd understands the following messages:
audio-samplerate
audio-delay
audio-dacblocksize
audio-scheduler
audio-device
audio-device-in
audio-device-out
audio-dacblocksize and audio-scheduler require devel_0_38
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2006-10-18 09:58
Message:
Logged In: YES
user_id=564396
as carmen has pointed out on the list, miller had just very
recently articulated a very similar idea.
even though it is unlikely that he will use the patch here,
i reopen this issue (and hopefully will close it again soon
when an equivalent mechanism will be part of pd)
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-10-17 07:41
Message:
Logged In: YES
user_id=27104
this has been here for a long while with no activity, so I
am setting it to Pending. It'll be automatically set to
closed after a while if no one tends to it.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-01-29 03:34
Message:
Logged In: YES
user_id=27104
I am liking the idea of sending messages to pd to get all of
this kind of information more and more. I am thinking that
a generic "get" message would be useful here. Like this:
[;pd get audio-samplerate(
[;pd get audio-delay(
[;pd get audio-dacblocksize(
[;pd get audio-scheduler(
[;pd get audio-device(
[;pd get audio-device-in(
[;pd get audio-device-out(
Then also:
[;pd get path(
[;pd get libs(
[;pd get version(
[;pd get dsp(
Then you could get similar messages from each canvas/patch:
[;pd-my_patch.pd get editmode(
[;pd-my_patch.pd get vis(
[;pd-my_patch.pd get namespace(
[;pd-my_patch.pd get canvasname(
You would retrieve these messages with a [receive] of the
same name, i.e.:
[r pd]
|
[route version]
|
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2005-05-18 06:36
Message:
Logged In: YES
user_id=313747
I'm scared of this one... how important is it to have all the
different audio parameters handled by separate messages? I
think the "audio_dialog" message should suffice for setting
audio parameters...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1094912&group_…
Patches item #1094912, was opened at 2005-01-03 05:56
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1094912&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: wishlist
>Status: Pending
Resolution: None
Priority: 6
Submitted By: Tim Blechmann (timblech)
Assigned to: Miller Puckette (millerpuckette)
Summary: message-based access to the audio api
Initial Comment:
attached is a patch that simplifies message-based
access to the audio api:
pd understands the following messages:
audio-samplerate
audio-delay
audio-dacblocksize
audio-scheduler
audio-device
audio-device-in
audio-device-out
audio-dacblocksize and audio-scheduler require devel_0_38
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-10-17 01:41
Message:
Logged In: YES
user_id=27104
this has been here for a long while with no activity, so I
am setting it to Pending. It'll be automatically set to
closed after a while if no one tends to it.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-01-28 21:34
Message:
Logged In: YES
user_id=27104
I am liking the idea of sending messages to pd to get all of
this kind of information more and more. I am thinking that
a generic "get" message would be useful here. Like this:
[;pd get audio-samplerate(
[;pd get audio-delay(
[;pd get audio-dacblocksize(
[;pd get audio-scheduler(
[;pd get audio-device(
[;pd get audio-device-in(
[;pd get audio-device-out(
Then also:
[;pd get path(
[;pd get libs(
[;pd get version(
[;pd get dsp(
Then you could get similar messages from each canvas/patch:
[;pd-my_patch.pd get editmode(
[;pd-my_patch.pd get vis(
[;pd-my_patch.pd get namespace(
[;pd-my_patch.pd get canvasname(
You would retrieve these messages with a [receive] of the
same name, i.e.:
[r pd]
|
[route version]
|
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2005-05-18 00:36
Message:
Logged In: YES
user_id=313747
I'm scared of this one... how important is it to have all the
different audio parameters handled by separate messages? I
think the "audio_dialog" message should suffice for setting
audio parameters...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1094912&group_…
Bugs item #1531757, was opened at 2006-07-31 09:46
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1531757&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: Postponed
Priority: 5
Submitted By: Jamie Bullock (postlude)
Assigned to: Nobody/Anonymous (nobody)
Summary: Opening curly brace causes freeze until a closing brace
Initial Comment:
Typing a curly brace '{' anywhere in pd causes a freeze
until a closing brace is given.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-10-18 20:25
Message:
Logged In: YES
user_id=27104
Since it wasn't really fixed, but rather just worked around,
I changed the resolution to something hopefully more
appropriate.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2006-10-18 04:13
Message:
Logged In: YES
user_id=564396
seems like this is fixed with pd-0.40-1 (probably earlier):
typing opening curly brace results in "keycode 123: dropped".
(the better solution would of course be to properly escape
curly brackets so that they could be used)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1531757&group_…
Bugs item #1518048, was opened at 2006-07-06 10:18
Message generated for change (Comment added) made by claudiusmaximus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1518048&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
Submitted By: ClaudiusMaximus (claudiusmaximus)
Assigned to: Nobody/Anonymous (nobody)
Summary: percent symbol (%) behaves weirdly in iemgui object labels
Initial Comment:
When the properties window of a vslider is opened after
the label has been set to a name containing %p, the
label changes to something with the %p replaced by a
seemingly random hexadecimal value.
I haven't checked which other gui objects are affected,
nor whether other % codes (eg, %d or %f) are similarly
affected.
See attached pd patch for an example - click the bng
and then open the properties window for the vslider.
----------------------------------------------------------------------
>Comment By: ClaudiusMaximus (claudiusmaximus)
Date: 2006-10-18 16:50
Message:
Logged In: YES
user_id=769033
Fixed in DesireData 0.39.A (anon CVS checkout as of today).
----------------------------------------------------------------------
Comment By: ClaudiusMaximus (claudiusmaximus)
Date: 2006-10-18 16:12
Message:
Logged In: YES
user_id=769033
Behaves the same in pd-0.40-1 from Miller's site.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1518048&group_…
Bugs item #1518030, was opened at 2006-07-06 09:54
Message generated for change (Comment added) made by claudiusmaximus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1518030&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: 7
Submitted By: ClaudiusMaximus (claudiusmaximus)
Assigned to: Miller Puckette (millerpuckette)
Summary: subpatch clearing itself crashes Pd
Initial Comment:
Tested on Linux with pd-0.39-2 from Miller's site.
Steps to reproduce:
start pd
load the patch attached to this post
click the bng
close the patch
load the patch again
click the bng
=> crash
OR
start pd
load the patch
open the subpatch
(optionally: close the subpatch)
click the bng
=> crash
Here's a gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 27794)]
pd_bang (x=0x11) at m_pd.c:269
269 m_pd.c: No such file or directory.
in m_pd.c
(gdb) where
#0 pd_bang (x=0x11) at m_pd.c:269
#1 0x0808a61b in outlet_bang (x=0x3) at m_obj.c:328
#2 0x080765ad in bng_bout2 (x=0x81f2790) at g_bang.c:294
#3 0x080767f6 in bng_newclick (z=0x11,
glist=0x81f2338, xpix=74, ypix=70,
shift=0, alt=0, dbl=0, doit=1) at g_bang.c:343
#4 0x0806e907 in gobj_click (x=0x0, glist=0x11,
xpix=17, ypix=17, shift=17,
alt=17, dbl=17, doit=17) at g_editor.c:92
#5 0x0805b557 in graph_click (z=0x81f2338, glist=0x11,
xpix=74, ypix=70,
shift=0, alt=0, dbl=17, doit=1) at g_graph.c:1059
#6 0x0806e907 in gobj_click (x=0x0, glist=0x11,
xpix=17, ypix=17, shift=17,
alt=17, dbl=17, doit=17) at g_editor.c:92
#7 0x08070a97 in canvas_doclick (x=0x81ecd08, xpos=74,
ypos=70, which=1,
mod=0, doit=1) at g_editor.c:1094
#8 0x0807119d in canvas_mousedown (x=0x11, xpos=0,
ypos=0, which=0, mod=0)
at g_editor.c:1252
#9 0x08089789 in pd_typedmess (x=0x81ecd08, s=0x0,
argc=0, argv=0x80cf488)
at m_class.c:728
#10 0x08089665 in pd_typedmess (x=0x81f25f8, s=0x0,
argc=4, argv=0x80cf468)
at m_class.c:749
#11 0x0808c32f in binbuf_eval (x=0x11,
target=0x81f25f8, argc=0, argv=0x0)
at m_binbuf.c:574
#12 0x08091fdf in socketreceiver_read (x=0x81ec2f0,
fd=7) at s_inter.c:540
#13 0x0809180f in sys_domicrosleep (microsec=17,
pollem=1) at s_inter.c:180
#14 0x08092660 in sys_pollgui () at s_inter.c:823
#15 0x0808fe5b in m_scheduler () at m_sched.c:466
#16 0x08095b1b in main (argc=17, argv=0x11) at s_entry.c:27
----------------------------------------------------------------------
>Comment By: ClaudiusMaximus (claudiusmaximus)
Date: 2006-10-18 16:30
Message:
Logged In: YES
user_id=769033
Some comments about pd-0.40-1 from Miller's site:
1. Start pd, load gop-subpatch-self-clear-crash.pd, click
bang => no crash, subpatch is cleared correctly
2. Start pd, load gop-subpatch-self-clear-crash.pd, open
subpatch, click bang => crash:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211095376 (LWP 13534)]
pd_bang (x=0x11) at m_pd.c:269
269 (*(*x)->c_bangmethod)(x);
(gdb) bt
#0 pd_bang (x=0x11) at m_pd.c:269
#1 0x080aa8eb in outlet_bang (x=0x82371f8) at m_obj.c:328
#2 0x0808f101 in bng_newclick (z=0x82415c8,
glist=0x8241200, xpix=136,
ypix=139, shift=0, alt=0, dbl=0, doit=1) at g_bang.c:294
#3 0x0808a36a in canvas_doclick (x=0x8241200, xpos=136,
ypos=139, which=1,
mod=0, doit=1) at g_editor.c:92
#4 0x0808b14b in canvas_mousedown (x=0x8241200, xpos=136,
ypos=139, which=1,
mod=0) at g_editor.c:1242
#5 0x080a79c5 in pd_typedmess (x=0x8241200, s=0x822ac40,
argc=4,
argv=0x811a928) at m_class.c:728
#6 0x080a7632 in pd_typedmess (x=0x8241418, s=0x822ac40,
argc=<value optimized out>, argv=0x811a928) at m_class.c:749
#7 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value
optimized out>,
argc=0, argv=0x0) at m_binbuf.c:673
#8 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at
s_inter.c:540
#9 0x080b693e in sys_domicrosleep (microsec=<value
optimized out>,
pollem=<value optimized out>) at s_inter.c:180
#10 0x080b7967 in sys_pollgui () at s_inter.c:825
#11 0x080b2f53 in m_scheduler () at m_sched.c:466
#12 0x080b651a in sys_main (argc=1, argv=0xbfcbb4a4) at
s_main.c:316
#13 0x080bf7cf in main (argc=136563232, argv=0x8242b00) at
s_entry.c:27
3. Start pd, load gop-subpatch-self-clear-crash.pd, open
subpatch, close subpatch, click bang => crash
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210849616 (LWP 13563)]
pd_bang (x=0x11) at m_pd.c:269
269 (*(*x)->c_bangmethod)(x);
(gdb) bt
#0 pd_bang (x=0x11) at m_pd.c:269
#1 0x080aa8eb in outlet_bang (x=0x82373c0) at m_obj.c:328
#2 0x0808f101 in bng_newclick (z=0x823cbc0,
glist=0x8237230, xpix=72,
ypix=70, shift=0, alt=0, dbl=0, doit=1) at g_bang.c:294
#3 0x0805be1a in graph_click (z=0x8237230, glist=0x8237090,
xpix=72, ypix=70,
shift=0, alt=0, dbl=0, doit=1) at g_graph.c:1052
#4 0x0808a36a in canvas_doclick (x=0x8237090, xpos=72,
ypos=70, which=1,
mod=0, doit=1) at g_editor.c:92
#5 0x0808b14b in canvas_mousedown (x=0x8237090, xpos=72,
ypos=70, which=1,
mod=0) at g_editor.c:1242
#6 0x080a79c5 in pd_typedmess (x=0x8237090, s=0x822ac40,
argc=4,
argv=0x811a928) at m_class.c:728
#7 0x080a7632 in pd_typedmess (x=0x823ca28, s=0x822ac40,
argc=<value optimized out>, argv=0x811a928) at m_class.c:749
#8 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value
optimized out>,
argc=0, argv=0x0) at m_binbuf.c:673
#9 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at
s_inter.c:540
#10 0x080b693e in sys_domicrosleep (microsec=<value
optimized out>,
pollem=<value optimized out>) at s_inter.c:180
#11 0x080b7967 in sys_pollgui () at s_inter.c:825
#12 0x080b2f53 in m_scheduler () at m_sched.c:466
#13 0x080b651a in sys_main (argc=1, argv=0xbfeee6d4) at
s_main.c:316
#14 0x080bf7cf in main (argc=136541136, argv=0x823e958) at
s_entry.c:27
4. Start pd, load crash-1518030.pd, click "bang" => crash:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210677584 (LWP 13575)]
pd_bang (x=0x11) at m_pd.c:269
269 (*(*x)->c_bangmethod)(x);
(gdb) bt
#0 pd_bang (x=0x11) at m_pd.c:269
#1 0x080aa8eb in outlet_bang (x=0x8237408) at m_obj.c:328
#2 0x080aa8eb in outlet_bang (x=0x82373d0) at m_obj.c:328
#3 0x080aa8eb in outlet_bang (x=0x823cce0) at m_obj.c:328
#4 0x080a77a1 in pd_typedmess (x=0x823cccc, s=0x8119364,
argc=0,
argv=0x811a950) at m_class.c:641
#5 0x080abba4 in binbuf_eval (x=0x823cc68, target=<value
optimized out>,
argc=1, argv=0xbfa50e8c) at m_binbuf.c:673
#6 0x0805f46d in message_click (x=0x823ccb0, xpos=91,
ypos=65, shift=0,
ctrl=0, alt=0) at g_text.c:300
#7 0x08063721 in text_click (z=0x823ccb0, glist=0x8237080,
xpix=91, ypix=65,
shift=0, alt=0, dbl=0, doit=1) at g_text.c:1065
#8 0x0808a36a in canvas_doclick (x=0x8237080, xpos=91,
ypos=65, which=1,
mod=0, doit=1) at g_editor.c:92
#9 0x0808b14b in canvas_mousedown (x=0x8237080, xpos=91,
ypos=65, which=1,
mod=0) at g_editor.c:1242
#10 0x080a79c5 in pd_typedmess (x=0x8237080, s=0x822ac40,
argc=4,
argv=0x811a928) at m_class.c:728
#11 0x080a7632 in pd_typedmess (x=0x823ca28, s=0x822ac40,
argc=<value optimized out>, argv=0x811a928) at m_class.c:749
#12 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value
optimized out>,
argc=0, argv=0x0) at m_binbuf.c:673
#13 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at
s_inter.c:540
#14 0x080b693e in sys_domicrosleep (microsec=<value
optimized out>,
pollem=<value optimized out>) at s_inter.c:180
#15 0x080b7967 in sys_pollgui () at s_inter.c:825
#16 0x080b2f53 in m_scheduler () at m_sched.c:466
#17 0x080b651a in sys_main (argc=1, argv=0xbfa52a44) at
s_main.c:316
#18 0x080bf7cf in main (argc=0, argv=0x0) at s_entry.c:27
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2006-10-10 15:13
Message:
Logged In: YES
user_id=564396
the really interesting thing here, is that your patch will
not crash when you only click on the [bng] once. you have to
follow the steps as described.
i add another patch that triggers the crash reliable and
without the complicated procedure (just click it and crash it)
raised priority, since crashers should be fixed.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2006-07-06 18:48
Message:
Logged In: YES
user_id=564396
this has nothing to do with GOP, therefore i renamed the
bug-report.
what happens: an object emits a message; the calling
function is pushed to the stack; the message triggers the
deletion of the object; after the message is done, the
calling function (of the now deleted object) is popped back
from the stack: but alas! the entire environment has changed
and nothing is as it should be....stack corruption -> crash.
personally i think, that this is NOT a bug in pd but rather
a bug in the patch (but i am repeating myself...)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1518030&group_…
Bugs item #1349967, was opened at 2005-11-07 06:09
Message generated for change (Comment added) made by claudiusmaximus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1349967&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: 5
Submitted By: ClaudiusMaximus (claudiusmaximus)
Assigned to: Nobody/Anonymous (nobody)
Summary: 0.39-1 pd -jack doesn't set requested channels
Initial Comment:
(with no .pdrc, doesn't make a difference if these
flags are in there either)
$ pd -jack -inchannels 2 -outchannels 2 -verbose -stderr
input channels = 0, output channels = 0
Pd version 0.39-1
compiled 05:20:44 Nov 7 2005
port 5401
TCL_LIBRARY="/usr/local/lib/pd/tcl/library"
TK_LIBRARY="/usr/local/lib/pd/tk/library"
"/usr/local/lib/pd/bin/pd-gui" 5401
Waiting for connection request...
... connected
opened 0 MIDI input device(s) and 0 MIDI output device(s).
input channels = 0, output channels = 0
It is very inconvenient to have to set the number of
channels (and activate them) in the settings dialog
each time Pd is started.
>From what I can remember, it worked fine (ie, set the
requested number of channels and activated them) in Pd
0.39-0test6.
----------------------------------------------------------------------
>Comment By: ClaudiusMaximus (claudiusmaximus)
Date: 2006-10-18 16:19
Message:
Logged In: YES
user_id=769033
Fixed in pd-0.40-1 from Miller's site:
$ ./pd -jack -inchannels 2 -outchannels 2 -verbose -stderr
input channels = 2, output channels = 2
Pd version 0.40-1
compiled 16:51:03 Oct 18 2006
port 5401
TCL_LIBRARY="../tcl/library" TK_LIBRARY="../tk/library"
"../bin/pd-gui" 5401
Waiting for connection request...
... connected
opened 0 MIDI input device(s) and 0 MIDI output device(s).
input channels = 2, output channels = 2
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1349967&group_…
Bugs item #1351274, was opened at 2005-11-08 14:15
Message generated for change (Comment added) made by claudiusmaximus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1351274&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
Submitted By: ClaudiusMaximus (claudiusmaximus)
Assigned to: Nobody/Anonymous (nobody)
Summary: pd 0.39-1 GOP bounding box doesn't appear if no objects
Initial Comment:
This is minor, but confused me and made me think
something was broken:
Create a new patch, don't create any objects.
Make the patch graph-on-parent.
The red GOP bounding box doesn't appear until the first
object is created (pressing Ctrl-1 without typing an
object name is enough).
Alternatively,
Create a new patch, create some objects, delete them all.
Make the patch graph-on-parent.
The red GOP bounding box doesn't appear until a new
object is created (pressing Ctrl-1 without typing an
object name is enough).
Once GOP is activated for the first time, the bounding
box appears correctly when there are no objects, even
when GOP is turned off and on again.
Pd version 0.39-1
compiled 05:20:44 Nov 7 2005
----------------------------------------------------------------------
>Comment By: ClaudiusMaximus (claudiusmaximus)
Date: 2006-10-18 16:14
Message:
Logged In: YES
user_id=769033
Behaves the same in pd-0.40-1 from Miller's site.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1351274&group_…
Bugs item #1518048, was opened at 2006-07-06 10:18
Message generated for change (Comment added) made by claudiusmaximus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1518048&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
Submitted By: ClaudiusMaximus (claudiusmaximus)
Assigned to: Nobody/Anonymous (nobody)
Summary: percent symbol (%) behaves weirdly in iemgui object labels
Initial Comment:
When the properties window of a vslider is opened after
the label has been set to a name containing %p, the
label changes to something with the %p replaced by a
seemingly random hexadecimal value.
I haven't checked which other gui objects are affected,
nor whether other % codes (eg, %d or %f) are similarly
affected.
See attached pd patch for an example - click the bng
and then open the properties window for the vslider.
----------------------------------------------------------------------
>Comment By: ClaudiusMaximus (claudiusmaximus)
Date: 2006-10-18 16:12
Message:
Logged In: YES
user_id=769033
Behaves the same in pd-0.40-1 from Miller's site.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1518048&group_…
Bugs item #1475239, was opened at 2006-04-24 02:46
Message generated for change (Comment added) made by claudiusmaximus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1475239&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: 5
Submitted By: ClaudiusMaximus (claudiusmaximus)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch's "confirm close" dialog messes up pd main window exit
Initial Comment:
Steps to reproduce the problem:
1. start Pd
2. create a new patch
3. close the new patch, don't select anything in the
confirmation dialog
4. close the main pd window
At this point all Pd windows are closed, but pd and
pd-gui are still running, which can be observed if
audio is running. If gui objects are being updated, pd
prints out reams of 'invalid command name
".x83a56a0.c"' messages.
Hitting Ctrl-C in the terminal I started Pd from makes
Pd exit cleanly.
Tested on GNU/Linux with pd-0.39-2 (source downloaded
from MSP's site).
----------------------------------------------------------------------
>Comment By: ClaudiusMaximus (claudiusmaximus)
Date: 2006-10-18 16:06
Message:
Logged In: YES
user_id=769033
Fixed in pd-0.40-1 downloaded from Miller's site.
Specifically, the main window close button now pops up a
"Really Quit" dialog, which replaces the "Really Close"
dialog that pops up from the patch window close button, so
it is no longer possible to close the main window while the
patch close dialog is open.
Thanks!
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2006-10-18 10:24
Message:
Logged In: YES
user_id=564396
this seems to be fixed in pd-0.40-1 (at least i was not able
to close the main-window as long as the confirmation dialog
for the patch was still open).
could you confirm that this has been fixed?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1475239&group_…
Bugs item #1475239, was opened at 2006-04-24 04:46
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1475239&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
Submitted By: ClaudiusMaximus (claudiusmaximus)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch's "confirm close" dialog messes up pd main window exit
Initial Comment:
Steps to reproduce the problem:
1. start Pd
2. create a new patch
3. close the new patch, don't select anything in the
confirmation dialog
4. close the main pd window
At this point all Pd windows are closed, but pd and
pd-gui are still running, which can be observed if
audio is running. If gui objects are being updated, pd
prints out reams of 'invalid command name
".x83a56a0.c"' messages.
Hitting Ctrl-C in the terminal I started Pd from makes
Pd exit cleanly.
Tested on GNU/Linux with pd-0.39-2 (source downloaded
from MSP's site).
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2006-10-18 12:24
Message:
Logged In: YES
user_id=564396
this seems to be fixed in pd-0.40-1 (at least i was not able
to close the main-window as long as the confirmation dialog
for the patch was still open).
could you confirm that this has been fixed?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1475239&group_…