Re: [PD] "waking up" an audio patchbay abstraction upon live creation.

[Brady Sharp]

Oh, OK!  Understood. Thanks for clarifying.

Brady

On Mon, Dec 18, 2017, 2:30 PM Simon Iten  wrote:

> On 18 Dec 2017, at 14:33, Brady Sharp  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 
> 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
> bradysh...@gmail.com
> bradysharp.com 
> ___
> 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

Re: [PD] "waking up" an audio patchbay abstraction upon live creation.

[Simon Iten]

> On 18 Dec 2017, at 14:33, Brady Sharp  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  > 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
> bradysh...@gmail.com 
> bradysharp.com  
> 
> ___
> 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

Re: [PD] "waking up" an audio patchbay abstraction upon live creation.

[Brady Sharp]

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 
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
bradysh...@gmail.com
bradysharp.com 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] "waking up" an audio patchbay abstraction upon live creation.

[IOhannes m zmoelnig]

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



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] "waking up" an audio patchbay abstraction upon live creation.

[Brady Sharp]

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  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
>
>


-- 
Brady Sharp
bradysh...@gmail.com
bradysharp.com 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] "waking up" an audio patchbay abstraction upon live creation.

[IOhannes m zmölnig]

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



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] "waking up" an audio patchbay abstraction upon live creation.

[Brady Sharp]

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!

-- 
Brady Sharp
bradysh...@gmail.com
bradysharp.com 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list