[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?
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
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
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
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 __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
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/li
stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
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
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@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/li
stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
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
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@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/li
stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
2018-03-07 15:42 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
by the way, here's an issue on github
which had been posted on this thread already, haha, sorry
-
Alex -
Alexandre Torres Porres -
Alexandros -
Antoine Rousseau -
Christof Ressi -
Miller Puckette