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.k...@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 >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list