<div dir="ltr">yeah, but it's a completely different picture.<div><br></div><div>we're talking here about an "invisible" inlet. Please note that [inlet~] does not actually have any real inlet on its box.</div><div><br></div><div>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.</div><div><br></div><div>Have a look at the code, where I highlighted it, this is it: <font color="#000000" style="font-family:Menlo;font-size:11px;font-style:normal;font-variant-ligatures:no-common-ligatures;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">canvas_addinlet(x->x_canvas, &x->x_obj.ob_pd,<span> </span></font><font color="#ff0000" style="font-family:Menlo;font-size:11px;font-style:normal;font-variant-ligatures:no-common-ligatures;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">&s_signal</font><font color="#000000" style="font-family:Menlo;font-size:11px;font-style:normal;font-variant-ligatures:no-common-ligatures;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">);</font></div><div><br></div><div>As you can see, you need to specify if it is a signal or not.  </div><div><br></div><div>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.</div><div><br></div><div>cheers</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-03-08 4:33 GMT-03:00 oliver <span dir="ltr"><<a href="mailto:oliver@klingt.org" target="_blank">oliver@klingt.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yeah, I've been still trying around and now I'm pretty sure this is<br>
where you set the type, and I'm also now assuming there's no way to<br>
carry both signals and control data in the same input as it is. This<br>
seems to require changes to the core of Pd elsewhere, right?<br>
</blockquote>
<br></span>
???<br>
<br>
i don't think so ...<br>
<br>
[writesf~], [tabwrite~], [snapshot~] etc.<br>
<br>
all of them vanilla objects, all take signal AND message inputs<br>
<br>
<br>
best<br>
<br>
oliver<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/li<wbr>stinfo/pd-list</a><br>
</blockquote></div><br></div>