On Jul 8, 2010, at 3:30 AM, IOhannes m zmoelnig wrote:
On 2010-07-08 01:09, Hans-Christoph Steiner wrote:
I guess there should be a third inlet for the signals? I see
something like this:STDIN signals process name | | | | | | [process /usr/sbin/httpd] | | | | | | STDOUT STDERR status messages, like PID, current process name, state, etc.
hmm, iirc "process name" is there mainly to override the process given as the argument.
sending a new "process name" (e.g. "/usr/sbin/apache2") into the last inlet surely won't start the new process, would it? for me starting a new process seems to be a very "hot" action.
then i don't see a reason why we need different inlets for "process name" and "signals", as both are there to control the the current/ future process from "outside".
so i would basically simplify this to the attached interface.
as for sending signals: even though i like signals very much, there is no such concept on w32 (or at least it is not readily available for
the little programmer). personally i would hate to have the 5th object for the same task
that is still highly platform dependent.
Your example seems backwards to me. STDIN is definitely a hot action,
and most likely the inlet that is going to be used the most. I
imagine many users would never change the program that is being run.
STDOUT will most likely be the main outlet used, i.e the result, so
that really should be the first outlet. The process information is
meta/info/status stuff like in [hid], [comport], etc. so it should be
the right outlet like them.
I could see combining the signal and process inlets into one second
meta inlet, but it seems to me that since there are just two messages
(run and signal), why not just make each have their own inlet and
spare the patcher from having to build up messages as much.
.hc
'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf