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

[João Pais]

> This is that kind of thinking that led me to invent [#many]. I looked at
> their matrix of toggle-like things and told myself I should make  
> something
> similar, except it would have a much shorter list of properties, and a
> possibility to connect plugins (using an extra inlet and outlet) so that
> any special behaviour can be user-specified. And then I wanted a variable
> element-class, not just toggle. And thus it was born.
>
> Apart from that, many things can be made using [#see]-[#mouse] with
> various graphics processing in GF/GEM/PDP. [#see] displays a video in a
> patch, and the video can be tiny, generated, and rendered on demand (it's
> actually a picture viewer). This is most useful for high-color,
> pixel-oriented data, or really complicated vector data, perhaps.

that's also true, but in this case I was speaking more about small user  
issues. Pd people (me as well) got used to the "clean" look of the  
patches, but sometimes this lack of options also means to waste lots of  
time when a decent gui has to be made. Clean guis should be the result of  
the programmer's choices, not of the limitations of the program.

I had a small look at [#many]. Do you think it would be better to use  
C-coded objects instead for this kind of "complex" gop abstractions? I use  
lots of abstractions with gop (from my library, specially [m-i] for midi  
input), and it seems to me that at some point I have so many abstractions,  
that my patches take longer to load. But I didn't do a real test to prove  
this.