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.
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
