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@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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list