2016-06-24 22:16 GMT+02:00 Fred Jan Kraan fjkraan@xs4all.nl:

Hi Raphaël,

...

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 ...

Just today I completed a first reissue of the tof library containing [breakpoints], a derivate of [ggee/envgen] for deken. I found it unstable in edit mode, but not yet in a GOP. Can you describe the buggyness of [envgen]? I could try to do something about it.

...

Sorry Fred, I remembered that when inside a gop abstraction, the displayed curve of [envgen] did let traces when its wrapping GOP-object was moved in edit mode. But that was a year or two ago, on windows, and now I can't reproduce this malfunction on my new setup (mac os X + pd-0.46-7 + ggee via deken). So my mistake, sorry. I'll give a fresh look to [envgen]. But i always wondered if it would be complicate to have a few other features (like curved interpolation, or sort of bezier curve instead of only linear interpolation between points).

cheers,

Raphaël

best regards,

...

Raphaël

Greetings,

Fred Jan

...

Nice!

FWIW, in vanilla you have an array that can be used as a multislider, although it may be difficult to sometimes grab each point. In pd-l2ork you have an option of jump on click inside arrays, and a new mode of drawing arrays with individual bars whose colors can be customized. With this, the array effectively becomes a rather convenient multislider. Pd-L2Ork also outputs a bang every time the array has been changed if you need to use it for this kind of purpose.

Best,

Ico

On 6/25/2016 11:30 AM, Alexandre Torres Porres wrote:

2016-06-24 17:38 GMT-03:00 Roman Haefeli <reduzent@gmail.com mailto:reduzent@gmail.com>:

I even like them being abstractions as opposed to compiled externals.

Quite the opposite here :) I'd love to see them as externals and included in some library - maybe a max clone for cyclone...

---

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

2016-06-26 16:35 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:

for me this sounds a bit like "i'd love to see them as externals

totally sound like that :)

*so* they can be included in some library"

yeah, also like the idea of having it not as a single separate thing

would you care to explain what makes externals superior?

I don't think I'm the best one to discuss about the external x abstraction in terms of 'superiority', but yeah, I do like them better, I think they can be designed and work in ways that abstractions just don't (specially GUIs), and it's a common sense they are more efficient. In any way, I guess this discuss will touch known facts and issues and be subject to personal preferences.

cheers

Yeah, most of your points against externals sounds a bit like "they need to be maintained and that takes effort", I know... but I don't think that's a disadvantage of an external. If no one is willing to do it, that's another problem...

OK,sometimes, externals can be faster. And in sometimes, it matter. Also, sometimes, externals can be more flexible

Yes, those are my points regarding externals. But I say they're always more flexible. Abstractions' functionalities are very limited and not flexible at all.

Do you think of a fact that would lead to reprogram it to an external?

I was pinching general points for externals in general. Nonetheless, specifically about this one, I can think of many advantages. First, when I try to open it in vanilla, I get *658* lines in the Pd window of couldn't create errors. And it'd be more if I didn't have one of the dependencies, which is cyclone... but it does need over 10 external libraries, and I don't want them all...

So, first thing I have to say is... if external libraries are bad and a pain... why does this one needs so many of them? If this was a vanilla abstraction I could understand the point... but it's more of a Pd-Extended abstraction.

And thus I tried it in Pd-Extended 0.42-5, the one I use, but I still can't get it to work. Not sure how better it is in 0.43 (which I'm not installing as it always screws things up in my system) - but it seems it needs even more not included abstractions such as 's.mmb'

So, regarding this particular example, this is a very classic one where it's quite kludgy (with so many dependencies) that I can't even open.

Now, if cyclone had a multislider object, cloned from max msp ,and then if you have cyclone (one of the libraries this abstraction needs), all you had to do is call it... and, in this case (as I pointed when I entered this thread) it'd have many more functionalites.

I understand many of the arguments if this was a vanilla abstraction, but it is not. And even if it were, GUI is something that I think is particularly better to have an external in order to potentialize its interface purposes.

From reading the email, seems there are attempts to solve many of the

issues like right clicking and getting into a properties window, which I think it's impressive and I'd like to see that as I still cannot quite grasp how it'd be possible. Nonetheless, some GUI functionalities are still only possible with an external.

• as you know, i'm using a very limited range of externals

(pmpd / Gem and very few other).

So it doesn't seem likely you were able to check this one before discussing about it, or could you?

• they are faster to develop (human time is more expensive than cpu time)

