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).

Have a nice day,

Raphaƫl

2016-06-28 12:33 GMT+02:00 Derek Kwan <derek.x.kwan@gmail.com>:
Hello,

I suppose this response is to no one in particular but I like talking to
Alex so I'll reply to him =).

As per the abstraction vs externals for gui stuff debate, I have a few
general thoughts/observations:

At least in my personal experience, I haven't had much luck with GUI
abstractions. It seems like a lot of them that I at least have
investigate date back to the pd-extended era of things and thus rely a
lot of all the libraries provided with pd-extended, which loaded all the
libaries as a default so they didn't have follow an
libraryname/objectname convention of declaration. So I have to find out
all the library dependencies and get them on my computer and if I don't
want to automatically load all the libraries at start, I have to dig
through and try to find where all these objects are within the
subpatches of subpatches of abstractions to where these objects are and
add the libraryname/ (or I suppose I could do a [declare -lib
libraryname] too, I suppose that makes more sense). At least to me, not
just externals but abstractions suffer from maintenance issues as well.
At least with externals, compilation lends itself to more of a
standalone mindset without this pure data library dependency hell
(although of course externals upon compilation can suffer from this as
well). Perhaps this is a historical issue though and now that
PD-extended is being phased out, this situation going forward would be
less of an issue.

Also, perhaps it is just my own failing as a PD programmer, but I've
never felt entirely comfortable with multiplicity in a graphical
programming language. Like say, I want a 100x120 grid of toggle boxes
that fits within a 640x480 rectangle and all their backgrounds are black
and their Xs are yellow and each toggle box is hot so when you select
one, it dumps out a list of all the values. Plus, every 500 ms I want
the backgrounds of all the toggle boxes to flash blue so it's a clear
visual cue that's where a downbeat is. It feels like in this case, I'm
going to be making a lot of objects and connecting a lot of cords or do
a clickable canvas or use structs (I think there was an abstraction that
did this?) or something like that. At least for me, it feels way more
natural to use a text-based language vs a graphic-based language to do a
whole lot of one particular thing and keep track of it all and thus I'd
lean more towards external vs abstraction. Plus with an external you get
more flexibility with what you can do rather than be limited to using
Pure Data objects to try to achieve your goals, although I can see that
perhaps in a lot of cases this flexibility is not needed.

I don't know, I'm sort of rambling and losing my train of thought here
lol. I'm glad this topic is being brought up though, it's making me
reconsider abstractions and costs and benefits or doing abstractions vs
externals. Maybe I just need to familiarize myself more with things you
can do with canvases and how to do iteration in Pure Data =).

Derek

=====================
Derek Kwan
www.derekxkwan.com

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list