Hi, so, I'm working on my variant of delread/write with more features like "freezing", for reference => https://lists.puredata.info/pipermail/pd-list/2021-03/129181.html
So, here's another question, thought I'd open a new thread. I'm now at the point of setting the delay name to delread-like object, the problem is that I need to force a dsp call, which can be done by creating a new object or something like that before the new delay name takes effect.
This is because the delay line to read is passed via the dsp_add function in "sigdelread_dsp" or "sigvd_dsp", for example see https://github.com/pure-data/pure-data/blob/master/src/d_delay.c#L330
someone once asked about this on the list and the answer was to find an alternative solution that didn't need to force the call, see https://lists.puredata.info/pipermail/pd-list/2020-11/128514.html - so I don't know if this is possible, or dangerous or something. I wouldn't know of a possible alternative as well.
I don't know if other people out there would love the idea of being able to set a new delay name to [delread~]/[delread4~]. If so, we can also make that request, but then the problem would be the same.
thanks
This is because the delay line to read is passed via the dsp_add function in "sigdelread_dsp" or "sigvd_dsp"
It doesn't have to be. You can certainly change the delay line during runtime, just like in [receive~], [throw~], [tabsend~], [tabreceive~], etc. All relevant information obtained in the "dsp" method, like x_sr, x_n and x_zerodel, is stored in the object and can be easily accessed any time.
I don't know if other people out there would love the idea of being able to set a new delay name to [delread~]/[delread4~]. If so, we can also make that request
Done: https://github.com/pure-data/pure-data/issues/1274
I might do a PR when I have some time.
Christof
On 01.03.2021 22:13, Alexandre Torres Porres wrote:
Hi, so, I'm working on my variant of delread/write with more features like "freezing", for reference => https://lists.puredata.info/pipermail/pd-list/2021-03/129181.html https://lists.puredata.info/pipermail/pd-list/2021-03/129181.html
So, here's another question, thought I'd open a new thread. I'm now at the point of setting the delay name to delread-like object, the problem is that I need to force a dsp call, which can be done by creating a new object or something like that before the new delay name takes effect.
This is because the delay line to read is passed via the dsp_add function in "sigdelread_dsp" or "sigvd_dsp", for example see https://github.com/pure-data/pure-data/blob/master/src/d_delay.c#L330 https://github.com/pure-data/pure-data/blob/master/src/d_delay.c#L330
someone once asked about this on the list and the answer was to find an alternative solution that didn't need to force the call, see https://lists.puredata.info/pipermail/pd-list/2020-11/128514.html https://lists.puredata.info/pipermail/pd-list/2020-11/128514.html - so I don't know if this is possible, or dangerous or something. I wouldn't know of a possible alternative as well.
I don't know if other people out there would love the idea of being able to set a new delay name to [delread~]/[delread4~]. If so, we can also make that request, but then the problem would be the same.
thanks
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em seg., 1 de mar. de 2021 às 20:19, Christof Ressi info@christofressi.com escreveu:
It doesn't have to be. You can certainly change the delay line during runtime, just like in [receive~], [throw~], [tabsend~], [tabreceive~], etc.
I thought so, but let me just get something straight, is it possible to force a global dsp call or not? Should it always be avoided at all costs?
Cause I'm now facing another issue, I have a [del~ in] object spitting a unique delay name, and when I connect it via a control cord to a [del~ out] object I want it to spit out the delay name symbol. I made it spit it out when there's a new dsp call, but.... control connections do not force a new dsp call, so I dunno.
I ask because I'm still thinking about strategies involving dsp calls and it'd be good to get a final word if that's a "PLEASE DON'T DO THAT" :)
Done: https://github.com/pure-data/pure-data/issues/1274
I might do a PR when I have some time.
Thanks, and I'll look into the way [receive~] and the like work to try and incorporate it in my external, I can also try a PR if you don't beat me to it in a quite probable better way.
"PLEASE DON'T DO THAT"
I would say so :-)
control connections do not force a new dsp call, so I dunno.
Pd objects are (unfortunately) not notified on connection changes and I can't think of a sane way to work around this. The real solution would be to add an API for object state change notifications. In the meantime, I would say: forget about it.
Christof
On 02.03.2021 00:40, Alexandre Torres Porres wrote:
Em seg., 1 de mar. de 2021 às 20:19, Christof Ressi <info@christofressi.com mailto:info@christofressi.com> escreveu:
It doesn't have to be. You can certainly change the delay line during runtime, just like in [receive~], [throw~], [tabsend~], [tabreceive~], etc.I thought so, but let me just get something straight, is it possible to force a global dsp call or not? Should it always be avoided at all costs?
Cause I'm now facing another issue, I have a [del~ in] object spitting a unique delay name, and when I connect it via a control cord to a [del~ out] object I want it to spit out the delay name symbol. I made it spit it out when there's a new dsp call, but.... control connections do not force a new dsp call, so I dunno.
I ask because I'm still thinking about strategies involving dsp calls and it'd be good to get a final word if that's a "PLEASE DON'T DO THAT" :)
Done: https://github.com/pure-data/pure-data/issues/1274 <https://github.com/pure-data/pure-data/issues/1274> I might do a PR when I have some time.Thanks, and I'll look into the way [receive~] and the like work to try and incorporate it in my external, I can also try a PR if you don't beat me to it in a quite probable better way.
Em seg., 1 de mar. de 2021 às 20:40, Alexandre Torres Porres < porres@gmail.com> escreveu:
I can also try a PR
I give up already, waiting for you :)
Em seg., 1 de mar. de 2021 às 21:02, Christof Ressi info@christofressi.com escreveu:
Pd objects are (unfortunately) not notified on connection changes and I can't think of a sane way to work around this. The real solution would be to add an API for object state change notifications. In the meantime, I would say: forget about it.
forgotten, but: https://github.com/pure-data/pure-data/issues/1275
while we're at it, any reason why not to have a "set" method for [send~] and [catch~]? Seems inconsistent
I recently implemented a variant of delread~ that can have it's delwrite~ set. Basically in the "set" messageI just did most of the things normally done in the dsp method. Instead of sending the pointer to the delwritectl to the performmethod using dsp_add, instead I send a pointer to a pointer to the delwritectl that is stored in the object dataspace.That way, when a different delwrite is set I just have to store the pointer in the object dataspace and dereference it correctlyin the perform method:you can see it in the .c files in this commithttps://github.com/sebshader/shadylib/commit/8bdf985aacb3979e776ad4e2487c451...
-seb
-----Original Message----- From: Alexandre Torres Porres porres@gmail.com To: Christof Ressi info@christofressi.com Cc: Pd-List pd-list@lists.iem.at Sent: Mon, Mar 1, 2021 5:08 pm Subject: Re: [PD] how to force the DSP call? / set delread~ delay name
Em seg., 1 de mar. de 2021 às 20:40, Alexandre Torres Porres porres@gmail.com escreveu:
I can also try a PR
I give up already, waiting for you :) Em seg., 1 de mar. de 2021 às 21:02, Christof Ressi info@christofressi.com escreveu:
Pd objects are (unfortunately) not notified on connection changes and I can't think of a sane way to work around this. The real solution would be to add an API for object state change notifications. In the meantime, I would say: forget about it.
forgotten, but: https://github.com/pure-data/pure-data/issues/1275 while we're at it, any reason why not to have a "set" method for [send~] and [catch~]? Seems inconsistent_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
while we're at it, any reason why not to have a "set" method for [send~] and [catch~]? Seems inconsistent
For the same reason why you can't set the name of [delwrite~]: it's the object owning the buffer. In theory, it would be possible to bind the object to another name, but why would you want to do that? Also, you would have to notify *all* existing [delread~] objects, so they have a chance to update the delay line (if needed).
Generally, resources have a fixed name and you only dynamically set the name in accessor objects. For example, you would set the array in [array set] and [array get], but you wouldn't change the name of the [array define] *).
Christof
*) Actuallly, it's possible with the "rename" method, but it's *very* confusing.
On 02.03.2021 02:08, Alexandre Torres Porres wrote:
Em seg., 1 de mar. de 2021 às 20:40, Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> escreveu:
I can also try a PRI give up already, waiting for you :)
Em seg., 1 de mar. de 2021 às 21:02, Christof Ressi <info@christofressi.com mailto:info@christofressi.com> escreveu:
Pd objects are (unfortunately) not notified on connection changes and I can't think of a sane way to work around this. The real solution would be to add an API for object state change notifications. In the meantime, I would say: forget about it.forgotten, but: https://github.com/pure-data/pure-data/issues/1275 https://github.com/pure-data/pure-data/issues/1275
while we're at it, any reason why not to have a "set" method for [send~] and [catch~]? Seems inconsistent
Em seg., 1 de mar. de 2021 às 22:43, Christof Ressi info@christofressi.com escreveu:
while we're at it, any reason why not to have a "set" method for [send~] and [catch~]? Seems inconsistent
For the same reason why you can't set the name of [delwrite~]
I see, I got confused and thought we were supposed to also set the name for it.
-
Alexandre Torres Porres -
Christof Ressi -
Sebastian Shader