On Fri, 15 Oct 2004, Frank Barknecht wrote:
I see, but that can be solved. "route" could be changed to do pattern matching.
I would generally have no problem with replacing the OSC-messages for rrad-internal messages with lists.
But I would need to solve another thing: The fact, that OSC message targets are just a single atom in Pd, and not a list, while they still can describe hierarchies of e.g. abstractions.
This is very useful, if you want to "pack" lists into abstraction arguments. $1 in OSC lingo can be "/myabs/synths/fm/carrier" whereas [route]-lingo would need $1-4 for the same: "myabs synths fm carrier".
Thinking about that I am not even sure if the possibility to send to /myabs/synths/fm/carrier directly is such a good thing, as it completely destroys encapsulation of abstractions. all /myabs messages should be handled by myabs and its subpatches.
Otherwise I can just hookup any receiver to /myabs/synths/fm/carrier and create a complete mess ... if I am not very careful.
Forcing decomposition of message hierarchies into the objects where they belong seem to be a restriction that actually helps to write better code.
Another problem is that a route with wildcards is not enough, what we would need additionally is a "receive" with wildcards.
I am still trying to follow the pd train of thought instead of thinking OSC ... If we are weak now, we will end up like C++, which has, in fact, its good additions, but there are too many bad ones and it generally ended up being a collection of concepts. It has its followers, though.
Guenter
Now someone might suggest to pack the 4-element list with something like "list2symbol" in advance. But in fact that only brings us back to OSC formatted messages. ;)
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev