Right, I had thought about a third outlet which sends a 1 or a 0 depending on connection state -- somehow the float argument seems better integrated with the default behavior of other objects, and much simpler to use. I think the reason is that floats coming in are already promoted to signals; in the "split signal and control" model for [inlet~], if floats were passed as control data rather than promoted then the third outlet for connection state would make more sense.
In fact, now that I think about it this may be a very different problem from the splitting signal and control problem because it might not just affect [inlet~] -- a similar feature could be made for [outlet~] since it can also take float messages and promote them to signals (this functionality is much less needed for [outlet~] than for [inlet~] however, since float messages can be passed directly to the [outlet~] from inside the patch, but it could be useful especially for an abstraction whose internal connections change dynamically).
I only know two arguments for [inlet~] and [outlet~] -- "hold" and "lin" -- but they don't take floats for anything, do they? (actually, they currently take "0", I guess with the default "interleave zeroes" meaning?) I suppose I need to go through the code more thoroughly, but I could imagine that since they already know what to do with one nonzero float argument (the object is not created), they could possibly use that float instead as a default output value. The problem is what to do when you want both sample-and-hold when upsampling (say) and a default output value:
[inlet~ hold 0.5]
would not break current patches, as it keeps the currently available arguments first. The other problem is that other objects define arguments by order rather than by type, and I doubt anybody would want to require an argument for the default "intervleaving" that an [inlet~] or [outlet~] already does for upsampling just to maintain proper order:
[outlet~ inter 0.7]
seems kind of silly since the argument would not make explicit sense in non-upsampled subpatches/abstractions.
Of course this is all moot if [inlet~] and [outlet~] already take float arguments for something after all. One other option which I think is way too extravagant for something this low-level would be to provide flagged arguments a la [sigmund~]... it would be too error-prone and would break tons of patches.
At any rate, I appreciate your help and others' on the list greatly!
Thanks,
Matt
On Thu, Jun 12, 2008 at 3:41 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Matt Barber wrote:
Hello,
soon as it received a zero-valued float or [sig~]. The feature I propose would be to allow a float argument to [inlet~] as the default signal to be passed and which is remembered as signals are connected and disconnected to the abstraction from the parent, only until the value stored is changed by a float message. Of course I'm interested in other currently implementable solutions...
you seem to not be aware that [inlet~] already takes arguments, which makes your proposal a bit more awkward to implement. (nonetheless i like the basic idea; as you are already adding outlets to [inlet~] once could imagine a third inlet that would tell you the connection state...)
mfg.asdr IOhannes