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