@raynovich said:

When doing audio processing, a few milliseconds error can cause a digital click. I was worried that the digital processing would be compromised. As I am looking into granular synthesis, it is a bit overwhelming figuring out how to make granular synthesis work without creating lots of problems.

Avoiding clicks in granular synthesis is mainly a matter of applying a windowing envelope to every grain. If every grain ramps up from silence and back down to silence, then there is never a sudden transition.

Just the other week, I demonstrated in a class a way to do that: each grain runs a line~ from 0 to 1 and this splits to two places:

1. Map this normalized range onto the desired range of samples to pay back, and tabread4~ the source.

2. Map the normalized range onto another table containing a Hann window, and tabread4~ that.

3. Multiply, and... a clean, windowed grain.

hjh

hjh

@jameslo Sorry for the confusion. I am not the well-versed in the language to be clear. When doing audio processing, a few milliseconds error can cause a digital click. I was worried that the digital processing would be compromised. As I am looking into granular synthesis, it is a bit overwhelming figuring out how to make granular synthesis work without creating lots of problems.

G09.pitchshift.pd as I understand it is emulating an even older hat in audio tech, namely the rotary tape head pitch shifter. Explanation here: https://valhalladsp.com/2010/05/04/pitch-shifters-pre-digital/

It just so happens that this technique is a subset of what you can do with granular synthesis- and the digital implementation is using some of the same tricks as granular synthesis (splicing, window fading, etc). So your observation is correct in the same way as "A radio tuner is a filter".

Hello again,
I am looking ast G09.pitchshift.pd and am failing to see the exact differences between this and granular synthesis. Is it merely an implementation of granular synthesis?

granular.zip

So I've been using some version of this patch (the main patch is gs.pd) for a while now for Granular Synthesis using audio files and it works well. I've adapted it here to take live input that continually refreshes (cf. the upper right of gs.pd), and it works, but sometimes there are random snaps in the sound. If I had to speculate as to what is causing this, I'd imagine it's the buffer changing in a part that is currently being read, but I'm not sure how to confirm this, or even what I'd do about it if I could. The heart of the synthesis is in grain-stream.pd, three of which are in [pd 3streams in the mid-lower-left of gs.pd. Any ideas? Maybe have it alternate reading into two buffers and have the grain-stream read only from the buffer that's currently not being written to? Sounds like that'd be tricky to coordinate timing-wise though.

Hello all,
I am trying to make a granular synthesis operation and have an idea to make it more precise but do not know how to do a few things. Hoping someone can help.

I want to make a granular synthesis object that can play grains in a wide variety of ways. So what was my new concept?

Record the audio that I am going to manipulate.four times sampling rate faster if possible. then play it four times slower which would bring it down four 2 octaves of course. My thought was that I would record at a 44100 * 4 = 176400 sampling rate. Then play the file at 44100 sampling rate. Which would play it down 2 octaves, but the files would not be "grainy.."

Then I could use the granular synthesis operation to play each grain 4x faster which would bring the file back up to speed but would play the sound 4x longer in duration. Does this make sense?

This is coming up because there is too much distortion when I play the file 4x slower and then use granular synthesis to bring the speed back up.

OK, so I tried to use:

writesf~

With the rate changed to 176400. This does not seem to work.

I wrote it like this:

writesf~ -rate 176400

But that did not seem to work. So, I just am thinking, can you use sampling rate higher than set by preferences?

@whale-av

It is often forgotten that [metro] is the Pd metronome and it will take beat length messages though not quite as "musically" as quant for TempoClock.

The limitation there is that it necessarily enforces a certain time granularity. (Though, modular sequencers have the same limitation.)

In SC, you can schedule for any floating-point time, on or off a grid. A [metro]-driven clock in Pd could calculate an offset from the preceding grid line; if the granularity is tight enough, it would be reasonably accurate even through moderate tempo changes.

So bars and beats can be sent separately with two tied [metro] clocks or one and a counter.

Or take the modular "clock divider" approach (wherein, after a night's sleep, I see that I messed up the connections out of the [select 1] but I won't bother to fix the screenshot ).

hjh

@raynovich technically, yours is a polynomial function. It would be an exponential function if the input was used as the exponent of some constant, like {mtof].

I've only used Hann windows in 2 circumstances: as an FFT windowing function, and for granular synthesis. In the FFT case, the Hann window allows you to overlap each window by a factor of 4 so there are no discontinuities in the inverse transform. In granular synthesis, I've noticed that the Hann window injects fewer harmonics of the looping frequency so that the tone of the wavetable comes through more. I think there's a mathematical explanation of how that works in that same Miller Puckette book.

I'm sure there are other uses I don't know about, maybe someone more knowledgeable can chime in.

@g.arj I am sure it is not exactly what you wish but there should be a few clues in there.
I have added recording to the patch...... Microsound-granular-record.pd
I don't have any headphones at the moment so I am not sure what it does when you start to record again.
I get some feedback....... but it is probably a lot worse.
In fact it might be easier to do with two recordings each with a [delwrite~] [delread~] pair looping and an additional [delread~] randomly accessing the delay line..
David.

@g.arj Something like this although it has no audio input...... but I am sure that could be easily added.
Write over the table when you want a new sample. I am a bit brain dead today and not shure straight away how to resize the table for a recording but that can be done too.
Microsound-granular.pd
Pretty sure it's Vanilla.
Take a look at Katja's SliceJockey too........ http://www.katjaas.nl/slicejockey/slicejockey.html
Was Pd Extended........ but I think someone said on this forum that it can work in Vanilla.
Google is your friend.
David.