Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
And Pd doesn't provide enough when it comes to supporting abstractions in a way that makes them be able to use Pd in a way equivalent to how normal externals can use Pd, and at a price not significantly greater.
For example, [#in] and [#out] aren't in such great shape since they became abstractions, and they're significantly more complicated, because even the simplest dynamic patching is complicated.
At Pd Convention 2004, there was a nice moment during the papers sessions, where there was an apparent consensus that as many things as possible should be made as abstractions. I still think about that. I like the idea, and I've always liked the idea, and you can trace my appreciation of that idea back to the original design of GridFlow, but it's not always so feasible just by using Pd.
I think, Pd could benefit a lot by providing a default scripting language to write operations like [range] which are tediuos to do as an abstraction. Altough I'm not a fan of Tcl (and would prefer Lua), Tcl would be a natural choice as it's available anyway. Ideally the scripts would be saved within the patch, e.g. inside message boxes. Oh wait, that's toxy! Hm, ... but toxy has a horrible syntax, which I could never get around. But the general approach of it is a fantastic idea.
The advantages of a scripted Pd classes are: For certain tasks, especially those involving lots of repetition, patching is too much work. And as pd-extended shows, if you pack each and every external and abstraction into the pd-distribution, you either have to deal with ugly long names or live with namespace pollution.
Btw.: That's why today I tend to avoid installing lots of externals and rather copy them to a project's folder when needed. Apart from extensions that provide special functionality like Gem, msd, OSC or iemfilters, I don't use "convenience collections" like maxlib anymore - expect my own of course. Joao would probably call me a hardcore user. ;)
Ciao