It doesn't seem, by looking at all the dependencies and size of the patch, plus the research on how to solve many of the existing problems that it took little time to do this. And it seems the only issue for not having done this in C or whatever is the lack of knowledge in programming skills.

• lot's of externals are deprecated

I agree, that's why I don't like the idea of an abstraction that needs over 10 library dependencies and over 20 externals, many of which are currently unmaintained...

Anyway, making a decent GUI as an abstraction is not a trivial thing at all, as this example points out. I agree with Raphaël that there are many problems with GUI in Pd, I wish there were more... it's very limited, and being a visual graphic environment, that's a bit contrasting.

don't use pd if you need lot's of performance, use pd if you want to develop fast. Use C from start to end for performance.

I use Pd cause I'm a musician and I'm not a programmer, and I just want an efficient and convenient patching environment.

i think abstraction are preferable when possible because

I do offer a couple of abstractions that are vanilla patches, and I don't think they'd gain anything being externals, I agree with the general idea and common sense that sometimes it'll do... it'd be more convenient, and etc...

That is why I say this discussion will rely mostly in personal opinions and subjectivities, sometimes disagreements will be just subtle... so I never pointed "externals are always better, never do abstractions, just externals".

But I did jump in here to say it'd be so much better if this was just a compiled external in cyclone... and I do have a pretty strong point for that! To respond to your quote, in this case, I don't consider it convenient or preferable in this case.

cheers

2016-06-27 7:09 GMT-03:00 cyrille henry ch@chnry.net:

hello,

i'm sorry to jump again on this kind of topic, but it's painful to read a mail like that.

Le 26/06/2016 23:31, Alexandre Torres Porres a écrit :

...

2016-06-26 16:35 GMT-03:00 IOhannes m zmölnig <zmoelnig@iem.at mailto: zmoelnig@iem.at>:

for me this sounds a bit like "i'd love to see them as externals

totally sound like that :)

*so* they can be included in some library"

yeah, also like the idea of having it not as a single separate thing

abstraction vs external did not change anything regarding this matter. anyhow, you can create a "useful_abstraction_from_the_mailing_list" folder on your computer and it will soon be full of patch. (no more separate thing)

...

would you care to explain what makes externals superior?

I don't think I'm the best one to discuss about the external x abstraction in terms of 'superiority', but yeah, I do like them better, I think they can be designed and work in ways that abstractions just don't (specially GUIs),

and it's a common sense they are more efficient.

common sense is sometime wrong.

• expr is an externals, using it for a big equation is slower than the

same equation programed as abstraction

• gui is slow, problem comes from TK, switching from abstraction to

external will not help

anyhow, performance is not really a problem because :

• You don't need to optimized everything. You have to optimize only the

bottleneck of your patch, usually it's the audio routine. Blindly optimizing the rest is loosing time for no performance gain.

• don't use pd if you need lot's of performance, use pd if you want to

develop fast. Use C from start to end for performance.

• as you know, i'm using a very limited range of externals (pmpd / Gem and

very few other). Even when working with very big patch, no externals could solve performance problem I could face.

i think abstraction are preferable when possible because :

• they don't need to be compiled. For example, there is no more windows

pmpd user because i can't provide binary for this platform. This is very sad. An other example is when distributing a patch on a CD/SD, it became obsolete as soon as osX get a new version.

• they are faster to develop (human time is more expensive than cpu time)
• they can be distribute with your patch, even if they are not part of an

official lib (solving dependency problem)

• They can be easily customizable by any user. (most pd user never

compiled anything). Or reuse only part of the abstraction.

• You can learn a lot about pd programming when analyzing an abstraction

code written by someone else

• lot's of externals are deprecated, patch using them became obsolete.

abstraction are immune to this problem

In any way, I guess this discuss will touch known facts and issues and be subject to personal preferences.

Personal preference can be irrational, but they can also evolve.

OK,sometimes, externals can be faster. And in sometimes, it matter. Also, sometimes, externals can be more flexible. (initbang problem)

But it look like this abstraction did not fall in this 2 categories. Do you think of a fact that would lead to reprogram it to an external?

cheers c

...

cheers

---

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

---

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

Hello,

I suppose this response is to no one in particular but I like talking to Alex so I'll reply to him =).

As per the abstraction vs externals for gui stuff debate, I have a few general thoughts/observations:

