Re: [PD] PD] Zen Garden re-implementing the wheel in C++?
On 2010-04-19 18:56, Vilson Vieira wrote: > Guys, > > and how about PD-anywhere? How ZenGarden is influenced by? Isn't them so > similar? no, the only similarity between the 2 is, that both run on computers (you could say "smallish computers", but compared to computers some years ago, there is not so much difference in size between a sharp zaurus, an eee pc and a an I Phone. Pd-anywhere is a Pd-port to arm-architectures (fixed point maths), whereas the I Phone has an FPU built in. so the original version of RjDj (aka Pd-on-I-Phone) only needed slight modifications, in order to interface with the OS. Pd-A had to do more modding, as it had to re-implement a lot of ugens, to fixed-pointify them. ZenGarden is a new implementation of the "Pd language" (which is a bit hard to do, as the language is nowhere defined) all this is only guess work, as i am not part of these projects. fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD] Zen Garden re-implementing the wheel in C++?
Guys,
and how about PD-anywhere? How ZenGarden is influenced by? Isn't them so
similar?
Thanks.
2010/4/18 Frank Barknecht
> On Sat, Apr 17, 2010 at 04:12:51PM +0200, Matteo Sisti Sette wrote:
> > I don't think it is more ambiguous than the order of execution of this:
> >
> > [adc~]
> > |
> > [dac~]
> >
> > Either (a) adc-dac or (b) dac-adc.
>
> In Pd it's always (a) because patch cords define the execution order for
> signals. There's no ambiguity, but you cannot do loops this way ("DSP
> loop detected").
>
> > Indeed loops by direct wiring are not allowed in Pd.
> > But to my surprise I find out that loops using send~ and receive~ are.
> > So does a send~-receive~ pair always implicitly have a one-block
> latency???
>
> Not always, but always when you do a loop. When you don't do a loop, you
> can order them so they have zero latency using patchcords/subpatches.
>
> > So my question is which of these is true:
> > A) there is always a one-block latency between a s~ and a corresponding
> r~
>
> No.
>
> > B) there _can_ be a latency, depending on the execution order Pd
> > choses, and you can't know whether there will or won't be.
>
> Yes, there can be a latency, but you can make sure there is none by
> sorting manually using subpatches/patchcords, or you can make sure Pd
> introduces latency by doing a DSP loop. If you try both at the same
> time, you get an error message - the famous "DSP loop detected".
>
> > C) there _can_ be a latency, but if there is no dsp loop on the
> > graph, then you can be sure there won't be any avoidable latency due
> > to execution order.
>
> I'm not sure I understand this sentence, but if you don't have loops,
> you can avoid latency between s~/r~, yes, by sorting.
>
> > Does anybody know the answer?
>
> http://crca.ucsd.edu/~msp/techniques/latest/book-html/node120.htmland
> following.
>
> Ciao
> --
> Frank
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
--
Vilson Vieira
vil...@void.cc
((( http://automata.cc )))
((( http://musa.cc )))
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD] Zen Garden re-implementing the wheel in C++?
On Sat, Apr 17, 2010 at 04:12:51PM +0200, Matteo Sisti Sette wrote:
> I don't think it is more ambiguous than the order of execution of this:
>
> [adc~]
> |
> [dac~]
>
> Either (a) adc-dac or (b) dac-adc.
In Pd it's always (a) because patch cords define the execution order for
signals. There's no ambiguity, but you cannot do loops this way ("DSP
loop detected").
> Indeed loops by direct wiring are not allowed in Pd.
> But to my surprise I find out that loops using send~ and receive~ are.
> So does a send~-receive~ pair always implicitly have a one-block latency???
Not always, but always when you do a loop. When you don't do a loop, you
can order them so they have zero latency using patchcords/subpatches.
> So my question is which of these is true:
> A) there is always a one-block latency between a s~ and a corresponding r~
No.
> B) there _can_ be a latency, depending on the execution order Pd
> choses, and you can't know whether there will or won't be.
Yes, there can be a latency, but you can make sure there is none by
sorting manually using subpatches/patchcords, or you can make sure Pd
introduces latency by doing a DSP loop. If you try both at the same
time, you get an error message - the famous "DSP loop detected".
> C) there _can_ be a latency, but if there is no dsp loop on the
> graph, then you can be sure there won't be any avoidable latency due
> to execution order.
I'm not sure I understand this sentence, but if you don't have loops,
you can avoid latency between s~/r~, yes, by sorting.
> Does anybody know the answer?
http://crca.ucsd.edu/~msp/techniques/latest/book-html/node120.html and
following.
Ciao
--
Frank
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD] Zen Garden re-implementing the wheel in C++?
> > |adc~| > > | > > |send~ foo| > > > > |receive~ foo| > > | > > |dac~| > > > > it execution order is ambiguous. > > > > either (a) adc-send-receive-dac or > > (b) receive-dac-adc-send. > > the case (b) introduces one sample block of latency between > > send and receive, (a) doesn't introduce any latency. > > I don't think it is more ambiguous than the order of execution of this: > > [adc~] > | > [dac~] > > Either (a) adc-dac or (b) dac-adc. Like in your example, the case (b) > introduces one sample block of latency between adc and dac, the case (a) > doesn't > > ...well, then the case (b) is the wrong one and the case (a) is the > right one!!! now consider a case, when receive~ can changes its bus ... > Please anybody correct me if I am wrong, but I think _unless there are > loops in the graph_ there is _always_ an order that ensures no added > latency, and finding out that order is all what dsp-graph computing is > about!!! I always thought Pd would take care of that perhaps doesn't > it?? no. if you want to ensure the order of execution, to be (a), you have to put each part in subpatch, and connect them with a signal connection. there is a help patch about this, G05.execution.order.pd > A) there is always a one-block latency between a s~ and a corresponding r~ false > B) there _can_ be a latency, depending on the execution order Pd choses, > and you can't know whether there will or won't be. true, but check the help patch > C) there _can_ be a latency, but if there is no dsp loop on the graph, > then you can be sure there won't be any avoidable latency due to > execution order. false -- t...@klingt.org http://tim.klingt.org The most wonderful opportunity which life offers is to be human. Henry Miller ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD] Zen Garden re-implementing the wheel in C++?
> |adc~| > | > |send~ foo| > > |receive~ foo| > | > |dac~| > > it execution order is ambiguous. > > either (a) adc-send-receive-dac or > (b) receive-dac-adc-send. > the case (b) introduces one sample block of latency between > send and receive, (a) doesn't introduce any latency. I don't think it is more ambiguous than the order of execution of this: [adc~] | [dac~] Either (a) adc-dac or (b) dac-adc. Like in your example, the case (b) introduces one sample block of latency between adc and dac, the case (a) doesn't ...well, then the case (b) is the wrong one and the case (a) is the right one!!! Please anybody correct me if I am wrong, but I think _unless there are loops in the graph_ there is _always_ an order that ensures no added latency, and finding out that order is all what dsp-graph computing is about!!! I always thought Pd would take care of that perhaps doesn't it?? However the problem does arise when there are loops. Indeed loops by direct wiring are not allowed in Pd. But to my surprise I find out that loops using send~ and receive~ are. So does a send~-receive~ pair always implicitly have a one-block latency??? This is not only a problem of dynamically changing the dsp graph. Even if the graph is static, the ambiguity of not knowing whether there is or there isn't a one-block latency in a particular connection, or where exactly the necessarily-existing-one-block-latency is in a dsp loop, can be very relevant to the resulting signal. So my question is which of these is true: A) there is always a one-block latency between a s~ and a corresponding r~ B) there _can_ be a latency, depending on the execution order Pd choses, and you can't know whether there will or won't be. C) there _can_ be a latency, but if there is no dsp loop on the graph, then you can be sure there won't be any avoidable latency due to execution order. Does anybody know the answer? thanks m. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD] Zen Garden re-implementing the wheel in C++?
> depending on their implementation, it may be possible to do > click-free changes of the dsp graph, which is the weakest part > of the dsp engine of pd. This recalls me of a possibly unrelated even "bigger" problem: you get audio dropouts even by opening a window (such as a subpatch or abstraction by right click -> open). Why? Is the dsp graph redrawn when opening a window? Is there a reason for doing that? Or is something else the cause for such dropouts (maybe some memory allocation)? But then, shouldn't _anything_ happening when opening a window affect _only_ the gui process? -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
