Hi all,
Well, first of all, I don't think incorporating the GUI objects from IEMLIB will make Pd any harder to extricate from tk if that ever has to be done. It can always be fixed so that when you import a Pd patch into some newer, leaner Pd, all those controls just revert to number boxes, or to some much simpler, less versatile GUI objects that anyone could write quickly...
My own question is how to prevent confusion when all the controls can have "send" and "receive" connections that you don't know about until you open the dialog. Someone could get in serious trouble copying and pasting sliders and wondering why they all seem to jump at once...! Also I'm baffled how to deal with dollar signs in send and receive names for GUIs.
I'm not too worried about efficiency problems since in any case you have to limit the number of graphical controls you have visible if you want your patch to run well. Someday I want to implement a kind of flow control to ease this situation, but then you'll just see the interface react slower and slower as you add creamy GUI objects to your patch.
No, I don't think color is CPU-expensive... it's probably all those labels on the VU meters that are the real killers (the more stuff you have on the screen the more things TK has to check if it needs redrawing when sonething changes).
Anyway, I have many more thoughts than that, but I'm focussing on getting ready for ICMC right now... :)
cheers Miller
On Tue, Sep 11, 2001 at 05:37:30PM -0400, Michal Seta wrote:
Frank Barknecht wrote:
I like gripd, that was not what I meant. But gripd IMO fills another niche: it allows one to build "performance patches" like in Reaktor, where only the important things are visible.
In my opinion this is what the gui is supposed to be for :)
I like those GUI thingies in PD because they help me build patches and keep them clean.
A simple example is [tgl]. Without [tgl] I need one [1( and one [0( to control a [metro] and I don't see at one glance if the [metro] is on or off. With one [tgl] instead I do.
Also colors in PD patches help me finding my way.
I agree...
I admit that I was just thinking of the iemlib vs gripd issue... If you remember I reported a problem using gripd. So, as I was somewhat desperate, I built my gui with iemlib. The whole thing. I'm rebuilding it with GriPD as well but I'm not in a hurry anymore... since I'm planning, perhaps, releasing the thing to the public at some point I thought that GriPD will be "cuter" ....
However, iemlib is great for quick things. More like testing/prototyping. I would probably not use gripd early on during patch development. But then, it's possible in any case....
And I think I would rather see more features added to gripd (and I'm sure more of such gadgets will pop up) than iemlib. But we should not underestimate the usefulness of iemlib. And then the proper credit should be given :)
mine 0.02
./MiS