In Pd of course, anyone?

@porres in my version I added controls for period regularity and polarity bias.
Setting period regularity to '0' constrains the random phase range and polarity bias controls the offset of the noise that chooses the polarity (copysign)
so if you set the regularity to 0 and polarity bias to 1 you get a (aliased) regular pulse train

@seb-harmonik.ar said:

@porres in my version I added controls for period regularity and polarity bias.
Setting period regularity to '0' constrains the random phase range and polarity bias controls the offset of the noise that chooses the polarity (copysign)
so if you set the regularity to 0 and polarity bias to 1 you get a (aliased) regular pulse train

I did not get any of this sorry... what is any of it good for? can you try and ellaborate?

you mean like you can choose how much of it is positive or negative?

that'd be easy with the probability parameter of [chance~] but I don't see any benefit in that.

@porres said:

[...] Haven't tested my patch like that, could you do that too @ben.wes?

... since it's based on the same logic of the randomly offset phasor crossing 1, it also sometimes misses impulses, yes (checked with ~3000Hz):

as far as i can see, all versions here potentially drop impulses? feels like this shouldn't be hard to solve - but i don't see how, i admit. and i probably also should check the previous versions in more detail to really understand them!

another simple approach is this, where i'm trying to detect the significant wrapping for each cycle. this also leads to some dropped impulses - but it also adds some ...

patch: velvet~.pd

... since it's based on the same logic of the randomly offset phasor crossing 1, it also sometimes misses impulses, yes (checked with ~3000Hz):

that's gotta be really rare and only if the random chosen number is stupidly low... basically zero!

@porres said:

that's gotta be really rare and only if the random chosen number is stupidly low... basically zero!

... not that rare depending on the phasor frequency and sample rate. for example: with a 3kHz phasor at 48kHz sample rate, the value of the phasor will increase by 0.0625 per sample (3000 / 48000). so in this case, for ~6% of the cycles, the value won't cross 1 (if the offset is below these 0.0625), since the phasor will already wrap when > 0.9375.

not sure if this is a good explanation and completely valid - i'll wait for others to confirm or correct me.

hmm, yeah, I hadn't checked the values, well, I'm now thinking it makes better sense to set the above value randomly

@manuels said:

By multiplying the frequency with 1/SR you get the phase increment of the phasor. Since there is exactly one sample in each cycle where the sum of the current phase and the increment gets bigger (or equal to) 1, you get the impulse. Now all you have to do is to randomize the phase to get the impulse at a random position.

Just realised, that I didn't consider one important thing here: If the period isn't an integer number of samples, then the method of adding a random number and wrap doesn't work anymore!

yeah, it can't get simpler than this, I guess it can be more sophisticated, to never miss a period, but I also think this is a job for a C code.

I need to make [pimp~] multichannel, then I will also adapt it to become [velvet~} and it'll also be multichannel, meaning it can receive a multichannel signal to set different frequencies and it'll output a multichannel signal with independent impulse generators.

[else/dust~] and [else/dust2~] are already multichannel, so [velvet~] must also be to follow suit

I'm releasing ELSE RC12 soon, this will hopefully be part of the next RC13 update

@porres said:

to never miss a period, but I also think this is a job for a C code.

To atone for my earlier SC jibe, here's a delay-based approach. (Also, indeed you're right -- I hadn't read the thread carefully enough. Dust / Dust2 don't implement exactly "one pulse per regular time interval, randomly placed within each interval.")

velvet-noise-2.pd

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.

It looks to me in the graphs like there is exactly one nonzero sample per phasor~ cycle.

hjh

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

(
a = { |density = 2500|
    // var pulse = Impulse.ar(density);
    // for similarity to Pd graphs, I'll phasor it
    // but the Impulse is sufficient for the subsequent logic
    var phasor = LFSaw.ar(density);
    var pulse = HPZ1.ar(phasor) < 0;
    var delayTime = TRand.ar(0, density.reciprocal - SampleDur.ir, pulse);
    var rand = TRand.ar(-1, 1, pulse).sign;
    [DelayN.ar(rand * pulse, 0.2, delayTime), phasor]
}.plot;
)

@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