[PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

On Fri, 2010-11-26 at 02:44 +0100, András Murányi wrote:
> No, i wouldn't! I just had a vague memory that this behaviour (doing
> all the delayed calculations at once after a freeze) resembles
> -nosleep's behaviour (doing all the delayed calculations at once after
> a system sleep), but i may completely mistaken.

I see. As it turns out I did discover consistency check errors which
have to do with the new way iemgui objects tag their inlets and outlets
to make them highlight-compliant. It seems that GOP-ed objects should
not call glist_findrtext which is triggering this error as a bug (even
though iemgui's new code gracefully falls back to a secondary option).
I've now implemented a pre-check so that we never even call findrtext if
we are an iemgui object drawn as part of GOP.

All this said, I've not encountered any burst-like slowdowns except when
moving tons of objects simultaneously which was even more problematic in
the old iteration due to the amount of socket traffic.

What is really weird is the following:

1) try using any of your complex GOP abstractions and add one to a blank
patch and try to move it around
2) in my case movement is rather choppy (understandably so as GOP even
in l2ork iteration still relies upon coords calls rather than
move-by-tagging)
3) *however*, when one selects and duplicates the same abstraction so
that there are now two of them, suddenly performance is (at least on my
machine--msi wind u100 with atom 1.6GHz procesor) amazingly smooth which
goes against all logic

Anyone else experiencing the same and/or have a logical explanation for
this?

Latest snapshot can be found in the usual place:

http://l2ork.music.vt.edu/main/?page_id=56

Cheers!