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 <zmoel...@iem.at
<mailto:zmoel...@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
