I've been building some simple things and learning my way around PD vanilla. All in all it's a very nice system especially for free.

One thing that isn't working is creating windows for granular and FFT processing. I follow the exact patching from the tutorials that are included in the documentation. These things usually rely on "loadbang" for writing a single cycle of cosine to a table, buffer, etc. When I set this up I always still have to have to draw the table by hand. The filtering that I'm doing is working just fine, but I'm curious what I'm doing wrong. I've added a manual "bang" to write the table, calculate the size, etc, as well, but no luck. Usually I end up with nothing in the table.

I've had the same issue with granular synthesis. Even if I use a cos~ table that's offset and driven by a phasor~ I get clicks out the wahoo. This has happened even when just opening full patches that were made by the guy who wrote the software.

Anyhow. I'm finding workarounds for everything anyway, so hopefully things won't stay weird. It just seems like my system is acting screwy. I'm happy to try anything at this point as I'm looking forward to setting up my spare rPi as a standalone host for pd. Right now I'm just diddling around on my old 3930k windows 7 system so I don't get too carried away when I start trying to move things over to the Pi.

Thanks for any help,

JJ

@raynovich Loading a file into soundfiler takes time and so the table cannot be read correctly until it is written.
I don't really know what "granular" means for everyone, but made this Microsound-granular.pd a while ago, and it might help.
The file size stays the same and speed can be varied by a message to [phasor~] before [tabread4~].
It loads just one audio file and the arrays remain "whole"...... it is just the playback head that is moved and there is no "-resize" once it is loaded.
The playback head is moved all the time by a [metro] but before the move the sound is "ducked" by a message to [vline~] and then brought back up just after the move of the playback head to avoid clicks.

If you have lots of separate tracks loading with [soundfiler] you could join them together in one long track and access them by playback positions within the long track.
You will still have your problem though if you load a new audio file into the arrays and I don't know any way around that..... except that you could crossfade between old and new arrays once the new one has loaded..
David.

@Cmaj7 Maybe you should zip up your whole patch (without sound files) and upload it to this thread.
I think you have a problem we will not find without the whole picture.
But try this patch first....... Microsound-granular.pd ..... as it is also reading from arrays (onscreen) and softening crossovers with a short fade down and back up again (duck)....... and maybe your problem is not the speed of the duck but when the duck occurs........ it needs to start before the crossover and be at zero already at the crossover point.

So the crossover needs to be delayed slightly...... the duck needs to know it is about to happen a few milliseconds earlier...... 5ms in the above patch....... see the "granular" part in the middle.
The delay will not affect your musical timing noticeably...... 5ms is like moving 5 feet away from your speakers..... or being 5 feet from another player in the band.
David.

Yes but the point here being that digital granular synthesis does a lot of other things controlled by you: time stretching, jumbling up grains at your will, reverse playback and whatnot - the pitch shifter uses grains, delays and windows for one single purpose: shifting pitch

If you are doing a full fledged granular synth in PD the patch in question provides some basic technique,s but not as useful as you might think as it is designed for pitch shifting only. Pay attention to what @ddw_music told you in the other thread: https://forum.pdpatchrepo.info/topic/13489/realtime-detecting-lack-of-correct-delay-in-the-delay-object/11

Another note: Granular synthesis works with pre-recorded samples, whereas the pitch shifter is real time pitching

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