[PD] a multislider GUI as abstraction

[cyrille henry]

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