[PD] inlet and inlet~

[Matt Barber]

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 at 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
>