In Pd of course, anyone?

@ddw_music said:

PS FWIW -- one nice convenience in SC is that non-interpolating DelayN doesn't require the delay time to be rounded

I could include a -nointerp flag to del~ so it does that too

@ddw_music you can just use [rint~] or other objects instead of the [trunc~] approach

I do think @manuels original idea of having a sample-increment offset still works without missing periods?
Why don't you think it works with non-integer period lengths?

a phasor~ is always guaranteed to have its last sample be within the last sample increment regardless of whether an integer-period or not, and [wrap~] will pretty much perfectly wrap the phasor~'s phase..

I adapted the delay patch (and made other improvements, removed unnecessary stuff) with more ELSE objects, since it's in plugdata and uses del~ anyway... one can just use [imp~] instead, but [pimp~] is used to print the phase.

I was wondering about this approach and I wonder what happens if the frequency keeps changing drastically at signal rate... my intuition tells me it might go bad!

What I didn't like about this approach is also having a delay limit that limits the lowest frequency possible.

velvet-noise-delay.pd

@porres here's what I mean about adding parameters for bias/regularity
if you set regularity to max and polarity one extreme or the other it's an aliased pulse train
velvet-controls.zip

some of the papers were mentioning it, you can get some cool effects

some of the papers were mentioning it, you can get some cool effects

if they were mentioning, that changes everything and yeah, that's what I thought about the polarity... and the regularity is something I actually find interesting now that I see it...

hmmmm, I guess I can add them too in my version thanks

which papers exactly? can you post them again? I guess it's time to read it

@ddw_music said:

Uses else's del~ because delread~ requires a message-based delay time, which can't update fast enough, and delread4~ interpolates, which smears the impulses. With del~, I could at least round the delay time to an integer number of samples, and AFAICS it then doesn't interpolate.

Actually delread4~ doesn't smear if the delay is always an integer number of samples (which makes sense from the cubic interpolation formula -- if the fractional part of the index is 0, then you just get the sample value at the integer index).

It's easier to ensure an integer-sample delay time using else/del~'s -samps flag

I've definitely not dug deeply enough into ELSE -- so many things that are a PITA in vanilla become straightforward. (I'd have complained a lot less four-five years ago if I had known about this library from the beginning!)

hjh

@porres it's mentioned in the valimaki one I posted above: https://www.researchgate.net/publication/260701331_A_Perceptual_Study_on_Velvet_Noise_and_Its_Variants_at_Different_Pulse_Densities
(novel variants on page 7)
edit: it mentions the 'regularity' but not bias.. I can't remember where that came from, maybe that one wasn't in a paper but it's necessary to make it into a pulse train
or it may have come from a different paper on 'extended velvet noise'.. been a few years

I can't feel any perceptual difference with just positive impulses, for instance....

which makes me ask, what would be the purpose of having also negative impulses? what is it for?

@porres that's quite a philosophical question.. what are the positive ones for?
edit: as a serious answer, I guess anything that's polarity-specific. you could maybe combine multiple generators in different ways?
I guess you could always multiply by -1 but to me it seems more natural to have it go from 1 to -1 since that's the output range of digital audio and it would take extra objects.. easier just to allow negative values

@seb-harmonik.ar said:

I do think @manuels original idea of having a sample-increment offset still works without missing periods?
Why don't you think it works with non-integer period lengths?

a phasor~ is always guaranteed to have its last sample be within the last sample increment regardless of whether an integer-period or not, and [wrap~] will pretty much perfectly wrap the phasor~'s phase..

With non-integer period lengths you have effectively a changing number of samples per period. That in itself I don't think would be a problem, but adding a random value and wrapping the result can give you sample-increments that are either smaller or bigger than the calculated value.

Maybe an extreme example can help to clarify: Consider a period length of 2.5 samples. The sample increment is in this case 0.4. If you have a period with the sample values 0.3 and 0.7, add 0.8 as a random value and wrap, what you get is 0.1 and 0.5, so the last sample doesn't get above 1 when you add the calculated sample-increment of 0.4. Am I missing something?

@ben.wes Did you do the testing with non-integer fractions of your sampling frequency? You mentioned 3kHz at 48kHz SR as an example, which shouldn't make problems ....

@manuels hmm yeah I guess it doesn't quite work due to the phase discontinuities..
maybe have to do a bit more tinkering with the offset/phase reset part
I wonder if it would work to just discard the wrapped around part somehow, and set the limit based on the 'non-fractional' part of the period

@manuels said:

@ben.wes Did you do the testing with non-integer fractions of your sampling frequency? You mentioned 3kHz at 48kHz SR as an example, which shouldn't make problems ....

sorry for the confusion! - it weren't exactly 3kHz, since I'm setting the frequency with a logarithmic slider. tested once more with 3026.2Hz here now (which was probably also the value yesterday). i'm displaying the last 3 outlets here that i added to your patch (additionally offsetting the phasor for visual clarity):

@porres said:

I can't feel any perceptual difference with just positive impulses, for instance....

not sure if i understand correctly ... you mean you don't hear a difference between the mixed impulses and just positive ones?
in that case, you might need to check higher frequencies and tune it louder.

spectrograph~ (with db and log display) for both versions at ~3kHz:

"balanced":

positive only (missing some lower frequencies):

about the purpose: https://acris.aalto.fi/ws/portalfiles/portal/13412521/applsci_07_00483_v2.pdf talks about an application for late reverberation. i didn't completely read it, i admit - but i assume, for that purpose, the impulses should have both polarities.

@ben.wes Thanks! So no surprise that it doesn't work ....

@ben.wes Please don't laugh...... I shouldn't wade into this subject as I do almost no sample-wise work in Pd.
Just applying the rules as I understand them...... regular single sample impulse...... randomly +1 or -1.
I assume that to qualify as an impulse the sample must be followed by a zero.

As [noise~] seems never to output zero it seems to be a good choice for randomising +/-

[phasor~] seems to cause problems at wraparound..... as always.

[vline~] needs control rate input..... and it must be best to stay in the audio thread.

So...? please check this but [print~] produces output consistent with the rules as I understand them.....

I suppose the next stage would be to determine a period and randomly pack with zeros to displace the impulse, if that is really a requirement.
David.
velvety.pd

@whale-av said:

So...? please check this but [print~] produces output consistent with the rules as I understand them.....

i think, you built a version at nyquist frequency!

probably, i should read more into it (no time right now unfortunately) ... i'm not sure if velvet noise needs to meet the requirement of the random position of the impulses in each cycle. obviously, that's not possible anymore when a cycle is just 2 samples.

the idea in the version mostly discussed above is exactly that though: there's one impulse per cycle and this impulse should be placed at a random position in its cycle with random polarity. and the cycles can be of any length (samplerate / frequency).

this graph in https://acris.aalto.fi/ws/portalfiles/portal/13412521/applsci_07_00483_v2.pdf (page 4) is showing that quite well:

EDIT: this brings up an important question though (which is also probably answered in the papers): are consecutive values of 1, 1, 1, -1, -1, -1 or -1, 1 allowed? not sure ... but these wouldn't be actual impulses anymore then, right?

@ben.wes Then I cannot see how [vline~] can be avoided.
I still have no interval adjustment, and have to go out...... but it should be a trivial modification to the [random] argument and a correlated [block~] size.

I would think that writing an external would also be simple.
I had tried using [zexy/dirac~] but it was expensive.

I cant' hear the difference between [velvety-1] previous post) and [velvety-2] but of course if it were used to set reverb delays then the distribution would be important.
David.
velvety-2.pd