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/li stinfo/pd-list