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 <por...@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
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list