2016-06-24 22:38 GMT+02:00 Roman Haefeli <[email protected]>: > 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 > > _______________________________________________ > > [email protected] mailing list > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis > > tinfo/pd-list > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
