Someone could just write new objectclasses that handle both signal
and message, maybe something like:
message_inlet~ message_outlet~
.hc
On Jun 12, 2008, at 4:09 PM, Matt Barber wrote:
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson