[PD] one inlet that takes both signal and control

[Frank Barknecht]

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__