Precaution: As long as the feedback loop volume is at [*~ 0.99] or below, it'll be fine, but it's worth putting [clip~ -1.0 1.0] right before the [dac~] for extra safety! [clip~ -1.0 1.0] will act as a limiter. For more info about that object, I recommend watching this video: ruclips.net/video/jeovwEExuXI/видео.html Update: For most application, it'll be better to use [vd~] instead of [delread~]. This will prevent the clicking noise when you change the delay time!! So, replace your [delread~ delayname1 500] with [vd~ delayname1]. And connect [number] -> [message that says $1 10] -> [line~] to the inlet of [vd~]. Everything else will be the same as the video!
Too busy at the moment to put everything in practice but I enjoyed the video and am sure this will be very valuable tools for me in the near future. Thanks for all your efforts to create these videos!
So excited to get started with all this. One thing that occurs to me - is it possible to wrap the dac object in another object that automatically and always includes the [clip~ -0.9 0.9] (say [safedac~])? That way I wouldn't forget and blow something up.
I'm not sure I understand the logic behind pure data's flow of data. At 3:50, there are two inputs into delwrite, one from noise and one from delread. It _looks_ like this would add noise~ * .75 + delread~ * .95 and write it to the delay, but based on the played audio and your description, it _sounds_ like it should write the noise~ * .75 only until delread starts reading, then it will write only the output of delread~ * .95. But if so, why does it do that? How does puredata decide that once delread starts outputting, it should "prefer" its inlet to delwrite over the inlet from noise, since noise should also be constantly outputting?
The delay feedback loop is constantly happening but we don't hear it since there's an amplitude control ([*~] connected to [line], which should be [line~] btw) right before the [dac~]
@@ShotgunLlama [delwrite] is both the noise and the fedback noise simultaneously. The raw noise playing at the same time as the fedback noise with short delay time is what's creating this karplus-strong/comb-filtered sound. .. I recommend putting that [*~] & [line~] envelope between the [noise] and [delwrite~]. It should sound pretty much the same (there might be a longer tail end though). The key is to move objects around to see how everything works :)
Precaution: As long as the feedback loop volume is at [*~ 0.99] or below, it'll be fine, but it's worth putting [clip~ -1.0 1.0] right before the [dac~] for extra safety! [clip~ -1.0 1.0] will act as a limiter.
For more info about that object, I recommend watching this video: ruclips.net/video/jeovwEExuXI/видео.html
Update: For most application, it'll be better to use [vd~] instead of [delread~]. This will prevent the clicking noise when you change the delay time!!
So, replace your [delread~ delayname1 500] with [vd~ delayname1]. And connect [number] -> [message that says $1 10] -> [line~] to the inlet of [vd~]. Everything else will be the same as the video!
Thank you for the video! Helps me a lot in my Pd beginners struggles
Glad it's helpful! Thank you for watching!!
Too busy at the moment to put everything in practice but I enjoyed the video and am sure this will be very valuable tools for me in the near future. Thanks for all your efforts to create these videos!
Thank you as always for watching! These videos will be waiting when you have the time!!
This video is wow good work 👍 thank you
Thank you so much for the kind words! I greatly appreciate it!!
So excited to get started with all this. One thing that occurs to me - is it possible to wrap the dac object in another object that automatically and always includes the [clip~ -0.9 0.9] (say [safedac~])? That way I wouldn't forget and blow something up.
Thanks a lot!!!
I'm not sure I understand the logic behind pure data's flow of data. At 3:50, there are two inputs into delwrite, one from noise and one from delread. It _looks_ like this would add noise~ * .75 + delread~ * .95 and write it to the delay, but based on the played audio and your description, it _sounds_ like it should write the noise~ * .75 only until delread starts reading, then it will write only the output of delread~ * .95. But if so, why does it do that? How does puredata decide that once delread starts outputting, it should "prefer" its inlet to delwrite over the inlet from noise, since noise should also be constantly outputting?
The delay feedback loop is constantly happening but we don't hear it since there's an amplitude control ([*~] connected to [line], which should be [line~] btw) right before the [dac~]
@@SoundSimulator My question is more like how does the [delwrite] decide whether it writes the output from [noise] or [delread]?
@@ShotgunLlama [delwrite] is both the noise and the fedback noise simultaneously. The raw noise playing at the same time as the fedback noise with short delay time is what's creating this karplus-strong/comb-filtered sound.
.. I recommend putting that [*~] & [line~] envelope between the [noise] and [delwrite~]. It should sound pretty much the same (there might be a longer tail end though). The key is to move objects around to see how everything works :)
@@SoundSimulator so is delwrite writing the sum of the noise plus the feedback at all times?