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