On Thu, 14 Oct 2004, B. Bogart wrote:
Right now the control bus just prepends a string to set the destination (like text) but just using OSC formatted messages for interal communication would have significant advantages.
Is there a reason why this has to be done with OSC messages instead of pd messages ? IMO opinion it makes pd harder to use if you mix concepts. Is there a significant improvement from using /[patchname]/[abstraction-name]/f1 over [patchname] [abstraction-name] f1 ?
(except the spaces problem, which has to be solved separately)
I even think that the OSC messages should be converted into pd messages immediately, without using the OSCroute object.
Well, a question of taste, but thats my taste anyhow. same for naming of states. should be symbols IMO, without "/"
Ok all that was to say that its most flexible and modular to have a number of float values that have OSC names. I wonder if there would be a way to have a standard OSC namespace for a patch that all objects can be referenced via OSC something like /[patchname]/[abstraction-name]/f1 for
One problem might be that this naming is ambiguous, there could be hundreds of /[patchname]/[abstraction-name]/f1
first float. I think OSC really becomes powerful when the namespace reflects the structure of the patch, rather than being wholly generated and imagined by the user. this opens the door to extracting the function of a patch from the OSC namespace and simply being able to standardize so that patches not made to work together over OSC magically do.
Great idea, but again, why has this to be done with OSC ? I am very much for OSC compatibility of pd, but we should not change the style of the pd language for that. I think this would be possible to be implemented in pd messages instead of OSC messages. Just replace the "/" by a " ".
Guenter
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
Interpolation is something I talked about with Cyrille at the convention and definitely something, I'd like to somehow integrate into Memento. However I haven't yet thought about a way that is "stupid" enough for general use here. How are you (intending to) doing it?
Of course it would be great if state-saving was built right into PD.
I had this crazy idea when talking with Miller about this, that it could be nice to extend the basic data type objects like "float" with a OSC-tag. Instead of [float 0] ony would write [float 0 /freq], [f 0 $1/freq] or even [f 0 $0/freq] to make that float value state-saveable and accessible through some OSC inlet or sender. Then the currently nessecary [commun] objects could go away, and [originator] and [caretaker] could become an ext-/internal.
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev