[PD] inlet and inlet~

[Matt Barber]

Hello,

Thanks for your reply!

I think my wording of the original problem was wrong -- your solution
would work well, but my point is there should be an object (or maybe
this should just be the default behavior of [inlet~]) which looks like
the following (hopefully the ascii art doesn't get munged on the way
out):



 [inlet~]
 |         \
 |          \
signal    \
             control data



This way you could pass audio signals and control messages into the
one inlet, like you can with something like [snapshot~], say:

 [osc~]
 |
 |  [bang(
 |  /
 | /
 |/
[abstraction~ arg1 arg2 etc]


Inside the abstraction the signal would come out of [inlet~]'s left
outlet, and the bang would be sent to its right outlet and would be
passed to the rest of the abstraction appropriately and at the correct
time.  This would help complete the abstraction-as-object API and
could be a separate object if such a thing would use more overhead
than normal [inlet~]...


If I'm not mistaken your solution would allow you to decide whether an
inlet is a control or a signal object as it's instantiated in an
abstraction at creation time (which I think is what my original
wording might have implied) -- I think I'm after something a little
different than polymorphism (which is quite an interesting problem on
its own).  For numbers, [inlet~] already does a good job turning
floats into signals.


One other, possibly more extravagant feature that would go even further:

An object like [osc~] seems to "know" when a signal is attached to its
inlet or not -- if it's given a creation argument, it will snap back
to that, or the last float value it received when the audio signal is
disconnected.  I'm not sure how to simulate this behavior in an
abstraction; I think [inlet~] itself will snap to the last float it
received when an audio signal is disconnected, but if you want your
abstraction to move back to using the value of its creation argument,
there's a problem, since presumably the inlet~ knows nothing about
that.  One solution I've found is to poll the inlet with an [env~ 2]
to look for nonzero values and to switch between using the output of
the [inlet~] and a [sig $1] depending on the [env~]'s output, but this
assumes that zero is a "non-setting" (as it would snap to the $1 as
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...



Thanks,

Matt



On Wed, Jun 11, 2008 at 8:24 AM, Mathieu Bouchard <matju at artengine.ca> wrote:
> On Tue, 6 May 2008, Matt Barber wrote:
>
>> Is there a way to make an abstraction that has one inlet that takes both
>> signal and control messages (like osc~, e.g., or fiddle~ which gets audio
>> and setting info, etc.)?
>
> My solution has been to make an external that contains no objectclass and
> load it using -lib. It contains this code:
>
> #define ALIAS(y,x) \
>
>  class_addcreator((t_newmethod)getfn(m,gensym(x)),gensym(y),A_GIMME,0);
> t_pd *m = &pd_objectmaker;
> ALIAS( "inlet.f","inlet"  );
> ALIAS( "inlet.~","inlet~" );
>
> So after that, Pd 0.40 can instantiate it as [inlet.$1]
>
> If you are stuck with Pd 0.39 you will need to swap it around because
> [inlet.$1] won't work but [$1.inlet] will.
>
> But this is just an alternative to what Charles Henry said. I prefer mine
> because the syntax looks better. Then I pass either "f" or "~" as argument
> to an abstraction. I would later add more single-character suffixes such as
> "s" and such perhaps, but only to the extent that polymorphism makes sense -
> first, an analogy has to be made between two types such that one behaviour
> one one type can be likened to one behaviour on the other. From that point,
> the two behaviours can be unified, partially or totally, and then [inlet.$1]
> (or equivalent) becomes useful.
>
>  _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec