True, I agree that showing the power of abstractions 'under the hood' is a great thing. but still, it should be carefully used.
For instance, teaching someone how to use PixelTango before their learning Gem is a bad idea. I like to look at PixelTango abstractions now to get ideas for my own Gem toys, but that is because I started using Gem from the basic objects first.
I guess what I was trying to say is that it's nice to show off these flashy libraries and all, but I wouldn't want to be teaching someone something and have them get distracted by the glitz before they get a solid grasp on the principles.
Now, for things such as demux, et al, I wholeheartedly agree that we should be trying to do this with standard objects. There is a definite gray area here between abstractions that act as applications and those that mimic native Pd objects or low-level externals.
Sometimes I think the motto of Pd should be:
"The picture is the program is the programming language is the application is the GUI is the tangled mess is the where am I again?"
~Kyle
On 5/30/07, Roman Haefeli reduzierer@yahoo.de wrote:
On Wed, 2007-05-30 at 12:29 -0500, Kyle Klipowicz wrote:
I guess I think that the best approach is to give them Pd-extended, but only show the vanilla objects and documentation first. Then, after they are proficient with the basics, blow their minds with Gem, hid, Pduino, list-abs, rtc-lib, rradical, etc.
why not show them pduino, list-abs, rtc-lib, rradical from the beginning? to stick with the [list prepend]-[route] vs. [demux] example: the problem here is, that [demux] is an external, which doesn't give you an idea, how things could be done otherwise (without specialized objects). if [demux] would be substituted by an abstraction made of [list prepend]-[route], you could have an insight, how things are done. in other words, i think, there is no drawback in using abstractions from the beginning, but maybe there is one with externals.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de