At least in my personal experience, I haven't had much luck with GUI abstractions. It seems like a lot of them that I at least have investigate date back to the pd-extended era of things and thus rely a lot of all the libraries provided with pd-extended, which loaded all the libaries as a default so they didn't have follow an libraryname/objectname convention of declaration. So I have to find out all the library dependencies and get them on my computer and if I don't want to automatically load all the libraries at start, I have to dig through and try to find where all these objects are within the subpatches of subpatches of abstractions to where these objects are and add the libraryname/ (or I suppose I could do a [declare -lib libraryname] too, I suppose that makes more sense). At least to me, not just externals but abstractions suffer from maintenance issues as well. At least with externals, compilation lends itself to more of a standalone mindset without this pure data library dependency hell (although of course externals upon compilation can suffer from this as well). Perhaps this is a historical issue though and now that PD-extended is being phased out, this situation going forward would be less of an issue.

Also, perhaps it is just my own failing as a PD programmer, but I've never felt entirely comfortable with multiplicity in a graphical programming language. Like say, I want a 100x120 grid of toggle boxes that fits within a 640x480 rectangle and all their backgrounds are black and their Xs are yellow and each toggle box is hot so when you select one, it dumps out a list of all the values. Plus, every 500 ms I want the backgrounds of all the toggle boxes to flash blue so it's a clear visual cue that's where a downbeat is. It feels like in this case, I'm going to be making a lot of objects and connecting a lot of cords or do a clickable canvas or use structs (I think there was an abstraction that did this?) or something like that. At least for me, it feels way more natural to use a text-based language vs a graphic-based language to do a whole lot of one particular thing and keep track of it all and thus I'd lean more towards external vs abstraction. Plus with an external you get more flexibility with what you can do rather than be limited to using Pure Data objects to try to achieve your goals, although I can see that perhaps in a lot of cases this flexibility is not needed.

I don't know, I'm sort of rambling and losing my train of thought here lol. I'm glad this topic is being brought up though, it's making me reconsider abstractions and costs and benefits or doing abstractions vs externals. Maybe I just need to familiarize myself more with things you can do with canvases and how to do iteration in Pure Data =).

Derek

===================== Derek Kwan www.derekxkwan.com

Hello,

I think this discussion is moving to a general debate... or a troll :-( about external vs. abstraction Anyway, I'm interested in this not-so-childish debate, even if I might not have the skills to give some arguments (like on performance), and that I think it's more a personal matter at the end.

However, I do agree with Cyrille that shared abstractions may be good because

• they are patched in "pd" which is, for sure and at least the "common

language of the pd users".

• they can spread and teach clever or elegant ways of patching
• they can provide ways of faster patching when well standardized (I'm

thinking for example to "list-abs")

2016-06-27 17:41 GMT+02:00 Alexandre Torres Porres porres@gmail.com:

Yeah, most of your points against externals sounds a bit like "they need to be maintained and that takes effort", I know... but I don't think that's a disadvantage of an external. If no one is willing to do it, that's another problem...

...

OK,sometimes, externals can be faster. And in sometimes, it matter. Also, sometimes, externals can be more flexible

Yes, those are my points regarding externals. But I say they're always more flexible. Abstractions' functionalities are very limited and not flexible at all.

Yes, I absolutely don't know how to program something like [comport] in an abstraction ;-)

...

Do you think of a fact that would lead to reprogram it to an external?

I was pinching general points for externals in general. Nonetheless, specifically about this one, I can think of many advantages. First, when I try to open it in vanilla, I get *658* lines in the Pd window of couldn't create errors. And it'd be more if I didn't have one of the dependencies, which is cyclone... but it does need over 10 external libraries, and I don't want them all...

So, first thing I have to say is... if external libraries are bad and a pain... why does this one needs so many of them? If this was a vanilla abstraction I could understand the point... but it's more of a Pd-Extended abstraction.

You could also have re-read my email before opening the patch... I warned that it had a lot of dependencies and that it was first written with Pd-Extended. However, as Roman pointed out, and that was also my question, half of the externals used here could be replaced by... abstractions ! If some users cared about having a good-standardized library of externals that could be way more easy to maintain because, once again, I think most users don't know C, but all of them know Pd, at least a bit of it. The reason the file is so big, is that I replaced some of my own abstraction by the same but in a subpatch, which makes redundant code... So that's antoher point for abstractions.

And thus I tried it in Pd-Extended 0.42-5, the one I use, but I still can't get it to work. Not sure how better it is in 0.43 (which I'm not installing as it always screws things up in my system) - but it seems it needs even more not included abstractions such as 's.mmb'

Yes, as I said, 's.mmb' is not necessary to test this [ph_msl] abstraction. I should have removed it, sorry.

