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

have a look at this patch

http://www.timvets.net/video/grains.php?page=software

Hi Arif,

Thanks. I've spoken with Tim about his patch. Perhaps I will revisit it, although I'm still keen to hear what suggestions anyone might have WRT utilising variable amplitude windows when changing grain size in real-time.

Ricky

Hi Ricky - here is a granular synth patch with variable grain size that doesn't click - the window is formed directly off the [phasor~] and there is a [samphold~] after the input that changes the window size. I just quickly redid the recorder (I had it set up to work with foot pedals) it takes input from a microphone. I think it is still ok. You might have to move the startpoint slider to get things moving at first.
Simon

the trade off for the click is a temporary pitch shift until the new window value is passed through. There is a fairly simple way around it if you only have a single voice, but with 4 out of phase voices it gets more complicated. With a single voice you can find the phase of the [phasor~] that is driving the pitch using [expr~ $v1 < 0.5] then [edge~] ... this is hopeless ... I'll do it as an attachment ... I'm not sure how clear this is, but here it is

I've been banging my head around about this, and I've finally got it! What I did was I got rid of the [phasor~] -> [wrap~] set up and replaced them with two [vline~]s being controlled by a [metro]. Doing it this way, you can update the grain size of each grain independently at the start of the grain. And, there's no pitch-shifting artifacts, which is what I kept getting before.

I've attached a modified version of the one I posted earlier, because it's a little easier for me to understand. ;-p Hopefully you can incorporate it into your patch.

http://www.pdpatchrepo.info/hurleur/timestretch-vline.mmb.pd

banging my head too - came up with this - it's not perfect but it shows what I was trying to explain. No pitch shift or clicks, but 4 phasers that need to have their phases set - they seem to move out of sinc as their rates are updated - it's too late for me to really tell. Maelstorm, I'll look at your patch tomorrow.

You guys are all kinds of awesome. Thank you. I'll have a look at this today and get back to you.

this is Maelstorm's [vline~] idea put into my patch - you can control pitch, speed, grain size, read point, and chunk size (how much of the sample is read.) It all seems to work, but that is without much testing. I'm still finding the end of the line segment with [expr~ $v1 < 0.5]
|
[edge~] I'd be happy to find another method.
The playhead is kind of useless. It's a bit of a mess - I hope it's clear enough to follow.
Simon

I've been playing around with this a bit - when I really drop the pitch and alter the grain size the edge detection seems to be failing - also possibly the sample and hold - back to getting some crackles and the spigots in the selector subpatch have failed to open - it can make a hell of a racket though.

yeah - the samphold~ that is following the grainsize fails at around 5 hz (0, 1 in >= 200 ms)

Simon2, I don't have time to really look at your patch right now, but I've found that [edge~] isn't reliable in all situations, particularly when you need sample accuracy. It conforms to block boundaries, so if there is an edge in the middle of the block, it will bang at the beginning of the next block, not the middle like it should. Also, it seems to have a hard limit of a minimum of 64 samples, so even if you try [block~ 1], it still won't work ([bang~] is like that, too...kind of wish that would get fixed).

Basically what I'm saying is, if you can find a way to replace [edge~] with [samphold~], do it.

I'd have to look at your patch to see what the problem is with [samphold~] not working in your situation, but 200 ms is pretty big for a grain size, anyway.

