Dear Pd-list
I noticed a funny behavior when sending messages to dac~'s inlet:
sending a number, eg "1" to its inlet will not produce a corresponding DC signal at Pd's audio output. The DC signal is output when I delete this message.
Steps to reproduce: Start Pd and create an empty patch and turn on DSP. Create [dac~] create a [1 < message connect it to one inlet of [dac~] Send the message to [dac~]. Note that no click is audible. Then select the message and hit backspace. Click! Signal is output.
This only occurs the first time.
Is this know, explainable and does it "mean" something? ;)
cheersz, P
Usually float messages are "promoted" to signals in tilde objects. This behaviour seems weird indeed to me. We can "fix" it by adding a "CLASS_MAINSIGNALIN" into the code I guess... should we do this at the develop branch? Or open a new ticket on github?
you can just use [sig~] anyway
cheers
Em seg., 6 de dez. de 2021 às 14:00, Peter P. peterparker@fastmail.com escreveu:
Dear Pd-list
I noticed a funny behavior when sending messages to dac~'s inlet:
sending a number, eg "1" to its inlet will not produce a corresponding DC signal at Pd's audio output. The DC signal is output when I delete this message.
Steps to reproduce: Start Pd and create an empty patch and turn on DSP. Create [dac~] create a [1 < message connect it to one inlet of [dac~] Send the message to [dac~]. Note that no click is audible. Then select the message and hit backspace. Click! Signal is output.
This only occurs the first time.
Is this know, explainable and does it "mean" something? ;)
cheersz, P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Usually float messages are "promoted" to signals in tilde objects.
This is known to me and I am fine with it. The behavior I describe is about the signal being output when I delete a message box.
On 12/6/21 17:57, Peter P. wrote:
Is this know, explainable and does it "mean" something? ;)
it's known (that is: the group of problems to which this one belongs)
here's a layman explanation (that i haven't actually checked with the source code):
whenever you patch with signal objects (that is: create a new object~, delete a object~, connet object~s), the DSP graph gets re-compiled (if dsp is on). this is not true for non-signal objects: adding/connecting non-signal objects is not going to change the DSP graph, so it is not re-compiled (however, it does need to be recompiled if you remove a non-signal object...why? just think [table]).
now with your single [dac~] object, there is not much of a DSP-graph to compute, so Pd obviously does nothing. esp. the float-to-signal conversion seems to be not activated yet. adding a single msgbox and connecting it to [dac~] doesn't change anything in this regard, so Pd doesn't "notice" that it now has to actually do the float-to-signal forwarding.
you can force a re-compilation of the DSP graph (which will make Pd pick up the float-to-signal conversion) by saving your patch (notice that get the click). you can also force it by removing any object (or msgbox!) - which you already know.
you could also connect a [sig~ 0] to the *second* inlet of the [dac~] tat the beginning: this will not do much except creating a (small) DSP-graph of which [dac~] is part of. if you then create you msgbox and send [1( to the *first* (otherwise unconnected) inlet of [dac~] you also get a click.
gfmds IOhannes
Dear IOhannes,
crazy, thank you for the pristine explanation, is makes sense now! What still puzzles me is that [dac~] does not output a signal when it receives the "1" message.
Thanks again, P
On 12/6/21 17:57, Peter P. wrote:
Is this know, explainable and does it "mean" something? ;)
it's known (that is: the group of problems to which this one belongs)
here's a layman explanation (that i haven't actually checked with the source code):
whenever you patch with signal objects (that is: create a new object~, delete a object~, connet object~s), the DSP graph gets re-compiled (if dsp is on). this is not true for non-signal objects: adding/connecting non-signal objects is not going to change the DSP graph, so it is not re-compiled (however, it does need to be recompiled if you remove a non-signal object...why? just think [table]).
now with your single [dac~] object, there is not much of a DSP-graph to compute, so Pd obviously does nothing. esp. the float-to-signal conversion seems to be not activated yet. adding a single msgbox and connecting it to [dac~] doesn't change anything in this regard, so Pd doesn't "notice" that it now has to actually do the float-to-signal forwarding.
you can force a re-compilation of the DSP graph (which will make Pd pick up the float-to-signal conversion) by saving your patch (notice that get the click). you can also force it by removing any object (or msgbox!) - which you already know.
you could also connect a [sig~ 0] to the *second* inlet of the [dac~] tat the beginning: this will not do much except creating a (small) DSP-graph of which [dac~] is part of. if you then create you msgbox and send [1( to the *first* (otherwise unconnected) inlet of [dac~] you also get a click.
gfmds IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
The "problem" is that Pd doesn't recompute the DSP graph when you *add* an object. Instead it recomputes the graph when you make a new signal connection (or when you delete an object, save a patch, etc.) So when you add the [dac~] object, the graph is not updated and it doesn't compute audio (yet). Only when you force a DSP graph update - in your case by deleting an object - it starts computing audio.
BTW, the problem you see with [dac~] is basically the same as with [bang~]. The latter doesn't output bangs immediately after creation but rather on the next DSP graph update. This has caused quite some confusion in the past.
Christof
On 06.12.2021 19:18, Peter P. wrote:
Dear IOhannes,
crazy, thank you for the pristine explanation, is makes sense now! What still puzzles me is that [dac~] does not output a signal when it receives the "1" message.
Thanks again, P
- IOhannes m zmölnig zmoelnig@iem.at [2021-12-06 19:04]:
On 12/6/21 17:57, Peter P. wrote:
Is this know, explainable and does it "mean" something? ;)
it's known (that is: the group of problems to which this one belongs)
here's a layman explanation (that i haven't actually checked with the source code):
whenever you patch with signal objects (that is: create a new object~, delete a object~, connet object~s), the DSP graph gets re-compiled (if dsp is on). this is not true for non-signal objects: adding/connecting non-signal objects is not going to change the DSP graph, so it is not re-compiled (however, it does need to be recompiled if you remove a non-signal object...why? just think [table]).
now with your single [dac~] object, there is not much of a DSP-graph to compute, so Pd obviously does nothing. esp. the float-to-signal conversion seems to be not activated yet. adding a single msgbox and connecting it to [dac~] doesn't change anything in this regard, so Pd doesn't "notice" that it now has to actually do the float-to-signal forwarding.
you can force a re-compilation of the DSP graph (which will make Pd pick up the float-to-signal conversion) by saving your patch (notice that get the click). you can also force it by removing any object (or msgbox!) - which you already know.
you could also connect a [sig~ 0] to the *second* inlet of the [dac~] tat the beginning: this will not do much except creating a (small) DSP-graph of which [dac~] is part of. if you then create you msgbox and send [1( to the *first* (otherwise unconnected) inlet of [dac~] you also get a click.
gfmds IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
The "problem" is that Pd doesn't recompute the DSP graph when you *add* an object. Instead it recomputes the graph when you make a new signal connection (or when you delete an object, save a patch, etc.) So when you add the [dac~] object, the graph is not updated and it doesn't compute audio (yet).
So one solitary dsp~ object does not make a graph yet, correct?
Thänks, P
Not until you force a DSP graph update. Since a solitary DSP object can't have a signal connection, you have to resort to other means, like deleting an object or saving the patch.
On 06.12.2021 19:30, Peter P. wrote:
- Christof Ressi info@christofressi.com [2021-12-06 19:24]:
The "problem" is that Pd doesn't recompute the DSP graph when you *add* an object. Instead it recomputes the graph when you make a new signal connection (or when you delete an object, save a patch, etc.) So when you add the [dac~] object, the graph is not updated and it doesn't compute audio (yet).
So one solitary dsp~ object does not make a graph yet, correct?
Thänks, P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list