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 <[email protected]> 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 <[email protected]> > > > An: Pd-List <[email protected]> > > > 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? > > > > > > > > > > > > _______________________________________________ > > > [email protected] mailing list > > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list > > > > > > > _______________________________________________ > > [email protected] mailing list > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
