[PD] a multislider GUI as abstraction

Raphaël Ilias phae.ilias at gmail.com
Sun Jun 26 17:07:10 CEST 2016


2016-06-24 22:38 GMT+02:00 Roman Haefeli <reduzent at gmail.com>:

> Hey Raphaël
>
>
Hello Roman,

and first : thanks a lot for feedback !


> 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.
>
> Yes, I would be happy to contribute to such effort in pd. I found some
other people working in this perspective of advanced
abstraction-style-GUIs, especially I remember mmb's work for a "range"
(2-points) slider, I don't know its author and if he/she reads the pd-list
?
I'd be glad to participate in a collective effort to standardize and
distribute a collection of these as library, why not ?



> I do have some remarks. Some more steps were necessary for making it
> work than mentioned in the instructions.
>
> * [iem_event] doesn't create, even after installing iemgui. Probably
> you forgot to convert them to [library/objectclass] format.
>
>
yes I had trouble with that. Indeed, in the version i provided, [iem_event]
is created with the message [obj x y iem_event arguments arguments
arguments... ( so without the [library/objectclass] format - as you can see
in the subpatch [pd createVisualInterface] (in "initalize" section) and
then [pd create_iem_event]

But when I try to use [library/objectclass] format, I get this error
message on instantiation :

> iemgui/iem_event: already loaded

many of them, i suppose a thousand of this error because it ends with the
following :

> maximum object loading depth 1000 reached
>  iemgui/iem_event 147 83 0 0 2321-event_s 2321-event_r
> ... couldn't create

Don't know what this means exactly, probably my mistake, I should try to
reproduce this in a simpler patch.
However since I put [declare -stdpath extra/iemgui], [iem_event] (without
libraryname/ in object's name) does create for me. And without [declare] it
created also but not on first opening... only after a moment it seemed to
find the library... I didn't try to reproduce this, but again I'm confused
with all the way of loading libraries.



> * In addition to your library list, I also had to install mmb, which is
> not yet available through Deken.
>

Oh, yes, this is a not finished part of it. At one time I found that I
needed it, I think to handle $0-named receive, that can be saved as
arguments, but I still need to dig in this part again.


>
> * I had to re-install zexy, since I was using the vanilla zexy compiled
> as multi-object-single-file library. ph_msl currently works only with
> zexy from extended that has each object in its own file.
>

Ah I'm not very aware of these different "flavors" of zexy, or don't really
understand this multiple-flavor concept


>
> * I believe it would have been easier to [declare] all the libraries
> 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].
>

yes again, I am not very comfortable with the proper use of libraries, the
"good practices" even if I try to follow the debates about it on the list,
and reading [declare]'s help file didn't made me all clear...
I was thinking that this way, the missing object would display the name of
library from where they come in the "...couldn't create" error message.
Also, I realized that the [prepend] objectname actually exists in two
libraries, cyclone and iemlib... So I wondered what would happen if pd has
to decide which library use to create the object, and found that could be a
real problem if both homonym objects have very different function, or
usage, inlets/outlets, etc...

However, I might need a better understanding of [declare] because as said
above it helped with [iemgui] for dealing with the issue of [iem_event]
dynamic creation...
If this is standard solution and actually the best way to make this
abstraction easier to share, I'd be glad to rewrite everything and remove
library in [objectsname] and [declare all the libraries]


>
> * Many external classes your patch uses can be easily implemented with
> 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)
>
>
Yes I agree, and I know some of this tricks. However, it is sometimes
faster to use this precisely-named utilities because it's shorter to write
their name and easier read later. For example, I love [iemlib/once]. It's
very easy to write, and much easier to read than the few vanilla objects
that you would need to perform the same operation. I sometimes feel that
pd's standard vocabulary is a bit too short... even if I understand that
limiting the number of objects makes a less messy development and backward
compatibility.
But yes, I will consider these vanilla solutions to reduce the number of
dependencies...

In the same idea, I have a few standard functions I use in [ph_msl] like
rgb2int / int2rgb that convert 3 values for red/green/blue to the iemGUIs
1-float color format (that is cool, but way more difficult to "read") and
vice versa. I have both abstractions of mine to perform these conversions,
but I found that it would make it more complex to share if I have to
provide 10 personal abstractions with it, maybe.
Speaking about this, I wondered what is better in performance between
copies of pd-patch vs. multiple instances of an abstraction with exactly
the same content. I put aside here the facts that pd-subpatch cannot have
it's own arguments (but inherits the ones of parent patch) and that
multiple copies of a same pd-subpatch will result in a larger size of the
pd file on the harddisk.



> * After changing the overall size, the all sliders are at maximum and
> can't be visibly moved anymore. However, correct values are still
> output.
>

Yes, moreover when changing size with properties you have to click
"reDraw!" bang button, which don't have to do with message-method [size x y
(. I have same issue on my system, but "minimizing" then "restore" the
window will fully refresh the graphics to correct display, at least it does
on my setup mac OS X + pd-046-7 and it did on my previous setup with
Windows Vista. I don't know what is the origin of this annoying behavior,
but for now I decided it's still ok like that...

Thanks, and sorry for the long answer, but since I spent a lot of time
working on this abstraction, I hope that I could improve it, and optimize
it's compatibility for sharing ...despite it relies on many dirty
hack/tricks and is dependent to many other libraries (whose authors I thank
for their work).

best regards,

Raphaël



> 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 at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis
> > tinfo/pd-list
>
> _______________________________________________
> 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/20160626/b665555d/attachment-0001.html>


More information about the Pd-list mailing list