-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello OSCx developer(s),
I see that "set" message has been added to the little todo list at the start of OSCroute.c. Has there been any progress on this front?
I'm working on a lot of complex collections of abstractions using memento and really need to be able to specify the route name via message rather than by argument. The reason being is that I'm working on an infrastructure so that the abstractions don't have to be named individually, they are automatically named by thier position in the structure. In order to name dynamically I need to be able to route OSC message dynamically!
I would really appreciate this feature, and would be happy to get any development code that represents a stab at the problem to work on myself.
Thanks for all your work.
Ben
yolla
just a quick quest: single or multi element OSCroute instances?
i.e. implication of multi element set: changing number of outlets on a living object, e possibile?
maybe tune pattern matching so multi element set can be synomymized with
|set (/bli|/bla) <
bst, opt/jdl/etc
[B. Bogart]->[[PD-dev] OSCroute "set" feature request]->[04-11-07 23:07]
|Hello OSCx developer(s), | |I see that "set" message has been added to the little todo list at the start of |OSCroute.c. Has there been any progress on this front? | |I'm working on a lot of complex collections of abstractions using memento and |really need to be able to specify the route name via message rather than by |argument. The reason being is that I'm working on an infrastructure so that the |abstractions don't have to be named individually, they are automatically named |by thier position in the structure. In order to name dynamically I need to be |able to route OSC message dynamically! | |I would really appreciate this feature, and would be happy to get any |development code that represents a stab at the problem to work on myself. | |Thanks for all your work. | |Ben | | |_______________________________________________ |PD-dev mailing list |PD-dev@iem.at |http://iem.at/cgi-bin/mailman/listinfo/pd-dev |------------ Output from gpg ------------ |gpg: Signature made Mon Nov 8 05:07:09 2004 CET using DSA key ID 9480DB97 |gpg: Can't check signature: public key not found | |
Heya,
Thanks for the quick reply.
For my own purposes I'd be fine with single element set.
That being said that longer term flexibility would mean multi-element set would come in handy... (I suppose what I'm saying here about OSCroute would also apply to pd's internal route?)
If there are issues with changing outlet of a living object one OSC specific solution could be:
if there is a single arg, and it is a float (w/out "/" prepended) then it would set the number of outlets. This would not break current patches and give us future functionality for multi element sets.
[set /one /two /three< | [OSCroute 3]
Same as:
[OSCroute /one /two /three]
Of course this approach would not work with PD's internal route...
Can you change the number of inlets of an instanciated object via message?
Thanks for entertaining the suggestion! B.
d.lj wrote:
yolla
just a quick quest: single or multi element OSCroute instances?
i.e. implication of multi element set: changing number of outlets on a living object, e possibile?
maybe tune pattern matching so multi element set can be synomymized with
|set (/bli|/bla) <
bst, opt/jdl/etc
[B. Bogart]->[[PD-dev] OSCroute "set" feature request]->[04-11-07 23:07]
|Hello OSCx developer(s), | |I see that "set" message has been added to the little todo list at the start of |OSCroute.c. Has there been any progress on this front? | |I'm working on a lot of complex collections of abstractions using memento and |really need to be able to specify the route name via message rather than by |argument. The reason being is that I'm working on an infrastructure so that the |abstractions don't have to be named individually, they are automatically named |by thier position in the structure. In order to name dynamically I need to be |able to route OSC message dynamically! | |I would really appreciate this feature, and would be happy to get any |development code that represents a stab at the problem to work on myself. | |Thanks for all your work. | |Ben | | |_______________________________________________ |PD-dev mailing list |PD-dev@iem.at |http://iem.at/cgi-bin/mailman/listinfo/pd-dev |------------ Output from gpg ------------ |gpg: Signature made Mon Nov 8 05:07:09 2004 CET using DSA key ID 9480DB97 |gpg: Can't check signature: public key not found | |
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
That being said that longer term flexibility would mean multi-element set would come in handy... (I suppose what I'm saying here about OSCroute would also apply to pd's internal route?)
For Pd's internal route I actually would prefer a very un-intrusive solution: To make it behave like [select]. That is, [route something] will be static, but [route] will be settable through a right inlet. The same as [select]. This could be a very simple model for [OSCroute] as well. Not very intrusive, but still very useful, and all outlet counts would stay static.
I already have put a feature suggestion to the Pd tracker regarding this [route] wish.
Ciao
On Thu, 11 Nov 2004, Frank Barknecht wrote:
For Pd's internal route I actually would prefer a very un-intrusive solution: To make it behave like [select]. That is, [route something] will be static, but [route] will be settable through a right inlet.
You mean route with more than one argument is not setable. [route something] has exactly one and would be setable.
Guenter
The same as [select]. This could be a very simple model for [OSCroute] as well. Not very intrusive, but still very useful, and all outlet counts would stay static.
I already have put a feature suggestion to the Pd tracker regarding this [route] wish.
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev