Roman Haefeli a écrit :
> hello cyrille
>
> thank you for the adjustments. i think i understand the difference
> between measuring the gemhead loop and the time between 2 images. but
> the other thing with the optimization still remains unclear to me and it
> seems, that it doesn't work here. wh
hello cyrille
thank you for the adjustments. i think i understand the difference
between measuring the gemhead loop and the time between 2 images. but
the other thing with the optimization still remains unclear to me and it
seems, that it doesn't work here. when i stop the first and start the
seco
i made some change to this abstraction in order to compute only the time use
for the gemhead loop and not the time between 2 images.
on my computer, it's about 11ms.
but with the display list optimisation, it fall to 6ms about.
cyrille
Roman Haefeli a écrit :
as always: i forgot the attachmen
as always: i forgot the attachment
On Wed, 2007-02-28 at 23:24 +0100, Roman Haefeli wrote:
> On Wed, 2007-02-28 at 07:14 -0600, chris clepper wrote:
> > On 2/28/07, Roman Haefeli <[EMAIL PROTECTED]> wrote:
> >
> >
> > i might be wrong but in my eyes it doesn't mak
On Wed, 2007-02-28 at 07:14 -0600, chris clepper wrote:
> On 2/28/07, Roman Haefeli <[EMAIL PROTECTED]> wrote:
>
>
> i might be wrong but in my eyes it doesn't make sense to do
> all the work
> that could be done in 50ms in only 1.45ms.
>
> What? GEM doe
hello cyrille
thank you. [any] was what i was looking for. it can store a gem-pointer.
but as you mentioned it doesn't work when delayed.
putting this in the render chain works and gives the expected result:
[t b b a]
| //
[any ]
but this makes pd/gem completely stuck:
[t b b a]
| |
