Hallo, Josh Steiner hat gesagt: // Josh Steiner wrote:
its a solution, but it wont work well for us because i want the performance system to be as consistant as possible so im not on stage scratchin my chin and thinking about which inlet does what. so i want all my abstractions first inlets to be action inlets, so for instance a sampler might take an audio signal and a 1/0 to turn sampling on off... i want to just plug an audio stream and a toggle into the first inlet instead of having to wrapperize the toggle to get it to work. its looking like i can't easily get what i want and am just going to have to have 1, 2, or 3 hot inlets depending on the object type (mono inlet~, mono inlet~ w/2nd hot control inlet, stereo inlet~, or stereo inlet~ w/3rd hot control inlet).
What I did in the RRADical patches is to reserve the rightmost inlet for OSC-messages. This makes that inlet another hot inlet, of course only for messages, but I can control everything I want through that inlet by just using various OSC messages. These messages are very easy to remember. They take their first path component out of the patch's first argument (or I just use * if I don'T care), all other arguments normally correspond to the visible controls, when using graph on parent.
Nevertheless, this allows me to get away with the smallest number of inlets: The rightmost one for OSC, all other for signals or special funtionality. To me, this turns out to be very consistent and easy to remember. Plus it's easy to build the OSC responders, as it's done automatically using the Memento system. Now I only still have to autobuild some /help-message that prints the active OSC paths to the console.
Ciao
Frank Barknecht _ ______footils.org__