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@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@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




2018-03-06 18:31 GMT+01:00 Alex <x37v.alex@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@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@gmail.com>
> > An: Pd-List <pd-list@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@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> >
>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list


_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list



_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list