So, regarding this particular example, this is a very classic one where it's quite kludgy (with so many dependencies) that I can't even open.

The example was short because you could'nt explore so now we go back to general ideas and opinions ?... I'd be more interested in knowing what would be a good multislider GUI, and how it could be done (without learning C !?)

Now, if cyclone had a multislider object, cloned from max msp ,and then if you have cyclone (one of the libraries this abstraction needs), all you had to do is call it... and, in this case (as I pointed when I entered this thread) it'd have many more functionalites.

Could you be precise ? What "many more functionalies" ? I am really curious here.. that could be a challenge.

I understand many of the arguments if this was a vanilla abstraction, but it is not. And even if it were, GUI is something that I think is particularly better to have an external in order to potentialize its interface purposes.

From reading the email, seems there are attempts to solve many of the issues like right clicking and getting into a properties window, which I think it's impressive and I'd like to see that as I still cannot quite grasp how it'd be possible. Nonetheless, some GUI functionalities are still only possible with an external.

the properties windows is done with [iemguts/propertybang] and [vis 1( method to a [pd-$0-properties] subpatch containing the properties windows and all its GUI (size, number of sliders, colors...)

...

• as you know, i'm using a very limited range of externals

(pmpd / Gem and very few other).

So it doesn't seem likely you were able to check this one before discussing about it, or could you?

...

• they are faster to develop (human time is more expensive than cpu

time)

It doesn't seem, by looking at all the dependencies and size of the patch, plus the research on how to solve many of the existing problems that it took little time to do this. And it seems the only issue for not having done this in C or whatever is the lack of knowledge in programming skills.

Yes that is exactly what I said when proposing this abstraction, I am personally interested in this way of "contributing" to pd by sharing abstractions because I lack of the C knowledge and I lack of the desire of learning C. And because I don't want to wait for someone to program in C an external that does a good multislider GUI, I tried to do this as an abstraction (and once it is set up, I think it's a quite handy and functional GUI, at least I did use in live performances even though it's not a proper program test procedure...).

...

• lot's of externals are deprecated

I agree, that's why I don't like the idea of an abstraction that needs over 10 library dependencies and over 20 externals, many of which are currently unmaintained...

Anyway, making a decent GUI as an abstraction is not a trivial thing at all, as this example points out. I agree with Raphaël that there are many problems with GUI in Pd, I wish there were more... it's very limited, and being a visual graphic environment, that's a bit contrasting.

I agree with you. I think improving the "form" of Pd could make it a more useful tool. A diagram design involves as much "graphic/drawing" intelligence as it needs to mean something in a computer-language. (At least, the few months I tried Max/MSP after 4 years with Pd, that's what I felt, that my way patching was more clear because of some graphic features, like segmented patchchords... but I still resist to use MAX)

...

don't use pd if you need lot's of performance, use pd if you want to develop fast. Use C from start to end for performance.

I use Pd cause I'm a musician and I'm not a programmer, and I just want an efficient and convenient patching environment.

...

i think abstraction are preferable when possible because

I do offer a couple of abstractions that are vanilla patches, and I don't think they'd gain anything being externals, I agree with the general idea and common sense that sometimes it'll do... it'd be more convenient, and etc...

That is why I say this discussion will rely mostly in personal opinions and subjectivities, sometimes disagreements will be just subtle... so I never pointed "externals are always better, never do abstractions, just externals".

But I did jump in here to say it'd be so much better if this was just a compiled external in cyclone... and I do have a pretty strong point for that! To respond to your quote, in this case, I don't consider it convenient or preferable in this case.

I agree with that. It would be probably more : distributable, efficient, maintainable, easy to improve... if it was written in C instead on relying on dozen of externals that may be discontinued. However, I think that the vast majority of pd users don't know C, don't want to learn it... but would be glad to contribute to the improvement of Pd as a "efficient and convenient patching environment".

I think that abstractions are messy but a good way to experiment patching techniques. I have the impression that an object like "clone" (that I haven't tested yet but read about it) is a standardization/formalization in C of what a lot of users had done practically with dynamic-patching.

I am still interested to know if this [ph_msl] could be an alternative to wait that generous and clever developers make and provide a nicely designed external multislider GUI ? ... as this one features :

• mouse/key user input close to iemGUIs (alt-click for smaller step,

shift-click for relative mode)

• size / colors / number of sliders parameters

--> that can be set by message and through a GUI you show by 'right-click > Properties' --> that can be stored as the instance arguments, so be saved with parent patch

I think this abstraction dependencies could easily be reduced to : [iemguts/receivecanvas] [iemguts/canvasargs] [iemguts/propertybang] [iemgui/iem_event] [hcs/colorpanel]

Best regards,

Raphaël

I agree with Alexander. Also Ivica has pointed the use of array as a multislider, I attach an example on that. Very easy and useful. Also I consider “multislider” a missing object or a bug in “zexy” not in cyclone. :)

Salutti,Lucarda. Mensaje telepatico asistido por maquinas.

From: porres@gmail.com Date: Mon, 27 Jun 2016 18:44:01 -0300 To: phae.ilias@gmail.com CC: pd-list@lists.iem.at Subject: Re: [PD] a multislider GUI as abstraction

2016-06-27 18:08 GMT-03:00 Raphaël Ilias phae.ilias@gmail.com: I think this discussion is moving to a general debate... or a troll :-( about external vs. abstraction Anyway, I'm interested in this not-so-childish debate,

On Mon, 2016-06-27 at 18:44 -0300, Alexandre Torres Porres wrote:

I do agree on this point about their convenience and everything. I pointed I do offer abstractions for that matter. Though I do maintain the personal and humble opinion that I'd rather see a multislider external in this case. Mostly because I don't feel like installing 10 external libraries just so I can check it.

Valid point. I guess nobody is seeing an advantage in having an abstraction depending on many externals over an external not depending on anything. The general "pro-abstraction" notion does probably focus more on vanilla-only abstractions (or abstractions as part of a library): They _are_ more portable as they do not need to be compiled for several platforms, they _are_ more educative for Pd users (especially those that call themselves 'not programmers, but musicians'), since they can be more easily inspected than externals. Those are facts and not a matter of preference.

I guess I wasn't clear when I said I'd love to see it as an external and included in some library - maybe I should have spent more time writing more than just a couple of lines. But my point was only that it'd be quite easier if it were the case where we could just see it just as an external included in some of the libraries you used - like cyclone...

I agree with you about the ease of libraries but still have the impression you think something can only be a library when it is compiled code, or am I wrong? I don't know where this notion comes from, but it is simply not true. I don't know if you have noticed, but zexy is a mixed library consisting of abstractions and externals (why should everything in it be externals?). list-abs is a library consisting only of abstractions. I don't see any reason why something couldn't be added to a library as abstraction. In the case of ph_msl the elimination of a lot of dependencies would be a valid reason for rewriting it as an external.

Now that I hopefully made myself clear, I wonder and ask; does anyeone disagree with that? Does anybody think it's a better thing that cyclone doesn't have a multislider object included right there and that maybe it's just better to have an abstraction that relies on the cyclone library and many more?

No, I believe most agree with you, at least I do. The discussion arose because you sounded like compiled externals should be _generally_ preferred which I still disagree with. In the end your own argument is "but as an external it would require less externals" - we're on the same track on this :-)

Roman

Hello dear pd-freaks,

I come back on this thread not to reanimate the subjective debate about abstractions vs. externals... ;-) but to provide for those interested an updated and less dependent version of [ph_msl] that is, for those who didn't read earlier, an abstraction-based multislider GUI.

Please see "ph_msh-help.pd" in attached .zip for more info.

You now only need 3 libraries to try it. It's functional for me with pd-0.46-7 & pd-0.47-1 and deken's libraries : iemlib / iemguts / iemgui I'd be happy to have remarks on it, if some may find it useful enough to use and care have it maintained standard (a few features could be added like receive/send-symbols) ...and to know if you find that it's worthy to share this kind of abstraction or if it's useless regarding pd's future development (like the all GUI of pd may change soon and become something javascript...) or still "too fragile" hacks/way of doing thing.

It is still "a big patch" and relies on unavoidable externals (all come from iem) mostly to perform dynamic-patching, state-saving and user events capture :

[iemguts/canvasargs] [iemguts/propertybang] [iemgui/iem_event] [iemlib/dollarg]

That's still 3 libraries and 4 externals

Moreover, for the sake of avoiding redundant code, this abstraction is provided with 8 homemade abstractions,

• 6 about color-format conversion : ph_iem2rgb ph_iem2web ph_rgb2iem ph_rgb2web ph_web2iem ph_web2rgb
• 1 control facility : ph_skip
• and 1 GUI abstraction for picking colors and to avoid dependency on

[hcs/colorpanel] : ph_g.colorpicker

Hope I am not the only one interested in this.. even though I firstly made it for my personal use.

all best,

Raphaël

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