Hi,

I've built a granular synth for time stretching in real-time within a specified array size. I've looked at a series of examples of the forum and various tutorials and I have put together the following. I've also implemented some functions based on the Echoplex loop station (replace). While the system works well for the most part, I'm not satisfied with the variable grain size in real-time. It still seems to produce a lot of unwanted clicks regardless of the grain amplitude window.

I'm wondering how I may improve the variable grain size function with minimal clicks when utilised in real-time.

Thanks to .mmb with his help with this, thus far. Any suggestions and or feedback on how I may improve this engine would be greatly appreciated.

Best,

Ricky

http://www.pdpatchrepo.info/hurleur/rg_grain~.pd

I presumed Lead meant that he was no longer displaying the waveform at all? Maybe not?

I did. It might not be the key issue, but it solved a clicking/glitching problem (for me) as per the patch I posted earlier.
I added a canvas that changes size to show the size of the sample taken, as a sort of substitute length indicator.

I was thinking of simply using a horizontal slider instead. I have no real desire to see the waveform.

@lead said:

I added a canvas that changes size to show the size of the sample taken, as a sort of substitute length indicator.

Which is very cool, I may add!

@.mmb said:

In that case, you could just use [vline~] to do it. Just make sure you sync it to the block boundary with [bang~].

Sorry for the delay. Here is my rather clumsy but functional fade abstraction synced with [bang~]. Feedback would be most welcome.

Ricky

http://www.pdpatchrepo.info/hurleur/ricky.fade.pd

.mmb's much less convoluted version!

http://www.pdpatchrepo.info/hurleur/fade.mmb.pd

Particle Chamber by Derek Holzer:
http://macumbista.net/?page_id=514%20%28ParticleChamber%29

I hate to bring up this old chestnut but I came across an idea that Robert Henke utilises to record and read audio for his Monolake abstraction in Max for Live and thought it might be useful to someone at some point in developing a patch in Pure Data. Essentially, as I understand it, the patch is reading between multiple record buffers to avoid clicks on playback. Smart, no?:

"We check if desired freeze position is in first or second half of buffer pointer. if in second half, we use alternatively buffer 0 and 1. If in first half, we instead freeze buffer 2 or 3 which is shifted by 50% in the Buffer sub-patcher. In this case we also shift the read out pointer by 50% to stay in sync with the shifted buffers. We do this, because we read out the buffers with the play~ object. The interpolation inside play~ cannot deal with a discontinuous pointer. If the desired playback position happens to be at the very beginning of the buffer, the grain would 'jump' back to the very end. This would cause a click. by switching between the buffers, we always get a buffer that stores at least half of the buffer size in a continuous section. This implies that with a buffer of 4000ms we can move the playback position 2000ms in the past without click, regardless of the captured buffer point."

>>The interpolation inside play~ cannot deal with a discontinuous pointer.<<

sorry, i don't know max; but it sounds like play~ is equivalent roughly to tabread4~ ?

if that's the case, then why do they need a whole new buffer to stop interpolation errors? wouldn't an extra 3 samples of buffer at the start and end be enough???