[PD] a multislider GUI as abstraction

Raphaël Ilias phae.ilias at gmail.com
Tue Jun 28 15:18:34 CEST 2016


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 at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160628/ea8cb584/attachment.html>


More information about the Pd-list mailing list