[PD] Control-rate computations in the Signal domain (was Re: Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?)
muranyia at gmail.com
Mon Apr 19 19:17:51 CEST 2010
On Sun, Apr 18, 2010 at 2:47 PM, Frank Barknecht <fbar at footils.org> wrote:
> On Sun, Apr 18, 2010 at 01:07:21PM +0200, Matteo Sisti Sette wrote:
> > Frank Barknecht escribió:
> > > *If* order matters to you (it may not always do) you can still use
> > >the subpatch approach with dummy inlet~/outlet~ objects.
> > That's the part I don't understand. I mean I can't figure out the
> > trick. I can easily imagine (and actually tried) how to patch things
> > to force the desired order, but then again, I see myself obliged to
> > do the wired connections that the [s~]/[r~]s were meant to avoid.
> > May you please make an example of the technique? I would be so grateful.
> Attached is a very stupid example, which should show what I mean: Here
> various abstractions are layed out in a way, that they execute in order.
> Only one connection is used for order forcing, but still many s~/r~ are
> active, all properly ordered.
> Real life examples may not be so easy to sort, of course.
> > >And don't forget the other application of s~/r~ where you actually
> > >*want* to have a delay of one block: feedback algorithms.
> > Yeah but in that case I would rather use a [delread~]/[delwrite~] pair,
> Well, you could, but s~/r~ is much easier to use. Also
> delread~/delwrite~ with a delay set to 0 won't have a delay of 0 in
> feedback situations, so it may even be more confusing.
> > Wow that sounds very interesting. I hope you will publish the paper
> > on the internet so we can have a look
> It will be in the LAC proceedings available on lac.linuxaudio.org soon.
I'll keep checking but it would be real nice if you could post it here when
I hear some of my friends using this technique rather successfully...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list