nickdesigner

I'm currently working on a granular synth patch, and I was getting pitch shifting when I changed the grain size (which was changing the frequency of a phasor~ that was reading through the sound file) As you will see in the patch below, on the left, I put the values into a float object, and only pushed the values through when the phasor hit 0.

But now I'm getting zipper noise, so I was going to try eliminating the data objects and just go with audio signals, but my example on the right, isn't working. Can anyone help me understand why it isn't working.. or if this would even solve the zipper noise that I'm getting?

I'm currently working on a granular synth patch, and I was getting pitch shifting when I changed the grain size (which was changing the frequency of a phasor~ that was reading through the sound file)  As you will see in the patch below, on the left, I put the values into a float object, and only pushed the values through when the phasor hit 0.

But now I'm getting zipper noise, so I was going to try eliminating the data objects and just go with audio signals, but my example on the right, isn't working.  Can anyone help me understand why it isn't working.. or if this would even solve the zipper noise that I'm getting?


using-msp-objects-to-trigger-events

Save the first patch as [fb~] in your abstractions folder.

The primary reason your second example doesn't work is the feedback loop. You can't do this without manually forcing 1 signal vector of delay in the loop - do this with send~/receive~.

The primary reason your second example doesn't work is the feedback loop.  You can't do this without manually forcing 1 signal vector of delay in the loop - do this with send~/receive~.


Thanks - this reduced the zipper noise greatly! I'm still getting a little though.

I'm using two of the wait~ objects, one to update the grain size (via phasor~ freq) an the other to update the start sample for the grain.

I got a lot more zipper noise when I ran the fb~ delayed ramp into the wait~ for the start sample than I did if I just ran the initial ramp into it. This leads me to think that it obviously needs to know where to read to and from before the 'read-thru' ramp begins. but even with this I'm still getting some zipper noise when the grains are small. 

Thanks - this reduced the zipper noise greatly!  I'm still getting a little though.  

I'm using two of the wait~ objects, one to update the grain size (via phasor~ freq) an the other to update the start sample for the grain.  

I got a lot more zipper noise when I ran the fb~ delayed ramp into the wait~ for the start sample than I did if I just ran the initial ramp into it.  This leads me to think that it obviously needs to know where to read to and from before the 'read-thru' ramp begins.  but even with this I'm still getting some zipper noise when the grains are small.  


I haven't looked at this patch yet nickdesigner, so feel free to diss me, but I'd be happy to share 'my own' stable and flexible granulator - which btw is built on much of Tim's contributions:

http://www.youtube.com/watch?v=QPNBPFAUDoM

(guaranteed click/artefact-free, thanks to TL)

(guaranteed click/artefact-free, thanks to TL)
Brendan


This granulator looks great! do you have a download for it? I'm not sure what the 'computer music' etiquette is, but I'd love to see under the hood at how you used the phase-synced overlapping windows and all-pass filtering.

This granulator looks great!  do you have a download for it?  I'm not sure what the 'computer music' etiquette is, but I'd love to see under the hood at how you used the phase-synced overlapping windows and all-pass filtering.

Sure, no problem (zip below). Essentially, it utilizes a central [phasor~] ramp to drive a [play~] object; this is time-shifted by 50% to a second [play~] object. Any user input passes through a [sah~] first, to avoid interruption of the central ramp. Most of the foregoing algorithm is the result of forum pounding and comes mainly from people like Tim, and also (if memory serves) Volker Boehm, Luke Hall and Alex Harker amongst others. The 'unique' element is the way I overcame unintentional pitch variation while changing grain size: this isn't a problem when using a single phasor/play pair, but occurs when using two synced pairs. My solution is to fix the grain size and add a user-defined offset to the noise element; this allows variation of the grain 'range' rather than size but kind of has the same effect, blah blah blah, here it is

Sure, no problem (zip below). Essentially, it utilizes a central [phasor~] ramp to drive a [play~] object; this is  time-shifted by 50% to a second [play~] object. Any user input passes through a [sah~] first, to avoid interruption of the central ramp. Most of the foregoing algorithm is the result of forum pounding and comes mainly from people like Tim, and also (if memory serves) Volker Boehm, Luke Hall and Alex Harker amongst others. The 'unique' element is the way I overcame unintentional pitch variation while changing grain size: this isn't a problem when using a single phasor/play pair, but occurs when using two synced pairs. My solution is to fix the grain size and add a user-defined offset to the noise element; this allows variation of the grain 'range' rather than size but kind of has the same effect, blah blah blah, here it is

the allpass filtering idea came from reading somewhere that it helps to blur or smear transients, while also passing all frequencies; it was implemented through trial and error, rather than through hard math(s)....some may think it's overkill.

this guy has some very quick, simple and effective phase-shifting/syncing ideas:

http://www.youtube.com/watch?v=uyzY_ZP54pA

Thanks so much for your help. And thanks for sending me your granular patch Brendan - I've referred to it many times.

I'm getting a nasty bug when my grains are very large (around 20 seconds). I want this patch to be able to go between granular effects and layered playback effects, so I want the grains to be able to be very small and very large.

the problem I'm getting now is aliasing when the grains are large - it sounds like sample reduction. There is a number of things that I've started to suspect to be the cause. At the foundation, it must be a phasor reading from start sample to end sample, and either the sample specifications are wrong or the phasor~ ramp's slope is wrong.

Thanks so much for your help.  And thanks for sending me your granular patch Brendan - I've referred to it many times.

I'm getting a nasty bug when my grains are very large (around 20 seconds).  I want this patch to be able to go between granular effects and layered playback effects, so I want the grains to be able to be very small and very large.

the problem I'm getting now is aliasing when the grains are large - it sounds like sample reduction. There is a number of things that I've started to suspect to be the cause.  At the foundation, it must be a phasor reading from start sample to end sample, and either the sample specifications are wrong or the phasor~ ramp's slope is wrong.  

Here is a zipped folder of an example. You'll have to go to 'tables' and replace the default sound file.

I'm wondering if its the math I'm doing for pitch shifting.

or maybe the feedback loop - that 32 sample delay?

Here is a zipped folder of an example.  You'll have to go to 'tables' and replace the default sound file.

or maybe the feedback loop - that 32 sample delay?


So a friend of mine informed me on what I was doing wrong - when using phasor~ to read through an index, the grains can only be so long. If you try to read through 20 seconds of audio using phasor~ then there aren't enough values in the ramp (from 0 to 1) to cover the millions of samples its reading through, so I starts to average samples and you get sample reduction.

I have another related question, which I started a new post for.

https://cycling74.com/forums/how-to-best-sync-phasor-objects-for-granular-synthesis

So a friend of mine informed me on what I was doing wrong - when using phasor~ to read through an index, the grains can only be so long.  If you try to read through 20 seconds of audio using phasor~ then there aren't enough values in the ramp (from 0 to 1) to cover the millions of samples its reading through, so I starts to average samples and you get sample reduction.  

https://cycling74.com/forums/how-to-best-sync-phasor-objects-for-granular-synthesis
Nick


using MSP objects to trigger events