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 <[EMAIL PROTECTED]> 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 > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
