I'm working on an audio patchbay function, with a small abstraction that simply [receive~]'s from one bus and [throw~]'s to another. I'm using $1 and $2 in the bus names, but that doesn't seem to be the issue, as it does the same for fixed-name buses as well.
What happens is that when I create the abstraction live, no sound passes. I can then save the canvas, toggle the DSP, and sometimes even edit unrelated parts of the patch, and PD will then "wake up" and start passing audio through the abstraction.
I'd rather not force a toggle of DSP or a saving of a canvas to get around this, as that will have other ramifications for the rest of my sprawling live patch.
I've been shown that generating the abstraction dynamically causes everything to work as it should, so that is an acceptable workaround for me, though not an extremely user-friendly one for some, so I thought I'd bring it up to the list
This applies to any combination of [send~], [receive~], [throw~], or [catch~].
Here's a link to a .zip of a very simple demo of the problem. Just load demo.pd, and the instructions are in the comments. https://ufile.io/e2dvk
I'm running Vanilla .48-0 on Linux Mint.
Thanks!
On 12/17/2017 06:40 PM, Brady Sharp wrote:
[...]
this is kind of known (at least to me :-)). my workaround for live coding sessions is simply to hit Ctrl-S (save the patch), which will force a recompilation of the DSP graph as well. that workaround is so simple and effective, that i didn't really bother to find a real solution for the problem.
I'd rather not force a toggle of DSP or a saving of a canvas to get around this, as that will have other ramifications for the rest of my sprawling live patch.
now, if this were true then you are in serious trouble. turning the DSP on (and to turn it "on", you might have to turn it "off" first) will recalculate the DSP graph. you might want to avoid that, but then you shouldn't do any patching, as putting in a new DSP object might trigger the very same (unless of course you are hitting a bug like the one you were initially describing)
magf IOhannes
Thanks IOhannes.
For me, the dynamic patch option (included in the demo link I sent) is probably the best workaround, since it passes audio instantly upon creation as expected. Since I'm usually holding a guitar as I perform, it's fewer keystrokes and stuff I'll need to worry about. I'd rather not toggle DSP, since I could be in the midst of recording a long loop or something, and if I'm going out on a limb in how I'm configuring my live patch, I may not want to save it either.
I realize it may not make it to the top of the bug list, but I figured I should bring it up, since it doesn't seem to work as one would expect.
Thanks again for all of your work!
Brady
On Sun, Dec 17, 2017 at 3:56 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 12/17/2017 06:40 PM, Brady Sharp wrote:
[...]
this is kind of known (at least to me :-)). my workaround for live coding sessions is simply to hit Ctrl-S (save the patch), which will force a recompilation of the DSP graph as well. that workaround is so simple and effective, that i didn't really bother to find a real solution for the problem.
I'd rather not force a toggle of DSP or a saving of a canvas to get
around
this, as that will have other ramifications for the rest of my sprawling live patch.
now, if this were true then you are in serious trouble. turning the DSP on (and to turn it "on", you might have to turn it "off" first) will recalculate the DSP graph. you might want to avoid that, but then you shouldn't do any patching, as putting in a new DSP object might trigger the very same (unless of course you are hitting a bug like the one you were initially describing)
magf IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On 2017-12-18 00:45, Brady Sharp wrote:
I'd rather not toggle DSP, since I could be in the midst of recording a long loop or something
but you already do (by whatever you do to make Pd aware of new signal processing objects). or am i missing something ( i *might* be).
fgasdmr IOhannes
Using the dynamically-created solution in my example let's everything work as it should. That abstraction passes audio right after creation, without having to toggle DSP, or save, or anything else.
I think it would be an improvement for a basic routing abstraction to work as it should, and not have someone learn dynamic patching to get around it, which is why I brought it up, but I'm personally fine with my workaround.
Thanks again!
Brady
On Mon, Dec 18, 2017 at 3:46 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-12-18 00:45, Brady Sharp wrote:
I'd rather not toggle DSP, since I could be in the midst of recording a long loop or something
but you already do (by whatever you do to make Pd aware of new signal processing objects). or am i missing something ( i *might* be).
fgasdmr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On 18 Dec 2017, at 14:33, Brady Sharp bradysharp@gmail.com wrote:
Using the dynamically-created solution in my example let's everything work as it should. That abstraction passes audio right after creation, without having to toggle DSP, or save, or anything else.
the point that johannes makes is, that you are toggling the dsp by creating new objects.
I think it would be an improvement for a basic routing abstraction to work as it should, and not have someone learn dynamic patching to get around it, which is why I brought it up, but I'm personally fine with my workaround.
Thanks again!
Brady
On Mon, Dec 18, 2017 at 3:46 AM, IOhannes m zmoelnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> wrote: On 2017-12-18 00:45, Brady Sharp wrote:
I'd rather not toggle DSP, since I could be in the midst of recording a long loop or something
but you already do (by whatever you do to make Pd aware of new signal processing objects). or am i missing something ( i *might* be).
fgasdmr IOhannes
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
-- Brady Sharp bradysharp@gmail.com mailto:bradysharp@gmail.com bradysharp.com http://bradysharp.com/ http://www.linkedin.com/in/bradysharp _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Oh, OK! Understood. Thanks for clarifying.
Brady
On Mon, Dec 18, 2017, 2:30 PM Simon Iten itensimon@gmail.com wrote:
On 18 Dec 2017, at 14:33, Brady Sharp bradysharp@gmail.com wrote:
Using the dynamically-created solution in my example let's everything work as it should. That abstraction passes audio right after creation, without having to toggle DSP, or save, or anything else.
the point that johannes makes is, that you are toggling the dsp by creating new objects.
I think it would be an improvement for a basic routing abstraction to work as it should, and not have someone learn dynamic patching to get around it, which is why I brought it up, but I'm personally fine with my workaround.
Thanks again!
Brady
On Mon, Dec 18, 2017 at 3:46 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-12-18 00:45, Brady Sharp wrote:
I'd rather not toggle DSP, since I could be in the midst of recording a long loop or something
but you already do (by whatever you do to make Pd aware of new signal processing objects). or am i missing something ( i *might* be).
fgasdmr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-- Brady Sharp bradysharp@gmail.com bradysharp.com http://www.linkedin.com/in/bradysharp _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Brady Sharp -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Simon Iten