<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><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><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><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><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></div><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><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><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><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><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><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><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><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><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><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><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><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><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><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><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><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">cheers</span></div><div><div style=""><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-27 7:09 GMT-03:00 cyrille henry <span dir="ltr"><<a href="mailto:ch@chnry.net" target="_blank">ch@chnry.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hello,<br>
<br>
i'm sorry to jump again on this kind of topic, but it's painful to read a mail like that.<br>
<br>
Le 26/06/2016 23:31, Alexandre Torres Porres a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
2016-06-26 16:35 GMT-03:00 IOhannes m zmölnig <<a href="mailto:zmoelnig@iem.at" target="_blank">zmoelnig@iem.at</a> <mailto:<a href="mailto:zmoelnig@iem.at" target="_blank">zmoelnig@iem.at</a>>>:<span class=""><br>
<br>
    for me this sounds a bit like "i'd love to see them as externals<br>
<br>
<br>
totally sound like that :)<br>
<br>
    *so* they can be included in some library"<br>
<br>
<br>
yeah, also like the idea of having it not as a single separate thing<br>
</span></blockquote>
<br>
abstraction vs external did not change anything regarding this matter.<br>
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)<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
    would you care to explain what makes externals superior?<br>
<br>
<br>
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),<br>
</blockquote>
 and it's a common sense they are more efficient.<br>
<br></span>
common sense is sometime wrong.<br>
- expr is an externals, using it for a big equation is slower than the same equation programed as abstraction<br>
- gui is slow, problem comes from TK, switching from abstraction to external will not help<br>
<br>
<br>
anyhow, performance is not really a problem because :<br>
- 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.<br>
- 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.<br>
- 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.<br>
<br>
<br>
i think abstraction are preferable when possible because :<br>
- 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.<br>
An other example is when distributing a patch on a CD/SD, it became obsolete as soon as osX get a new version.<br>
- they are faster to develop (human time is more expensive than cpu time)<br>
- they can be distribute with your patch, even if they are not part of an official lib (solving dependency problem)<br>
- They can be easily customizable by any user. (most pd user never compiled anything). Or reuse only part of the abstraction.<br>
- You can learn a lot about pd programming when analyzing an abstraction code written by someone else<br>
- lot's of externals are deprecated, patch using them became obsolete. abstraction are immune to this problem<span class=""><br>
<br>
<br>
In any way, I guess this discuss will touch known facts and issues and be subject to personal preferences.<br>
<br></span>
Personal preference can be irrational, but they can also evolve.<br>
<br>
OK,sometimes, externals can be faster. And in sometimes, it matter.<br>
Also, sometimes, externals can be more flexible. (initbang problem)<br>
<br>
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?<br>
<br>
cheers<br>
c<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
cheers<span class=""><br>
<br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">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>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">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>
</div></div></blockquote></div><br></div>