<div dir="ltr">how about an inlet~ object that has a secondary outlet for control data?<div><br></div><div>anybody done that as an external?</div><div><br></div><div>well, that's something we could maybe just include in vanilla's inlet, but if there's any work torwards that direction, I can give a look and try doing a Pull Request</div><div><br></div><div>cheers</div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-03-07 9:59 GMT-03:00 Antoine Rousseau <span dir="ltr"><<a href="mailto:antoine@metalu.net" target="_blank">antoine@metalu.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Long time ago I implemented [dinlet~] (in moonlib) , aka "default inlet~": when the dinlet~ isn't connected, then it reverts to its default (constant) signal value, which is given as an argument.<br></div>Maybe reading the code could give you some ideas:<br><a href="https://github.com/MetaluNet/moonlib/blob/externals/moonlib/dinlet~.c" target="_blank">https://github.com/MetaluNet/<wbr>moonlib/blob/externals/<wbr>moonlib/dinlet~.c</a><span class="HOEnZb"><font color="#888888"><br><br><br></font></span></div></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_5236891230469403851gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><font face="arial, helvetica, sans-serif"> Antoine Rousseau </font></div><div dir="ltr"><font face="arial, helvetica, sans-serif">  <a href="http://metalu.net" target="_blank">http://www.metalu.net</a> __ <a href="http://www.metaluachahuter.com/compagnies/al1-ant1/" target="_blank">htt<wbr>p://www.metaluachahuter.com/</a><br><br></font></div></div></div></div></div></div></font></span><div><div class="h5">
<br><div class="gmail_quote">2018-03-06 18:31 GMT+01:00 Alex <span dir="ltr"><<a href="mailto:x37v.alex@gmail.com" target="_blank">x37v.alex@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I put up a related 'enhancement' PR a bit ago for [inlet~] <a href="https://github.com/pure-data/pure-data/issues/259" target="_blank">https://github.com/pure-data/p<wbr>ure-data/issues/259</a><br><br></div><div>I dug into the ugen graph code a bit and got lost trying to implement it myself.. </div></div><div class="m_5236891230469403851HOEnZb"><div class="m_5236891230469403851h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 6, 2018 at 9:22 AM, Miller Puckette <span dir="ltr"><<a href="mailto:msp@ucsd.edu" target="_blank">msp@ucsd.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This too is on my (almost infinitely long) dolist... to somehow extend the<br>
"dsp" message to allow objects to find out whether there are signals connected<br>
or not (and perhaps also to be able to deal with unequal-sized arrays somehow).<br>
<br>
Main reason I think this is needed is so that objects like "vcf~" can take<br>
audio signals to change "q" without always assuming they're audio (which<br>
would cause more overhead).<br>
<br>
cheers<br>
<span class="m_5236891230469403851m_3534815459053793514HOEnZb"><font color="#888888">Miller<br>
</font></span><div class="m_5236891230469403851m_3534815459053793514HOEnZb"><div class="m_5236891230469403851m_3534815459053793514h5"><br>
On Tue, Mar 06, 2018 at 05:12:37PM +0100, Christof Ressi wrote:<br>
> the object doesn't know but the ugen graph algorithm does. if it sees that a signal inlet is not connected it creates a new signal and adds a scalar copy routine to the DSP chain.<br>
> the scalar value is stored in the inletunion in struct _inlet (m_obj.c) and it's updated whenever you send a float message to the inlet.<br>
> the first inlet is somewhat special in that you can use the CLASS_MAINSIGNALIN macro to store the scalar value directly in the class (usually named x_f).<br>
><br>
> have a look at ugen_doit in d_ugen.c:<br>
><br>
> if (!uin->i_nconnect)<br>
> {<br>
>     t_float *scalar;<br>
>     s3 = signal_new(dc->dc_calcsize, dc->dc_srate);<br>
>     /* post("%s: unconnected signal inlet set to zero",<br>
>        class_getname(u->u_obj->ob_pd)<wbr>); */<br>
>     if ((scalar = obj_findsignalscalar(u->u_obj, i)))<br>
>         dsp_add_scalarcopy(scalar, s3->s_vec, s3->s_n);<br>
>     else<br>
>         dsp_add_zero(s3->s_vec, s3->s_n);<br>
>     uin->i_signal = s3;<br>
>     s3->s_refcount = 1;<br>
> }<br>
><br>
><br>
> > Gesendet: Dienstag, 06. März 2018 um 16:08 Uhr<br>
> > Von: Alexandros <<a href="mailto:adrcki@gmail.com" target="_blank">adrcki@gmail.com</a>><br>
> > An: Pd-List <<a href="mailto:pd-list@lists.iem.at" target="_blank">pd-list@lists.iem.at</a>><br>
> > Betreff: [PD] How can a signal inlet of an object know if it's receiving a signal<br>
> ><br>
> > [phasor~] ([osc~], and probably other objects too) seems to be aware of<br>
> > signals being connected to its left-most inlet. Providing an argument to<br>
> > [phasor~], if there's no signal coming in its inlet, it will use its<br>
> > argument for the frequency. As soon as a signal is connected, it will<br>
> > use that signal for its frequency. As soon as this signal gets<br>
> > disconnected (even if the signal is 0), [phasor~] will go back to using<br>
> > its argument for its frequency.<br>
> ><br>
> > Reading [phasor~]'s code in d_osc.c, I can't understand how this is<br>
> > achieved. I thought of looking into canvasconnections.c from the iemguts<br>
> > library, but it's a bit too complicated for me. Still, there's this<br>
> > comment in that file:<br>
> ><br>
> > /* as Pd does not have any information about connections to inlets,<br>
> >      * we have to find out ourselves<br>
> >      * this is done by traversing all objects in the canvas and try<br>
> >      * to find out, whether they are connected to us!<br>
> >      */<br>
> ><br>
> > Does this have to do with control inlets only? How can [phasor~] know if<br>
> > it's receiving a singal in its frequency inlet?<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>
> ><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>
<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>
</div></div></blockquote></div><br></div>
</div></div><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>
<br></blockquote></div><br></div></div></div>
<br>______________________________<wbr>_________________<br>
<a href="mailto:Pd-list@lists.iem.at">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/<wbr>listinfo/pd-list</a><br>
<br></blockquote></div><br></div>