Hey list,I'm tearing my hair out trying to re-write the wrap~ object, so that it doesn't wrap instantly but waits until the end of the audio block to wrap~ the signal. I hope you understand. This is so that control-rate messages sent to another object further down the signal-path have a chance to catch up, and eliminate clicks due to the end-of-block delay for control messages. The idea is that wrap_overshoot~ will not wrap until the end of the block. This is a really tech-y problem, but I've tried variables and clocks. Everything seems to segfault on me. ?????Lots of love,Ed PS if this works you'll all be able to use it during and after pdcon16~
Hi Ed, The prototype of your perform method is wrong. You should have something like: static t_int *wrap_overshoot_tilde_perform(t_int *w) { t_wrap_overshoot_tilde *x = (t_wrap_overshoot_tilde *)(w[1]); t_sample *in = (t_sample *)(w[2]); t_sample *out = (t_sample *)(w[3]); t_int n = (t_int)(w[4]); ... return w+5; }
and the dsp_add method should be called like this: dsp_add((t_perfroutine)wrap_overshoot_tilde_perform, 4, (t_int)x, (t_int)sp[ 0]->s_vec, (t_int)sp[1]->s_vec, (t_int)sp[0]->s_n);
About what you want to do, I would like to help but I'm not sure to understand. I understand that you want that your object performs at the end of the DSP chain (end of the audio block) on a signal that should be computed previously in the DSP chain but as we all know only the Matthew McConaughey from Interstellar has this power :).
Cheers,
Pierre
2016-09-29 12:00 GMT+02:00 Ed Kelly via Pd-dev pd-dev@lists.iem.at:
Hey list, I'm tearing my hair out trying to re-write the wrap~ object, so that it doesn't wrap instantly but waits until the end of the audio block to wrap~ the signal. I hope you understand.
This is so that control-rate messages sent to another object further down the signal-path have a chance to catch up, and eliminate clicks due to the end-of-block delay for control messages.
The idea is that wrap_overshoot~ will not wrap until the end of the block. This is a really tech-y problem, but I've tried variables and clocks. Everything seems to segfault on me.
????? Lots of love, Ed
PS if this works you'll all be able to use it during and after pdcon16~
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Thanks Pierre. Trying it now. This thing doesn't immediately crash or segfault, so I'm onto a winner eventually :) I understand my brain is slightly more dead than it was. But we can move forward now.Cheers,Ed Lone Shark releases: Light Vessel Automatic available now on 12" vinyl.Build Your Wings on the Way Down, the new digital album available @ http://scifirecords.co.uk/releases Earthlings compilation is out now @ http://www.pyramidtransmissions.com
Ninja Jamm - the revolutionary music remix app for iOS and Android: http://www.ninjajamm.com/
Gemnotes-0.2: Live music notation for Pure Data, and Metastudio 5 live composition and improvisation suite, available at http://sharktracks.co.uk/puredata
On Thursday, 29 September 2016, 12:27, Pierre Guillot guillotpierre6@gmail.com wrote:
Hi Ed,The prototype of your perform method is wrong. You should have something like:static t_int *wrap_overshoot_tilde_perform( t_int *w){ t_wrap_overshoot_tilde *x = (t_wrap_overshoot_tilde *)(w[1]); t_sample *in = (t_sample *)(w[2]); t_sample *out = (t_sample *)(w[3]); t_int n = (t_int)(w[4]); ... return w+5;} and the dsp_add method should be called like this:dsp_add((t_perfroutine)wrap_ overshoot_tilde_perform, 4, (t_int)x, (t_int)sp[0]->s_vec, (t_int)sp[1]->s_vec, (t_int)sp[0]->s_n); About what you want to do, I would like to help but I'm not sure to understand. I understand that you want that your object performs at the end of the DSP chain (end of the audio block) on a signal that should be computed previously in the DSP chain but as we all know only the Matthew McConaughey from Interstellar has this power :). Cheers, Pierre 2016-09-29 12:00 GMT+02:00 Ed Kelly via Pd-dev pd-dev@lists.iem.at:
Hey list,I'm tearing my hair out trying to re-write the wrap~ object, so that it doesn't wrap instantly but waits until the end of the audio block to wrap~ the signal. I hope you understand. This is so that control-rate messages sent to another object further down the signal-path have a chance to catch up, and eliminate clicks due to the end-of-block delay for control messages. The idea is that wrap_overshoot~ will not wrap until the end of the block. This is a really tech-y problem, but I've tried variables and clocks. Everything seems to segfault on me. ?????Lots of love,Ed PS if this works you'll all be able to use it during and after pdcon16~
______________________________ _________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/ listinfo/pd-dev
On 2016-09-29 12:00, Ed Kelly via Pd-dev wrote:
Hey list,I'm tearing my hair out trying to re-write the wrap~ object, so that it doesn't wrap instantly but waits until the end of the audio block to wrap~ the signal. I hope you understand.
no (nto trying very hard though).
i'm pretty confident that you are trying to solve the wrong problem.
if you want to delay the signal coming out of [wrap~] for one block, use [delread~]/[delwrite~]. it's all there. nothing's needed to be coded. (using a delay of "0" and order-forcing to make sure that [delwrite~] is handled after [delread~] will give you exactly one block of delay).
if you want to do something else, then it's probably borked by design :-)
gmasdr IOhannes
PS: please do not CC me. please only reply to a single mailinglist.
Nope. It's not one block, but until the end of the current block.The error changes with each reset of the phasor input, so the clicks sound different each time, since they last for a different number of samples. Because the control-rate message doesn't happen until the end of the audio block, the signal has a few samples of +~ before the message arrives.I'm confident I can solve this.Cheers,Ed PS I didn't CC you directly.
Lone Shark releases: Light Vessel Automatic available now on 12" vinyl.Build Your Wings on the Way Down, the new digital album available @ http://scifirecords.co.uk/releases Earthlings compilation is out now @ http://www.pyramidtransmissions.com
Ninja Jamm - the revolutionary music remix app for iOS and Android: http://www.ninjajamm.com/
Gemnotes-0.2: Live music notation for Pure Data, and Metastudio 5 live composition and improvisation suite, available at http://sharktracks.co.uk/puredata
On Thursday, 29 September 2016, 13:40, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2016-09-29 12:00, Ed Kelly via Pd-dev wrote:
Hey list,I'm tearing my hair out trying to re-write the wrap~ object, so that it doesn't wrap instantly but waits until the end of the audio block to wrap~ the signal. I hope you understand.
no (nto trying very hard though).
i'm pretty confident that you are trying to solve the wrong problem.
if you want to delay the signal coming out of [wrap~] for one block, use [delread~]/[delwrite~]. it's all there. nothing's needed to be coded. (using a delay of "0" and order-forcing to make sure that [delwrite~] is handled after [delread~] will give you exactly one block of delay).
if you want to do something else, then it's probably borked by design :-)
gmasdr IOhannes
PS: please do not CC me. please only reply to a single mailinglist.
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 2016-09-29 16:25, Ed Kelly via Pd-dev wrote:
Because the control-rate message doesn't happen until the end of the audio block
but ain't this just wrong? iirc, the control-rate message happens before the audio block.
anyhow, at the end of the audio block, it's too late to do audio processing, because audio processing is already over for this block. so it will only effect the samples of the next block. which is much the same as delaying the signal for one block and then applying any transformation.
the only other wish that might make some sense (from the wisher's perspective) is, that [wrap_offshot~] is forced to be last object in the audio queue. this has some implications, like: what if you have two instances forced to be the last one? how will any objects below that forced-last object (as in: there inlet~s are connected to the forced-last outlet~s) receive their signal in time?
i still do not understand what you are actually trying to achieve and how. i also think that you are not entirely sure in what you are asking for. so let's try some rubber duck debugging: if you manage to explain your problem in simple enough words so others can understand it, we might find a solution (or the problem/approach has evaporated)
gasdr IOhannes
Hey IO, Don't worry, I got it sorted. The right inlet of +~ receiving a control-rate object waits until the end of the block, but the signal is continuous. wrap_overshoot~ waits until the end of the audio block to synchronize with control-rate signals further down the chain. Let's not have a debate now - all will be revealed at my paper presentation in New York in November. See you then,xEd Lone Shark releases: Light Vessel Automatic available now on 12" vinyl.Build Your Wings on the Way Down, the new digital album available @ http://scifirecords.co.uk/releases Earthlings compilation is out now @ http://www.pyramidtransmissions.com
Ninja Jamm - the revolutionary music remix app for iOS and Android: http://www.ninjajamm.com/
Gemnotes-0.2: Live music notation for Pure Data, and Metastudio 5 live composition and improvisation suite, available at http://sharktracks.co.uk/puredata
On Thursday, 29 September 2016, 16:44, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2016-09-29 16:25, Ed Kelly via Pd-dev wrote:
Because the control-rate message doesn't happen until the end of the audio block
but ain't this just wrong? iirc, the control-rate message happens before the audio block.
anyhow, at the end of the audio block, it's too late to do audio processing, because audio processing is already over for this block. so it will only effect the samples of the next block. which is much the same as delaying the signal for one block and then applying any transformation.
the only other wish that might make some sense (from the wisher's perspective) is, that [wrap_offshot~] is forced to be last object in the audio queue. this has some implications, like: what if you have two instances forced to be the last one? how will any objects below that forced-last object (as in: there inlet~s are connected to the forced-last outlet~s) receive their signal in time?
i still do not understand what you are actually trying to achieve and how. i also think that you are not entirely sure in what you are asking for. so let's try some rubber duck debugging: if you manage to explain your problem in simple enough words so others can understand it, we might find a solution (or the problem/approach has evaporated)
gasdr IOhannes
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Ed Kelly -
IOhannes m zmoelnig -
Pierre Guillot