In Pd of course, anyone?
looking for velvet noise generator
I gave it a shot using zexy relationals, might be more efficient using other externals (hence "pure")
edit: realized I didn't need one of the
edit2: now I realize there is also the possibility of missed periods in the case that the
[phasor~]wraps around to a value higher than the
edit3: 3rd time's the charm? used another
[rzero~]to put a 1 in there when the
why do you have a reset phase input for phasor~?
what do you mean by "make sure there is at least 1 1 on wraparound"?
this can be easily made 100% vanilla with expr~
although I see the implementation, I still don't really know how a velvet noise generator is defined so I can check this patch's implementation and maybe think of alternatives, can you help?
@porres oh yeah I always forget about
[expr~]for some reason.. maybe bc of the license it used to have.
There's no real reason to have the phase reset inlet, just more control.
From what I can tell, velvet noise is outputting a 1-sample impulse of value that's either 1 or -1, chosen randomly, at a random point in a regular period.
So I have a
[phasor~]to keep track of the period, and the
[samphold~]samples a random value from 0-1 when the
[phasor~]resets. This will be the point in the phase of that period that the impulse will occur. When the
[phasor~]gets to above or equal to this value, the
[<~ ]will go from 1 to 0. That goes into
[rzero~ 1], which will put out a -1 on the sample that occurs. That goes into the
[==~ -1], which acts (together with
[*~ ]) as a gate for the noise value that has been manipulated to either be 1 or -1, depending on if the output of
[noise~]is positive or not.
The issue with this original implementation was that when the
[phasor~]wraps around to start a new phase, it can wrap to a value greater than the new
[samphold~]value from the noise. That means that if the noise value is very small, there will be no impulse for that period since the
[phasor~]value will never be less than the sampled noise value for that period (and therefore the
[<~ ]won't go from 1 to 0, which means the
[rzero~ 1]below it won't output a -1, and so on). So, the
[<~ 0]put out a 1-sample value of 1 when the
[phasor~]wraps around, which is combined with the other signal in
[min~ 1]to take care of this. That way the
[rzero~ 1]below the
[min~ 1]will get a 1 even if the wrapped-around
[phasor~]value is less than the new sampled noise value, and there will be an impulse for that period.
(that is what "make sure there is at least 1 1 on wraparound" means)
edit: after writing all of this it occurred to me that the sampled noise value could also be greater than the value that the
[phasor~]will get to before it wraps around.. perhaps the solution is to constrain the sampled noise value depending on the frequency and phase of the
@porres the user's explanation for the basis of that patch doesn't seem to fit what is described in this paper: https://www.researchgate.net/publication/260701331_A_Perceptual_Study_on_Velvet_Noise_and_Its_Variants_at_Different_Pulse_Densities
but it seems like there are a few different types of velvet noise. The original seems to be 1 impulse (chosen to be randomly either 1 or -1) randomly placed in time within a regular period. (which is not what the above patch does)
that's not to say it might not be a different type though, I only looked at the original
@porres the first version I posted is what is described in that paper. If you look at figure 1a you can see that there is 1 impulse randomly placed within a regular interval (which is shown by the red dashed lines in the figure).