thanks Maelstorm - I was able to replace [edge~] with a delay of the grain size which then bangs a [1( to open the [spigot] - (I think that is actually what is in your patch) - and all other problems went away. The long grain times are just to get pitches transposed way down. Up next is some kind of feedback.

Simon

http://www.pdpatchrepo.info/hurleur/gran_exp_6.pd

Simon, some very interesting ideas in your patch(es). Great work. Thanks .mmb for your help once more. I much prefer working with a grain size in ms, for composition purposes, it seems a lot more friendly. I'm going to incorporate some of these ideas into my patch and I'll be sure to upload it to this thread once I'm done. Cheers.

R

I think a relationship could be established between speed, pitch, and grain size - grain size needs to increase as speed decreases and decrease as speed increases in order to avoid weird artifacts (I keep having to draw it out.) This could all be adjusted automatically. At very slow rates the number of out of phase voices becomes an issue - I currently have a patch running with 8 tunable voices, as the speed decreases they start to modulate each other (sounds like ring modulation) - even 2 voices produces the same sound, it is just less pronounced. Again, with Maelstorm's vline~ idea it is very easy to change the number of voices - just change the number being sent to the mod object.
Wish I could spend more time on this...
Simon

With the [phasor~] based pitch-shifter, the grain sizes are inversely proportional to the speed. So twice as fast means half the grain size. Probably a good place to start.

@Maelstorm said:

I've attached a modified version of the one I posted earlier, because it's a little easier for me to understand. ;-p Hopefully you can incorporate it into your patch.

There's been a couple of great sounding patches in this thread, looking forward to hearing more!

Hope this isn't a thread hijack, but I've been looking for a granular engine to use when sampling then playing-along with musicians, so the above version that's pitch steady has been a great starting point so far.

Made this quick one attached as a sort of front end (excuse the crudeness in parts of it).

A bit like a beat slicer - it records a bar/length/phrase from incoming audio/musician/instrument and then use its duration to create subdivisions that could be bashed out/tapped along in time to the music to create phrases.
You can also let it run in a loop, randomly or scrub through these subdivided settings.

I've let the selection process be powered by random objects for the most part, as I'm still looking for inexpensive ways to make it "playable", whilst trying to avoid creating an analysis controlled effect or a sequenced beat slicer.

Any input at all welcome, particularly with the tap-along and phrase building ideas. I think my one only really sounds any good with short <1 second samples so far... Up to about "_This_bu" (you'll see what I mean).

http://www.pdpatchrepo.info/hurleur/timestretch-vlineWTD3b.pd

@Maelstorm said:

Hopefully you can incorporate it into your patch.

And I did. A great approach, perhaps I'm being a tad perfectionist, but I still experience clicks when decreasing grain size to in and around 200ms.

I've included some improved functions, including an octave shift, and replace function (based on the replace function of the Gibson Echoplex). I hope to get around to implementing variable array size, as demonstrated in Simons patch.

@Simon said:

yeah - the samphold~ that is following the grainsize fails at around 5 hz (0, 1 in >= 200 ms)

Perhaps this is what I am experiencing WRT clicks.

I tried changing the [tabread~ window.array] to the following [cos~] approach (see attached) which seemed to reduce clicks in and around a threshold grain size of 200 ms, but not completely.

A Theory

Is it possible that the amplitude window is being updated before the grain reader? This may be why I am only experiencing clicks when decreasing in grain size.

Math Question

Apologies for my mathematical ignorance but I am not sure I understand the concept of "fmod" and how it improves this engine? Would you mind explaining to me?
As far as I understand the equation reads as;

[expr~ fmod(vline 0-1) * (grain.size * 44.1 + sample.pos), (arraysize)]

Best,

Ricky

http://www.pdpatchrepo.info/hurleur/rg_grain2.pd

@ricky said:

And I did. A great approach, perhaps I'm being a tad perfectionist, but I still experience clicks when decreasing grain size to in and around 200ms.

Okay, I think the problem is because I fucked up with the [spigot]/[delay] part. The output of [0( should go in the right inlet of [spigot], not [delay]. The output of [spigot] should be what goes into [delay]. I updated my post above to reflect that.

I tried changing the [tabread~ window.array] to the following [cos~] approach (see attached) which seemed to reduce clicks in and around a threshold grain size of 200 ms, but not completely.

You know your window is inverted, which means the phases are all inverted?

Maybe it's just me, but I think the raised cosine window sounds much better than the hann window here.

Apologies for my mathematical ignorance but I am not sure I understand the concept of "fmod" and how it improves this engine? Would you mind explaining to me?

fmod is a floating-point modulo. In [expr~], it's like using [wrap~], except it doesn't have to be restricted to 0-1. Here, I'm using so that when a grain reads off the end of a sample, it wraps around to the beginning of the sample.

Thanks for the quick response. I've made the [spigot] fixes, but I do not perceive any change from before. Are you getting everything click free at your end? How quickly are you changing the grain size?

@.mmb said:

You know your window is inverted, which means the phases are all inverted?

Do you mean the hann window;

[sig~ 1]
|
| [cos~]
| |
[-~]
|
[*~ 0.5]

Does this cause an issue?

I learned the construct from here: http://www.pd-tutorial.com/english/patches/3-7-2-2-granular-live-feedback.pd

@.mmb said:

Maybe it's just me, but I think the raised cosine window sounds much better than the hann window here.

Re: Cosine versus Hann. The raised cosine producing a lot more clicks for me (even with your patch), which is the only reason I looked to the Johannes Kreidler approach. It just sounds better to me (less clicks).

Well, looking at it again, I was wrong about the grain envelope being inverted. But I can't see why you'd get less clicks with it. I just find it to sound more like amplitude modulation. It sounds more grainy.

I'm not getting clicks with my patch, and I found that if I load in one of my samples, I don't get clicks with yours. Maybe the issue is with how you're recording them? Have you tried loading prefab samples?

There are clicks at the wrap-around point. You could add a declicking envelope synced with [r sample.pos], or just destructively add it as you record.

Well, the issue may very well lie with how I am recording it. The problem is that I want to work with live audio, so prefab samples are not an option.

@.mmb said:

There are clicks at the wrap-around point. You could add a declicking envelope synced with [r sample.pos], or just destructively add it as you record.

This sounds like an excellent idea, would it work just like a regular amplitude window? Ideally, I'd like to apply the window as the audio is written to the array. So, maybe something like the following;

[adc~] [tabread~ env]
| |
| _ _ |
[*~]

I'm not sure this would work, at the very least I hope it would give you an indication of what I'd like to do. Any suggestions would be greatly appreciated. Thanks!

Best,

Ricky

@ricky said:

Well, the issue may very well lie with how I am recording it. The problem is that I want to work with live audio, so prefab samples are not an option.

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

Ideally, I'd like to apply the window as the audio is written to the array.

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