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