Marius Schebella wrote:

what you should do, to get the loop working is to add a [delay] before frame 0 is triggered. I don't know if it should be a [delay 0] or a [delay 40]

Thanks Marius, it works now!

Anyway if i put [delay 2000] it doesn't work, do you know why?

Another question: [delay 0] is not the same as don't put anything?

GARFF

Date: Thu, 25 Oct 2007 22:23:43 -0400 From: marius.schebella@gmail.com To: tirengarfio@hotmail.com CC: pd-list@iem.at Subject: Re: [PD] Can you help me with this patch?

what you do in your patch, is trigger pdp_qt~ with a zero before the object has finished it's output. what you should do, to get the loop working is to add a [delay] before frame 0 is triggered. I don't know if it should be a [delay 0] or a [delay 40]. the delay could be related to the framerate and maybe the last frame needs 1/25 s to play before the movie can be looped. just try and see if this works better. marius.

Javier Garcia wrote:

...

Hi,

take a look at the patch i have made

I think it should restart the movie when it finishes, but no..

I know i could use [loop< but im trying this...

br. GARFF

---

Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

---

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Hallo, hard off hat gesagt: // hard off wrote:

i think it will delay until the next block.

Not quite: "delay 0" will do exactly as it tells you: It will delay zero milliseconds with is much less than one block: It's zero blocks.

However "delay 0" compared to a direct connection will defer execution for a logical step.

Say you have a "t b b" and a "delay 0" connected to the right outlet, plus a "print left" and "print right" below these (sorry, can't type brackets here so no ASCII). Then even when the right outlet of "t b b" fires first, the "delay 0" will defer its bang, so that still the "left" gets printed before the "right". Both get printed in the same block, though, and at the same time.

Ciao

Frank Barknecht _ ______footils.org__

Hallo, Steffen Juul hat gesagt: // Steffen Juul wrote:

On 26/10/2007, at 15.00, Frank Barknecht wrote:

...

However "delay 0" compared to a direct connection will defer execution for a logical step.

Say you have a "t b b" and a "delay 0" connected to the right outlet, plus a "print left" and "print right" below these (sorry, can't type brackets here so no ASCII). Then even when the right outlet of "t b b" fires first, the "delay 0" will defer its bang, so that still the "left" gets printed before the "right". Both get printed in the same block, though, and at the same time.

Say what... what happened to "depth first"? - What am i missing?

You're missing nothing: "delay 0" is used to *deliberatly* "break" depth first for the tree following it and kind of convert it to "this depth last". Sometimes this can be useful.

Ciao

Frank Barknecht _ ______footils.org__

Hallo, Steffen Juul hat gesagt: // Steffen Juul wrote:

...

Sometimes this can be useful.

Ok. There is no use case that pops to mind. Got one? I think that if
i had the need, i'd (re-)order it [t]'er-wise. To be a little risky
and "fresh"; I think using [delay 0] like that is "spaghetti coding".

One use is the to avoid suicides. Using [delay 0] (ah, brackets again) was used to work around a crash when closing the gemwin from gemkeyboard. Another suidice is attached.

Then if you have long-running [until]s that generate stack-overflows, you can work around this by dividing long computations into smaaller chunks with some [delay]s as well. Of course working around stack overflows this way can be even more dangerous, as is illustrated with the [pipe] example in attachement as well. [pipe] also act as an endpoint to depth first travesal just like [delay].

Ciao

Frank Barknecht _ ______footils.org__

On Fri, 26 Oct 2007, Frank Barknecht wrote:

Then if you have long-running [until]s that generate stack-overflows, you can work around this by dividing long computations into smaaller chunks with some [delay]s as well. Of course working around stack overflows this way can be even more dangerous, as is illustrated with the [pipe] example in attachement as well. [pipe] also act as an endpoint to depth first travesal just like [delay].

Actually, [delay] and such are doing breadth-first traversal. By putting one or a few [delay]s you get a breadth-first traversal of depth-first components, and if you insert a [delay] in every connection you have a purely breadth-first system.

depth-first is based on a stack. breadth-first is based on a queue.

I say just that as a different way to explain the concept. It also answers questions like "if an execution pattern is not depth-first then else can it be?" even though such a question would only be asked by impertinent students who deserves the leather strap.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada