<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-06-24 22:38 GMT+02:00 Roman Haefeli <span dir="ltr"><<a href="mailto:reduzent@gmail.com" target="_blank">reduzent@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Raphaël<br>
<br></blockquote><div><br></div><div>Hello Roman,<br><br></div><div>and first : thanks a lot for feedback !<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Impressive work. I'm all for more advanced GUIs. I even like them being<br>
abstractions as opposed to compiled externals. I'm not so concerned<br>
about performance, since the GUI runs in a separate thread. I believe<br>
it's rather GUIs like arrays that may cause hiccups when they send much<br>
data in short time.<br>
<br></blockquote><div>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 ? <br></div><div>I'd be glad to participate in a collective effort to standardize and distribute a collection of these as library, why not ?<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I do have some remarks. Some more steps were necessary for making it<br>
work than mentioned in the instructions.<br>
<br>
* [iem_event] doesn't create, even after installing iemgui. Probably<br>
you forgot to convert them to [library/objectclass] format.<br>
<br></blockquote><div><br></div><div>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 <span style="font-family:arial,helvetica,sans-serif">[library/objectclass] format - as you can see in the subpatch [pd createVisualInterface] (in "initalize" section) and then [pd create_iem_event]<br></span></div><div><span style="font-family:arial,helvetica,sans-serif"><br>But when I try to use [library/objectclass] format, I get this error message </span><span style="font-family:arial,helvetica,sans-serif"><span style="font-family:arial,helvetica,sans-serif">on instantiation </span>:<br><br>> iemgui/iem_event: already loaded<br></span></div><div><span style="font-family:arial,helvetica,sans-serif"><br>many of them, i suppose a thousand of this error because it ends with the following :<br><br>> maximum object loading depth 1000 reached<br>> iemgui/iem_event 147 83 0 0 2321-event_s 2321-event_r<br>> ... couldn't create<br></span></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="font-family:arial,helvetica,sans-serif">Don't know what this means exactly, probably my mistake, I should try to reproduce this in a simpler patch.<br>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.<br></span></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* In addition to your library list, I also had to install mmb, which is<br>
not yet available through Deken.<br></blockquote><div><br></div><div>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. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* I had to re-install zexy, since I was using the vanilla zexy compiled<br>
as multi-object-single-file library. ph_msl currently works only with<br>
zexy from extended that has each object in its own file.<br></blockquote><div><br></div><div>Ah I'm not very aware of these different "flavors" of zexy, or don't really understand this multiple-flavor concept<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* I believe it would have been easier to [declare] all the libraries<br>
instead of converting everything to [library/objectclass]. As a side<br>
effect, this also means all dependencies are documented. Also, by using<br>
[declare] you could make it work with any flavor of zexy, like [declare<br>
-stdlib zexy -stdpath zexy].<br></blockquote><div><br></div><div>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...<br></div><div>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.<br></div><div>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...<br><br></div><div>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...<br></div><div>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]<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* Many external classes your patch uses can be easily implemented with<br>
vanilla-only objects. For instance:<br>
[zexy/makesymbol %s%s] -> [symbol $1$2(<br>
[cycle/tosymbol] -> [makefilename %d] <br>
[zexy/multiplex] -> [list prepend]\[nbx\<br>
[zexy/demultiplex] -> [route 0 1 2 3 4]<br>
[moonlib/char2f] -> [list fromsymbol]<br>
[moonlib/f2char] -> [list tosymbol]<br>
(the list might be not complete)<br>
<br></blockquote><div><br></div><div>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, <span style="font-family:arial,helvetica,sans-serif">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.<br></span></div><div><span style="font-family:arial,helvetica,sans-serif">But yes, I will consider these vanilla solutions to reduce the number of dependencies...<br></span></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="font-family:arial,helvetica,sans-serif">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. <br></span></div><div><span style="font-family:arial,helvetica,sans-serif">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 t</span><span style="font-family:arial,helvetica,sans-serif">hat 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. </span></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* After changing the overall size, the all sliders are at maximum and<br>
can't be visibly moved anymore. However, correct values are still<br>
output.<br></blockquote><div><br></div><div>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...<br></div><div> <br><div>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).<br></div><div><br></div><div>best regards,<br></div><div><br></div><div>Raphaël<br></div><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><font color="#888888"><br>
Roman<br>
</font></span><div class=""><div class="h5"><br>
<br>
<br>
<br>
On Fri, 2016-06-24 at 21:22 +0200, Raphaël Ilias wrote:<br>
> Hello list,<br>
><br>
> I dare to share this abstraction named [ph_msl] because, I find it<br>
> quite handy even though made of many mouse/dynamic-patching tricks<br>
> that many pd users may find very inelegant and heavy.<br>
><br>
> However, this - if you manage to make it fully work* - is an attempt<br>
> to have this multi-slider GUI that I miss so much...<br>
> So it's a multi-slider GUI which visual & interface properties can be<br>
> saved with parent patch and modified in a windows when right-clicking<br>
> > Properties (like other vanilla guis).<br>
> ...and other features that I wanted : shift-clicking for smaller<br>
> step, relative/jump mode like [hsl] or [vsl], histogram style bars...<br>
><br>
> I often feel that pd lacks a good GUI that can be modified as an<br>
> abstraction, whose graphic properties can be changed, but also mouse<br>
> interaction can be redesigned, etc...<br>
> I think that while you can easily "abstract" a DSP/audio or data<br>
> processing (like the "list-abs" set), the process of creating a good<br>
> GUI is a very "manual" process (like right-click properties every<br>
> element, etc) and is limited to few GUI objects that are strong but<br>
> have their limits inside the "not-puredata-code" (in C or tcl/tk)<br>
> that make them black boxes. So that is an attempt to answer these<br>
> issues...<br>
><br>
> I love pd, but I miss some GUIs, like a good break-points curve<br>
> editing (i am aware about [envgen] but it's buggy inside graph-on-<br>
> parent), for envelopes or dynamic compressor ...<br>
> Maybe the ability to develop GUIs in "pd language itself" would make<br>
> them more customizable for the users, without having to learn C (at<br>
> least, for me, I don't want to learn C).<br>
><br>
> Maybe hackish-abstraction-GUI are too messy and not good in<br>
> performance... maybe it would still be easier and more efficient to<br>
> have "compiled" GUI... I don't know but wanted to share my<br>
> experiments, and see if some have answers or ideas...<br>
><br>
> Besides the debate I wish to have about GUI and pd, I hope you'll<br>
> enjoy this [ph_msl] or have any remarks about it... It's packed in a<br>
> zip file, and you should open "ph_msl-help.pd" first.<br>
><br>
> * this abstraction was made at first with pd-Extended, but I tried to<br>
> make it compatible with the vanilla+deken setup I use now and the<br>
> standard external call as [library/object].<br>
> It needs the following external libraries : cyclone, hcs, iemlib,<br>
> iemgui, iemguts, list-abs, moonlib, purepd, zexy<br>
><br>
> best regards,<br>
><br>
> Raphaël<br>
</div></div><div class=""><div class="h5">> _______________________________________________<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/lis" rel="noreferrer" target="_blank">https://lists.puredata.info/lis</a><br>
> tinfo/pd-list</div></div><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>
<br></blockquote></div><br></div></div>