Hey Raphaël
Impressive work. I'm all for more advanced GUIs. I even like them being abstractions as opposed to compiled externals. I'm not so concerned about performance, since the GUI runs in a separate thread. I believe it's rather GUIs like arrays that may cause hiccups when they send much data in short time.
I do have some remarks. Some more steps were necessary for making it work than mentioned in the instructions.
you forgot to convert them to [library/objectclass] format.
not yet available through Deken.
as multi-object-single-file library. ph_msl currently works only with zexy from extended that has each object in its own file.
instead of converting everything to [library/objectclass]. As a side effect, this also means all dependencies are documented. Also, by using [declare] you could make it work with any flavor of zexy, like [declare -stdlib zexy -stdpath zexy].
vanilla-only objects. For instance:
[zexy/makesymbol %s%s] -> [symbol $1$2(
[cycle/tosymbol] -> [makefilename %d]
[zexy/multiplex] -> [list prepend][nbx
[zexy/demultiplex] -> [route 0 1 2 3 4]
[moonlib/char2f] -> [list fromsymbol]
[moonlib/f2char] -> [list tosymbol]
(the list might be not complete)
can't be visibly moved anymore. However, correct values are still output.
Roman
On Fri, 2016-06-24 at 21:22 +0200, Raphaël Ilias wrote:
Hello list,
I dare to share this abstraction named [ph_msl] because, I find it quite handy even though made of many mouse/dynamic-patching tricks that many pd users may find very inelegant and heavy.
However, this - if you manage to make it fully work* - is an attempt to have this multi-slider GUI that I miss so much... So it's a multi-slider GUI which visual & interface properties can be saved with parent patch and modified in a windows when right-clicking
Properties (like other vanilla guis).
...and other features that I wanted : shift-clicking for smaller step, relative/jump mode like [hsl] or [vsl], histogram style bars...
I often feel that pd lacks a good GUI that can be modified as an abstraction, whose graphic properties can be changed, but also mouse interaction can be redesigned, etc... I think that while you can easily "abstract" a DSP/audio or data processing (like the "list-abs" set), the process of creating a good GUI is a very "manual" process (like right-click properties every element, etc) and is limited to few GUI objects that are strong but have their limits inside the "not-puredata-code" (in C or tcl/tk) that make them black boxes. So that is an attempt to answer these issues...
I love pd, but I miss some GUIs, like a good break-points curve editing (i am aware about [envgen] but it's buggy inside graph-on- parent), for envelopes or dynamic compressor ... Maybe the ability to develop GUIs in "pd language itself" would make them more customizable for the users, without having to learn C (at least, for me, I don't want to learn C).
Maybe hackish-abstraction-GUI are too messy and not good in performance... maybe it would still be easier and more efficient to have "compiled" GUI... I don't know but wanted to share my experiments, and see if some have answers or ideas...
Besides the debate I wish to have about GUI and pd, I hope you'll enjoy this [ph_msl] or have any remarks about it... It's packed in a zip file, and you should open "ph_msl-help.pd" first.
- this abstraction was made at first with pd-Extended, but I tried to
make it compatible with the vanilla+deken setup I use now and the standard external call as [library/object]. It needs the following external libraries : cyclone, hcs, iemlib, iemgui, iemguts, list-abs, moonlib, purepd, zexy
best regards,
Raphaël _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list