Sorry, I forgot saying I'm using pd 0.38.4 (from debian distro).
Hi!
I have noted a strange behaviour when input is taken from an [inlet~] in a subpatch which contains the [switch~] object.
The attached patch includes a subpatch with an [osc~]. There is an [inlet] for switching the subpatch on/off and an [inlet~] for passing the frequency of the oscillator (which could be control or audio rate).
Note that when you feed the frequency with a [sig~] it works, but when sending [0( and [440( messages it doesn't (of course, disconnect the [sig~] before). Then try deleting the [switch~] in the supatch. Once [switch~] is deleted, the subpatch works both when receiving frequency as messages and when receiving it as an audio stream, which if I'm not wrong is the right behaviour.
Is this a bug?
Thank you. Regards, Carlos
I have played a little more with the test patch and I found out that the cause is not the [switch~] presence but the [inlet~] being a second inlet (I thought it was [switch~] being there because when I deleted the [switch~] section of the subpatch the frequency [inlet~] became the first inlet).
I guess it could be related with hot/cold inlets but I can't think of a rationale for the behaviour.
See the attached subpatches. testx's subpatch has a dummy first inlet while testy's one has only one inlet for frequency. The first doesn't work. The second works ok.
Regards, Carlos
Sorry, I forgot saying I'm using pd 0.38.4 (from debian distro).
Hi!
I have noted a strange behaviour when input is taken from an [inlet~] in a subpatch which contains the [switch~] object.
The attached patch includes a subpatch with an [osc~]. There is an [inlet] for switching the subpatch on/off and an [inlet~] for passing the frequency of the oscillator (which could be control or audio rate).
Note that when you feed the frequency with a [sig~] it works, but when sending [0( and [440( messages it doesn't (of course, disconnect the [sig~] before). Then try deleting the [switch~] in the supatch. Once [switch~] is deleted, the subpatch works both when receiving frequency as messages and when receiving it as an audio stream, which if I'm not wrong is the right behaviour.
Is this a bug?
Thank you. Regards, Carlos
This is a bug... might take some time to fix!
Thanks for flagging it.
Miller
On Mon, May 02, 2005 at 07:00:07AM -0300, Carlos Pita wrote:
Sorry, I forgot saying I'm using pd 0.38.4 (from debian distro).
Hi!
I have noted a strange behaviour when input is taken from an [inlet~] in a subpatch which contains the [switch~] object.
The attached patch includes a subpatch with an [osc~]. There is an [inlet] for switching the subpatch on/off and an [inlet~] for passing the frequency of the oscillator (which could be control or audio rate).
Note that when you feed the frequency with a [sig~] it works, but when sending [0( and [440( messages it doesn't (of course, disconnect the [sig~] before). Then try deleting the [switch~] in the supatch. Once [switch~] is deleted, the subpatch works both when receiving frequency as messages and when receiving it as an audio stream, which if I'm not wrong is the right behaviour.
Is this a bug?
Thank you. Regards, Carlos
#N canvas 0 0 450 300 10; #X obj 127 135 dac~; #X obj 91 62 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1 ; #X msg 124 39 0; #X msg 160 39 440; #X obj 197 38 sig~ 440; #N canvas 0 0 450 300 osc 0; #X obj 123 103 outlet~; #X obj 21 38 inlet to; #X obj 121 39 inlet~ fr; #X obj 122 70 osc~; #X obj 22 74 switch~; #X connect 1 0 4 0; #X connect 2 0 3 0; #X connect 3 0 0 0; #X restore 127 105 pd osc; #X connect 1 0 5 0; #X connect 2 0 5 1; #X connect 3 0 5 1; #X connect 4 0 5 1; #X connect 5 0 0 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanks for the bug report, can you file a Bug Tracker on the
sourceforge site? It helps us keep track of what needs doing:
http://sourceforge.net/tracker/?group_id=55736&atid=478070
.hc
On Mon, May 02, 2005 at 07:00:07AM -0300, Carlos Pita wrote:
Sorry, I forgot saying I'm using pd 0.38.4 (from debian distro).
Hi!
I have noted a strange behaviour when input is taken from an [inlet~] in a subpatch which contains the [switch~] object.
The attached patch includes a subpatch with an [osc~]. There is an [inlet] for switching the subpatch on/off and an [inlet~] for passing the frequency of the oscillator (which could be control or audio rate).
Note that when you feed the frequency with a [sig~] it works, but when sending [0( and [440( messages it doesn't (of course, disconnect the [sig~] before). Then try deleting the [switch~] in the supatch. Once [switch~] is deleted, the subpatch works both when receiving frequency as messages and when receiving it as an audio stream, which if I'm not wrong is the right behaviour.
Is this a bug?
Thank you. Regards, Carlos
#N canvas 0 0 450 300 10; #X obj 127 135 dac~; #X obj 91 62 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1 ; #X msg 124 39 0; #X msg 160 39 440; #X obj 197 38 sig~ 440; #N canvas 0 0 450 300 osc 0; #X obj 123 103 outlet~; #X obj 21 38 inlet to; #X obj 121 39 inlet~ fr; #X obj 122 70 osc~; #X obj 22 74 switch~; #X connect 1 0 4 0; #X connect 2 0 3 0; #X connect 3 0 0 0; #X restore 127 105 pd osc; #X connect 1 0 5 0; #X connect 2 0 5 1; #X connect 3 0 5 1; #X connect 4 0 5 1; #X connect 5 0 0 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"The arc of history bends towards justice."
Dr.
Martin Luther King, Jr.
-
Carlos Pita -
Hans-Christoph Steiner -
Miller Puckette