Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The way I have been thinking is that the first inlet is the general
inlet, and it can accept many types of messages. Then the second inlet
lines up with the first argument, the third inlet to the second
argument, etc. I think this is pretty clean and flexible, and I think
it would be nice to have some kind of standard for this.Obviously, it doesn't work for all objects, but I think it would be
good to standardize on objects it does work for.
The RRADical patches would be an example for an orthogonal (rradically different) approach. Here the first argument is a "tag", which generally can not be changed except by reinstantiating the abstraction, but not through an inlet (there are ways to change it internally, but this, too, works different).
The rightmost in- and outlets are catch-all inlets intended for list-like OSC-messages. The targets are actually automatically built depending on what kind of [commun] objects are used inside the abstraction.
Explaining this in words might seem complicated, but once you use it, it feels very natural. On one hand it saves a lot of work and on the other it offers a bigger flexibility than mapping inlets and arguments one-to-one. (You could think of the OSC-inlets as a kind of macro.)
For example I can add a new "thing" to set remotely just by creating a [commun /thing $0] object inside an abstraction. Nothing more and no inlets are necessary to make this "/thing" read- and settable through the OSC-in/outlet.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__