[PD] How can a signal inlet of an object know if it's receiving a signal

[Alex]

I put up a related 'enhancement' PR a bit ago for [inlet~]
https://github.com/pure-data/pure-data/issues/259

I dug into the ugen graph code a bit and got lost trying to implement it
myself..

On Tue, Mar 6, 2018 at 9:22 AM, Miller Puckette <msp at ucsd.edu> wrote:

> This too is on my (almost infinitely long) dolist... to somehow extend the
> "dsp" message to allow objects to find out whether there are signals
> connected
> or not (and perhaps also to be able to deal with unequal-sized arrays
> somehow).
>
> Main reason I think this is needed is so that objects like "vcf~" can take
> audio signals to change "q" without always assuming they're audio (which
> would cause more overhead).
>
> cheers
> Miller
>
> On Tue, Mar 06, 2018 at 05:12:37PM +0100, Christof Ressi wrote:
> > 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.
> > 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.
> > 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).
> >
> > have a look at ugen_doit in d_ugen.c:
> >
> > if (!uin->i_nconnect)
> > {
> >     t_float *scalar;
> >     s3 = signal_new(dc->dc_calcsize, dc->dc_srate);
> >     /* post("%s: unconnected signal inlet set to zero",
> >        class_getname(u->u_obj->ob_pd)); */
> >     if ((scalar = obj_findsignalscalar(u->u_obj, i)))
> >         dsp_add_scalarcopy(scalar, s3->s_vec, s3->s_n);
> >     else
> >         dsp_add_zero(s3->s_vec, s3->s_n);
> >     uin->i_signal = s3;
> >     s3->s_refcount = 1;
> > }
> >
> >
> > > Gesendet: Dienstag, 06. März 2018 um 16:08 Uhr
> > > Von: Alexandros <adrcki at gmail.com>
> > > An: Pd-List <pd-list at lists.iem.at>
> > > Betreff: [PD] How can a signal inlet of an object know if it's
> receiving a signal
> > >
> > > [phasor~] ([osc~], and probably other objects too) seems to be aware of
> > > signals being connected to its left-most inlet. Providing an argument
> to
> > > [phasor~], if there's no signal coming in its inlet, it will use its
> > > argument for the frequency. As soon as a signal is connected, it will
> > > use that signal for its frequency. As soon as this signal gets
> > > disconnected (even if the signal is 0), [phasor~] will go back to using
> > > its argument for its frequency.
> > >
> > > Reading [phasor~]'s code in d_osc.c, I can't understand how this is
> > > achieved. I thought of looking into canvasconnections.c from the
> iemguts
> > > library, but it's a bit too complicated for me. Still, there's this
> > > comment in that file:
> > >
> > > /* as Pd does not have any information about connections to inlets,
> > >      * we have to find out ourselves
> > >      * this is done by traversing all objects in the canvas and try
> > >      * to find out, whether they are connected to us!
> > >      */
> > >
> > > Does this have to do with control inlets only? How can [phasor~] know
> if
> > > it's receiving a singal in its frequency inlet?
> > >
> > >
> > >
> > > _______________________________________________
> > > Pd-list at lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
> > >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180306/791f9c12/attachment-0001.html>