aha, so they take messages when you name them?
[quote]What would not work is to patch a control and a signal in simultaneously: the signal will overwrite the control.[/quote]
haha, in max it is like that:
most externals take signals and messages at the signal inlets.
if you connect a signal and a number to math objects like +~, the number would multiply the signal value.
if you want to connect signals and messages to an abstraction, you have to use something like [route start stop int float] inside the abstraction - the signal will come out of the "does not match" output of [route].
to complete the magic, you can pack signals into named connections using [prepend stereoL] [prepend stereoR] [prepend modulation1] [prepend modulation2] and then you can send all 4 signals through one connection into the subpatch.
you can also mix different types of connections that way.
regarding the problem of the OP:
in max i made myself abstractions to enhance the function of inlets and outlets, where you can send a [metro 3000] into using s/r in order to find out which inlets are connected and which not.
in theory one could do that with audio, too, and add a pulsetrain of + 1000. to a stream, later decode the stuff by modulo 1000.
of course i was more thinking about abstractions with 64 inputs of which you would often only connect only a few of them.
about your example... no idea how that same implementation would perform in pd? but in max, if you´d cut off a signal objects from DSP, for example by shutting down a subcircuit, the last value of the now stopped signal would remain in the input buffer of all connected objects.
it would not jump to 0 because there is no signal and it would also not snap back to the a possible default value of [~*]
so how about this?
one reason why i find it "strange" is that it causes an inconsistency between the externals paradigm and the patch paradigm, since you cant have inlets in your abstractions which takes both signals and messages.
the difference gave me a lot of headache already converting some of my patches.
i would have found it more logically that inlet~ would only get activated when you connect something to it, since patching requires a recompile anyway.
the way it is you are creating a lot of signal connections for nothing for some abstraction designs.
and dont worry, i can assure you that from a pd perspective the way inlets work in max are even more weird.
setting a default value for a signal as shown above is for sure easier in pd.
that was the missing part in my brain, thanks.
so it is the combination of a shared input and output buffer (something which does not exist in MSP) and a feedbackloop makes fexpr "possible".
otherwise using expr~ or other signal objects running under a vectorsize of 1 are doing the same.
the fact that pd is so different from max in these regards makes it really difficult to read these fexpr~ patches. (i am good in max and audio DSP - but max is the *only *language i can think in.)
i will try that with an example in the next days and then might come back to you,