<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hello Derek, Roman and others still reading :)<br><br></div>I am really pleased to read your thoughts as they express many issues I have had in mind :<br></div>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.<br><br></div>However, I still think that abstraction GUIs can be a mid-term solution until better external GUIs are provided. <br>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 <font face="arial,helvetica,sans-serif">[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).<br></font></div><font face="arial,helvetica,sans-serif">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... <br>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.<br><br></font></div><font face="arial,helvetica,sans-serif">(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.)<br><br></font></div><font face="arial,helvetica,sans-serif">Yes there could be good GUIs as externals, but this not my project.<br></font></div><div><font face="arial,helvetica,sans-serif">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.<br><br></font></div><font face="arial,helvetica,sans-serif">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).<br></font></div><div><font face="arial,helvetica,sans-serif"><br>In that idea of doing abstractions to share, I still haven't found answers on the "good practices" about reference to other objects : <br></font></div><div><font face="arial,helvetica,sans-serif"><br>> [declare] vs. [libraryname/objectname] ?<br><br></font></div><div><font face="arial,helvetica,sans-serif">> for the specific case of objects that could be implemented in vanilla (such as [cyclone/tosymbol], [zexy/multiplex], [iemlib/once], [iemlib/for++]...), should I :<br></font><br><font face="arial,helvetica,sans-serif"><font face="arial,helvetica,sans-serif">- use these "already existing externals" (more dependencies/libraries to install)</font><br>- or use "more homemade vanilla's abstractions.pd doing the same job" (more files, probably redundant with other externals)<br>- or replace them by "pd the-same-vanilla-solution-but-as-subpatch" (more redundant code, huge files)<br>?<br><br></font></div><div><font face="arial,helvetica,sans-serif">> 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....<br>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 ?<br></font></div><div><font face="arial,helvetica,sans-serif">he he, I know I am bit provocative here....</font></div><div><font face="arial,helvetica,sans-serif"><br></font></div><font face="arial,helvetica,sans-serif">Sorry if I am spamming the list with personal opinions, but I feel the need to confront them to experienced Pd users. <br>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).<br><br></font></div><font face="arial,helvetica,sans-serif">Have a nice day,<br><br></font></div><font face="arial,helvetica,sans-serif">Raphaël<br></font></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-28 12:33 GMT+02:00 Derek Kwan <span dir="ltr"><<a href="mailto:derek.x.kwan@gmail.com" target="_blank">derek.x.kwan@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I suppose this response is to no one in particular but I like talking to<br>
Alex so I'll reply to him =).<br>
<br>
As per the abstraction vs externals for gui stuff debate, I have a few<br>
general thoughts/observations:<br>
<br>
At least in my personal experience, I haven't had much luck with GUI<br>
abstractions. It seems like a lot of them that I at least have<br>
investigate date back to the pd-extended era of things and thus rely a<br>
lot of all the libraries provided with pd-extended, which loaded all the<br>
libaries as a default so they didn't have follow an<br>
libraryname/objectname convention of declaration. So I have to find out<br>
all the library dependencies and get them on my computer and if I don't<br>
want to automatically load all the libraries at start, I have to dig<br>
through and try to find where all these objects are within the<br>
subpatches of subpatches of abstractions to where these objects are and<br>
add the libraryname/ (or I suppose I could do a [declare -lib<br>
libraryname] too, I suppose that makes more sense). At least to me, not<br>
just externals but abstractions suffer from maintenance issues as well.<br>
At least with externals, compilation lends itself to more of a<br>
standalone mindset without this pure data library dependency hell<br>
(although of course externals upon compilation can suffer from this as<br>
well). Perhaps this is a historical issue though and now that<br>
PD-extended is being phased out, this situation going forward would be<br>
less of an issue.<br>
<br>
Also, perhaps it is just my own failing as a PD programmer, but I've<br>
never felt entirely comfortable with multiplicity in a graphical<br>
programming language. Like say, I want a 100x120 grid of toggle boxes<br>
that fits within a 640x480 rectangle and all their backgrounds are black<br>
and their Xs are yellow and each toggle box is hot so when you select<br>
one, it dumps out a list of all the values. Plus, every 500 ms I want<br>
the backgrounds of all the toggle boxes to flash blue so it's a clear<br>
visual cue that's where a downbeat is. It feels like in this case, I'm<br>
going to be making a lot of objects and connecting a lot of cords or do<br>
a clickable canvas or use structs (I think there was an abstraction that<br>
did this?) or something like that. At least for me, it feels way more<br>
natural to use a text-based language vs a graphic-based language to do a<br>
whole lot of one particular thing and keep track of it all and thus I'd<br>
lean more towards external vs abstraction. Plus with an external you get<br>
more flexibility with what you can do rather than be limited to using<br>
Pure Data objects to try to achieve your goals, although I can see that<br>
perhaps in a lot of cases this flexibility is not needed.<br>
<br>
I don't know, I'm sort of rambling and losing my train of thought here<br>
lol. I'm glad this topic is being brought up though, it's making me<br>
reconsider abstractions and costs and benefits or doing abstractions vs<br>
externals. Maybe I just need to familiarize myself more with things you<br>
can do with canvases and how to do iteration in Pure Data =).<br>
<br>
Derek<br>
<br>
=====================<br>
<span class="HOEnZb"><font color="#888888">Derek Kwan<br>
<a href="http://www.derekxkwan.com" rel="noreferrer" target="_blank">www.derekxkwan.com</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div><br></div>