@.mmb said:

Of course. But you can at least find out if that's the problem or not.

Apologies, I thought that was implicit in my response. However, I'm glad you said that because since making the spigot fixes manually, I never looked at your second patch (thoroughly) until now, and I notice you have a [vline~] at the grain size going in to the fmod [expr~], which was not in your first patch, and it seems to make a difference? Perhaps not, I don't know that I can trust my ears this late at night. I loaded up a sample in the second patch and yes, no clicks unless I changing the grain size quickly around 1 - 10ms.

I've just tried recording in live audio into your second patch, and it sounds grand to my ears. The issue with my live source is that of the length of the guitar tones (I probably need a bigger array) and the attack of the note, but also, I'm pushing my CPU very hard with 6/7 instances of this granular synth, so I presume that could also be producing artifacts?

I would like to work on smoothing out the live audio.

@.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~].

Are there any tutorials on this? I must confess, I'm not clear on how you mean to use [bang~]. Cheers.

Ricky

@ricky said:

I'm pushing my CPU very hard with 6/7 instances of this granular synth, so I presume that could also be producing artifacts?

That'll do it! Is this running your guitar analytical patch at the same time? I switched to tables from arrays displaying the input and that cleared things up.

@ricky said:

@.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~].

Are there any tutorials on this? I must confess, I'm not clear on how you mean to use [bang~]. Cheers.

Ricky

bang~ sends a bang at the end of each dsp cycle, so I guess he's saying use it to sync the fade in/fade out window that you're overlaying on the incoming audio, to stop clicks each time it starts over.

Thanks Lead. It might look a lot tidier without having the arrays displayed too. I'll get on that later this week. Thanks for the info on bang~. I'll post a new engine later this week hopefully with fade tables for recording a sample and the replace function. Thanks for your help.

where is the difference between tables and arrays when you use them to display things?
i always thought its almost the same thing just with a little bit different startparameters

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???