[PD] adding outlets to [inlet~] (was How can a signal inlet of an object know if it's receiving a signal)

[Alexandre Torres Porres]

yeah, but it's a completely different picture.

we're talking here about an "invisible" inlet. Please note that [inlet~]
does not actually have any real inlet on its box.

I was also assuming and pretty sure it'd be easy to handle both signal and
control data for [inlet~], but adding an inlet to a canvas is a completely
different process than adding an inlet to an object, and it really has to
be either a control inlet or an audio inlet.

Have a look at the code, where I highlighted it, this is it:
canvas_addinlet(x->x_canvas,
&x->x_obj.ob_pd, &s_signal);

As you can see, you need to specify if it is a signal or not.

And if we're talking about external coding, it is also actually the same
deal if you are adding secondary inlets to an object. You cannot have a
secondary inlet taking both a signal and a symbol input for instance. I can
only assume it is because of the same limitation.

cheers


2018-03-08 4:33 GMT-03:00 oliver <oliver at klingt.org>:

>
> Yeah, I've been still trying around and now I'm pretty sure this is
>> where you set the type, and I'm also now assuming there's no way to
>> carry both signals and control data in the same input as it is. This
>> seems to require changes to the core of Pd elsewhere, right?
>>
>
> ???
>
> i don't think so ...
>
> [writesf~], [tabwrite~], [snapshot~] etc.
>
> all of them vanilla objects, all take signal AND message inputs
>
>
> best
>
> oliver
>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
> stinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180308/360caf59/attachment.html>