granulator patch generating strange high frequencies

Hi
no-one can test this as you neglected to include the [grao] patcher.......

Amplitude modulation sidebands or frequency artifacts, in granular synthesis, result from the windowing of the grains (size and shape). Try varying this window to see if the frequencies persist, I believe that angular or hard-knee envelopes are often the cause, whereas curved overlapping grain windows can help alleviate them; also, reduce the number of polyphonic voices when testing too, 100 voices is quite numerous.

Brendan

hi, brendan.

i'm sorry, i forgot to include the patcher! here it goes:

by windowing of the grains you mean the duration of each one of the grains? now it is at 100.

the envelope is made with a line object. do you think that maybe using a groove~ instead of play~ and using the loop sync outlet of it to control the envelope should work better?

thank you!

play~ should be totally fine. Check out the "start" message for play~ if you want to skip the line~ before it. (dunno if there's a savings, but there might be a small one) t

My two cents on granular poly~ patches: I like the actual poly~ voice to be as dumb as possible (as in there's no control/random logic in it, it's just following instructions and playing the grain you provide). This allows you to have multiple streams of grain generators all using the same underlying engine, for instance, which you can't do if the control logic is inside the poly~ voice. You can make a big list using something like this:

pack 2 0. 0.2 0. 100. 0. 0. 0. 0. .... etc. for your various parameters where they map onto things like:
| bufferNumber transposition volume startTime duration pan envelopeShape etc.
| (The bufferNumber parameter is a great place to use a banged itable. (to give weighted probabilities for the different buffers)
|
|
prepend note
|
poly~

You can use zl nth within the poly~ voice to extract individual items. (you can use unpack, but you have to keep track of the positions, and certain values need to arrive before others, so zl nth and t l l l l ... saves you lots of trouble since you can pick and choose)

Here are some very small tweaks that may tighten up the performance for your poly~ voice:

Peter, thank you very much for your suggestions. I was actually using your approach, sending a larger message do the poly~ object and unpacking it. For some reason I can't remember I have changed it, but you are right, it doesn't make much sense. I have reorganized the patch and used a bunch of zl.nth, as you said. I also didn't know about this behavior of line~ with messages like (0, 1 100) and it was really helpful, thank you. I changed the message to control the playback position as you suggested, but to control the envelope I decided to use a curve~, as Brendan suggested.

But to eliminate the high frequency that was being generated, I had to increase the randomness of the playback position (to a window of 100 ms instead of 10ms). It solved the problem, but the result was a drone that was a little "blurry" (that's the best word I could think of). So I created a small expression to control the level and size of the grains: as closer a grain is to the middle of the window, the louder and longer it is. Does it makes sense?

Brendan, I'm still using 100 voices because my metro is set to 1 and the duration of each grain is 100. If the number of the voices is lower, I would get some missing grains. If the metro is higher, the sound is not that rich and I need to narrow the window again, resulting in that high pitched frequency. This allowed me to remove the reverbs.

Here is the new patch:

and this is inside the poly~~

I'm guessing that the high frequency that you were experiencing was comb filtering. If the grains are coming at very regular intervals, you're apt to get comb filtering, especially if the grain parameters are similar. You could also try randomly inverting the phase of some of the grains (* 1. or * -1. for the volumes) to break that up a little more.

You can use more than one metro, each set with a different rate, to generate bangs. (e.g. metro 1, metro 1.17, metro 1.83) You can also only pass x percent of bangs from each, and that will further break up the regularity.

Random phase inversion--clever.
Also check your audio settings- as small an IO vector as possible may help with the combing--also try enabling audio in interrupt and overdrive and see if that helps.

Peter, your suggestions made the patch sound much better! I decided to break the regularity of the metro with a random value at each bang. I have included the random phase inversion (indeed, really clever): the comb filtering is gone and the result is sounding much fuller and denser. I also noticed that now I can reduce the grain window again, and even if I remove the randomness, playing all the grains in order, it sounds perfectly fine - even better when playing some transients - thanks to the phase inversions.

Terry, with those improvements and with a brand new comb-filter-free patch, changing the IO Vector doesn't change the sound. But in the previous versions of the patch my experience was the opposite of what you said: as lower it is, the stranger it sounds. As I said before, this is something that I don't understand quite well. Can you please tell me where I can find more information about vector and buffer sizes? I guess I need to understand it better and study it for a while...

The new patch:

And the poly~

Thank you all!

Glad to hear it's working better. Very small things: you can save a multiply if you multiply the output of curve~ by your gain factor first; also, decide works better than random 2 in terms of uniformity. (decide is essentially random 2 but with an algorithm that's designed for that particular case)

@matheusleston
an explanation of audio vectors etc is here:
https://cycling74.com/docs/max5/tutorials/msp-tut/mspaudioio.html

if you are using metro to trigger an audio process, especially if the timing resolution is close to or below the vector size, then strange things can happen, like metro timing being quantized to the vector size, which could explain your earlier observations.

This thread outlines my recent experience of this problem:
https://cycling74.com/forums/triggering-audio-grains-timing-inaccuracies-how-to-fix