2016-06-24 22:38 GMT+02:00 Roman Haefeli <reduzent@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@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis
> tinfo/pd-list

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list