AW: [PD] prepend object

[Krzysztof Czaja]

hi Thomas,

Thomas Grill wrote:
...
 > How do you deal with objects/features that are not optimally solved in
 > MaxMSP and/or implemented differently in their (equally named) pd
 > counterparts?

the most important thing is to ease the pain of `recycling'
(although it will never be painless) -- porting existing max/msp
patches to Pd and creating Pd patches ready to be ported to max --
and not to ease the pain of making new patches.

The somewhat less important thing is that there are, indeed, quite
useful classes in max/msp, which could be made even more useful by
implementing some additional features.  If such additional feature
does not break max->Pd compatibility, I would be willing to implement
it, but then, if someone uses it in a Pd patch, a warning should be
printed out about breaking ``backwards compatibility'' (Pd->max).

Speaking of name clashes with Pd counterparts -- this was the
subject of a small voting proposed some time ago on pd-list.  The
poll's results were, basically (but not necessarily accurately),
that internal Pd classes need to remain as they are, but it is
better for externals to conform, or change the name.

...
 > For example, the prepend object in Max/MSP can be sent a [set preatom(
 > message, which then makes the object prepend "preatom" to every incoming
 > message. Therefore you can't prepend to a message beginning with "set".

one can always [route]...

...
 > Well, go on and use Thomas Musil's since it's smaller for use and possibly
 > better tested.

but not fully compatible.  Otoh gg's seems to be unfinished -- but
I suspect it uses similar memory scheme as max does (stack instead
of a heap).  I may be wrong, though...

Krzysztof