<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hello,<br><br></div><div class="gmail_quote">I think this discussion is moving to a general debate... or a troll :-( about external vs. abstraction<br>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.<br><br></div><div class="gmail_quote">However, I do agree with Cyrille that shared abstractions may be good because<br></div><div class="gmail_quote">- they are patched in "pd" which is, for sure and at least the "common language of the pd users".<br></div><div class="gmail_quote">- they can spread and teach clever or elegant ways of patching<br></div><div class="gmail_quote">- they can provide ways of faster patching when well standardized (I'm thinking for example to "list-abs")<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br>2016-06-27 17:41 GMT+02:00 Alexandre Torres Porres <span dir="ltr"><<a href="mailto:porres@gmail.com" target="_blank">porres@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"><div dir="ltr"><div>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... </div><span class=""><div><br></div><div>> <span style="font-size:12.8px">OK,sometimes, externals can be faster. And in sometimes, it matter.</span></div><span style="font-size:12.8px">> Also, sometimes, externals can be more flexible</span><div><br></div></span><div>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.</div></div></blockquote><div><br></div><div>Yes, I absolutely don't know how to program something like [comport] in an abstraction ;-)<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"><div dir="ltr"><span class=""><div><br></div>> <span style="font-size:12.8px">Do you think of a fact that would lead to reprogram it to an external?</span><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">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 <b><u>658</u></b> 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... </span> <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div></div></blockquote><div><br>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.<br></div><div>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.<br>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.<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"><div dir="ltr"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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'</span></div></div></blockquote><div><br></div><div>Yes, as I said, 's.mmb' is not necessary to test this [ph_msl] abstraction. I should have removed it, sorry.<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"><div dir="ltr"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div></div></blockquote><div><br></div><div>The example was short because you could'nt explore so now we go back to general ideas and opinions ?...<br></div><div>I'd be more interested in knowing what would be a good multislider GUI, and how it could be done (without learning C !?)<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"><div dir="ltr"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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 (</span><span style="font-size:12.8px">as I pointed when I entered this thread</span><span style="font-size:12.8px">) it'd have many more functionalites.</span></div></div></blockquote><div><br></div><div>Could you be precise ? What "many more functionalies" ? I am really curious here.. that could be a challenge.<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"><div dir="ltr"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span><span style="font-size:12.8px"><br></span></div></div></blockquote><div><br></div><div>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...)<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"><div dir="ltr"><div><span style="font-size:12.8px"></span></div><span class=""><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">- as you know, i'm using a very limited range of externals</span></div><div><span style="font-size:12.8px">> (pmpd / Gem and very few other).</span></div><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">So it doesn't seem likely you were able to check this one before discussing about it, or could you?</span></div><span class=""><div><span style="font-size:12.8px"><br></span></div><div>> <span style="font-size:12.8px">- they are faster to develop (human time is more expensive than cpu time)</span></div><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">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.</span></div></div></blockquote><div><br></div><div>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.<br></div><div>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...).<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"><div dir="ltr"><span class=""><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">- lot's of externals are deprecated</span></div><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">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...</span></div><div><span style="font-size:12.8px"><br></span></div><div>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. </div></div></blockquote><div><br></div><div>I agree with you.<br></div><div>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.<br></div><div>(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)<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"><div dir="ltr"><span class=""><div><br></div><div>> <span style="font-size:12.8px">don't use pd if you need lot's of performance, use pd if you</span></div><div><span style="font-size:12.8px">> want to develop fast. Use C from start to end for performance.</span></div><div><br></div></span><div>I use Pd cause I'm a musician and I'm not a programmer, and I just want an efficient and convenient patching environment.</div><span class=""><div><br></div><div><span style="font-size:12.8px">> i think abstraction are preferable when possible because</span><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">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... </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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". </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div></div></blockquote><div><br></div><div>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.<br></div><div>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".<br></div><div><br></div><div>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.<br></div><br></div><div class="gmail_quote">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 ?<br>... as this one features : <br>- mouse/key user input close to iemGUIs (alt-click for smaller step, shift-click for relative mode)<br>- size / colors / number of sliders parameters<br>--> that can be set by message and through a GUI you show by 'right-click > Properties'<br></div><div class="gmail_quote">--> that can be stored as the instance arguments, so be saved with parent patch<br><br></div><div class="gmail_quote">I think this abstraction dependencies could easily be reduced to :<br>[iemguts/receivecanvas]<br>[iemguts/canvasargs]<br>[iemguts/propertybang]<br>[iemgui/iem_event]<br>[hcs/colorpanel]<br><br></div><div class="gmail_quote">Best regards,<br><br></div><div class="gmail_quote">Raphaël<br></div></div></div>