Hello Derek, Roman and others still reading :)
I am really pleased to read your thoughts as they express many issues I have had in mind :
Especially what you said about GUIs being probably much easier to implement in a text language than in graphical/dataflow programming language. I have the same impression and my experience with Processing has to do with this opinion.
However, I still think that abstraction GUIs can be a mid-term solution until better external GUIs are provided.
For example, I don't remember where I saw this, but someone (I think mmb) made a "emtpy to filled" slider abstraction, where the value is not showed by a thin cursor like iem's
[vslider] but by a colored bar (just a trick with a dynamically set [cnv]'s visual size over a [vslider] object that deals the mouse interaction).
I think that such a "filled bar" slider can greatly improve the "visual" efficiency of a patch, its usability in a live performance... This might be a very easy feature to add to current [vsl] and [hsl] iemGUIs but, as it would involve learning a new programming language, I don't want to do it myself...
So, at least to me, it's worth to answer this need by finding a solution that may be not-very-elegant but still functional : GUI abstraction.
(Same with the solution of using an [array] as a multislider that Ivica mentioned : it's ok, it's functional, it's vanilla so it's "pure" puredata. It's not ugly but it's really an 90ies GUI, and it's way below optimization of a screen+mouse interactive control compared to what any desktop computer can offer today.)
Yes there could be good GUIs as externals, but this not my project.
They could be data-structures but I think it's a bit a closed system (and limited visually, in terms of colors or shape, at least a few years ago last time I tried datastructures), and I'm personnally not very fond of the way to program them.
So what I imagine is extending features over existing GUI, using dynamic patching / user/mouse/keyboard event tracking / state-saving through arguments techniques in abstractions. I think this could help sketching new methods to think for GUIs (graphical / interactive / modulable / state-saved objects) as something that can be programmed *in* Pd as abstraction... and so would have the ability to be developed by users as they do with audio when they program a polyphonic Synthetizer or a wave-shaper, which are perfectible but also have multiple designs that can be interesting to investigate as Pd's abstraction. Maybe this new methods could lead to develop new good-stable-efficient-external objects to support them (like [clone] that might be historically sort of a formalization of dynamic-patching).
In that idea of doing abstractions to share, I still haven't found answers on the "good practices" about reference to other objects :
> [declare] vs. [libraryname/objectname] ?
> for the specific case of objects that could be implemented in vanilla (such as [cyclone/tosymbol], [zexy/multiplex], [iemlib/once], [iemlib/for++]...), should I :
- use these "already existing externals" (more dependencies/libraries to install)
- or use "more homemade vanilla's abstractions.pd doing the same job" (more files, probably redundant with other externals)
- or replace them by "pd the-same-vanilla-solution-but-as-subpatch" (more redundant code, huge files)
?
> why some objects like [hcs/colorpanel] couldn't be added to vanilla, since it will unlikely be done as well with an abstraction ? As long as I can remember it's calling OS-specific GUI like [openpanel] and [savepanel] and I think I saw it work on Linux, MacOSX & Windows....
Or will it remain an external (I'm ok with that), so people can't complain about shared patches/abstractions because they have "too many dependencies" ? Would this be a "dev only" mailing-list, and "regular pd users" should go to pd forum to share their noobs' messy patch, stuck they are in the Pd-Extended collapse ?
he he, I know I am bit provocative here....
Sorry if I am spamming the list with personal opinions, but I feel the need to confront them to experienced Pd users.
By the way, I am not regretting Pd-Extended era, I know there are good reasons to clean the Puredata environment and make it modular, and I think that deken is a wonderful improvement (this way to set up new libraries is I think part of what made arduino/processing IDE a success).