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

Wed Mar 7 19:42:46 CET 2018

by the way, here's an issue on github

https://github.com/pure-data/pure-data/issues/259

I say it'd also be good to include this idea of using a float argument to
set a default value, but it's also interesting if this could be set via an
inlet as well, and now it seems all such enhancements would make [inlet~]
quite complex and maybe not likely, so I might go for an external design
first.

by checking
https://github.com/MetaluNet/moonlib/blob/externals/moonlib/dinlet~.c I can
see it's not actually using the "dinlet_float" function, and that this is
mostly just joining codes from m_obj and g_io.c but then just using an
"addcreator" and still relying in the code of inlet/inlet~ to do the job.

I guess I should start with the complete code of inlet~ and just edit it,
so I can make all these achievements (like new outlets and route control
messages)

cheers

2018-03-07 13:43 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:

> 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/listinfo/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/li
>> stinfo/pd-list
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180307/d2f1f233/attachment-0001.html>