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

Alexandre Torres Porres porres at gmail.com
Wed Mar 7 17:43:21 CET 2018


how about an inlet~ object that has a secondary outlet for control data?

anybody done that as an external?

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

cheers

2018-03-07 9:59 GMT-03:00 Antoine Rousseau <antoine at metalu.net>:

> 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.
> Maybe reading the code could give you some ideas:
> https://github.com/MetaluNet/moonlib/blob/externals/moonlib/dinlet~.c
>
>
>
> Antoine Rousseau
>   http://www.metalu.net <http://metalu.net> __ htt
> p://www.metaluachahuter.com/
> <http://www.metaluachahuter.com/compagnies/al1-ant1/>
>
>
> 2018-03-06 18:31 GMT+01:00 Alex <x37v.alex at gmail.com>:
>
>> 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/li
>>> stinfo/pd-list
>>> > >
>>> >
>>> > _______________________________________________
>>> > Pd-list at lists.iem.at mailing list
>>> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>>> stinfo/pd-list
>>>
>>> _______________________________________________
>>> Pd-list at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>>> stinfo/pd-list
>>>
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/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/20180307/5bbdd487/attachment.html>


More information about the Pd-list mailing list