In Pd of course, anyone?

what I don't get is why you need to add to a multiplication of the frequency and the sample rate period, can you explain that @seb-harmonik.ar ?

New ELSE version

Just a single noise source, no [expr~] and no copysign, which might be expensive and also the way I'm doing it now has "real zeros". I was very annoyned that the other version had a bunch of "-0" (minus zeros) values!

@porres Ah, now I see the problem ... (so I'll try to explain anyway)

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.

I'll have to take a look at your new version ... (Still I don't think the noise scaling and [+~ 0.5] are necessary.)

Edit: Just noticed that you have ">" instead of ">=" in the [op~].

new version, seems more elegant to just use [pimp~] and use it to trigger a random number generator

Ok, a much simpler approach now, I believe.

Never liked using the samplerate to add an increment, and wrap~ and everything, so what we need is just being able to catch the transition above 1 and make it an impulse out of it, so [op~ >= 1] into [status~] solves that!

damn, I have so many tools in ELSE that generates impulses that even myself can forget what is the best to use sometimes. It turns out I just need [above~] for this... and [chance~] also needs seeding

@porres said:

Never liked using the samplerate to add an increment, and wrap~ and everything, so what we need is just being able to catch the transition above 1 and make it an impulse out of it, so [op~ >= 1] into [status~] solves that!

Well, it may not be nice, but it was my attempt to solve the problem of missing periods (see further up in the thread). If you have a phasor cycle of, say, 0.1 - 0.3 - 0.5 - 0.7 - 0.9 - 0.1 - etc., then adding small random values to it won't give you any transition above 1.

Edit: ... and the critical case of a cycle 0 - 0.2 - 0.4 - 0.6 - 0.8 - 0 - etc. may illustrate why you need >= instead of > in the [op~].

FWIW I think in SuperCollider this would all be just Dust2.ar(density).sign where density is the average number of pulses per second. (Edited from Dust.ar -- Dust is positive only; Dust2 is positive or negative.)

hjh

@ddw_music Shall I ban @ddw_music for blatant promotion of SuperCollider on this forum....?
Just joking....
David.

@ddw_music I mentioned about dust, I have ported both to ELSE, but the density parameter is kina bogus and doesn't behave like the algorithm we're working on here, and I like the way velvet~ works better by the way, it's less random.

And beware of getting banned!!!

@manuels said:

Well, it may not be nice, but it was my attempt to solve the problem of missing periods (see further up in the thread). If you have a phasor cycle of, say, 0.1 - 0.3 - 0.5 - 0.7 - 0.9 - 0.1 - etc., then adding small random values to it won't give you any transition above 1.

Edit: ... and the critical case of a cycle 0 - 0.2 - 0.4 - 0.6 - 0.8 - 0 - etc. may illustrate why you need >= instead of > in the [op~].

I know you needed it for the vanilla implementation, but I thought I could have a simpler and more elegant solution with the ELSE objects

this doesn't add any new concepts and in case of a samphold~ value of 0, it will not cross 0 - so it's certainly missing a few impulses as stated by @manuels ... but besides that, i wonder if i'm missing anything with this simple approach?

(in this case with ELSE's zerocross~ for upward-crossing detection - but a vanilla option would also be possible with 3 more objects iirc)

EDIT: patch: velvet~.pd
EDIT2: ... and a noise value of 0 will not have a sign to copy in this case via x/abs(x), but result in a factor of 0 - so it will obviously prevent an impulse output. and if you know about the efficiency of (x+1)/2 vs. x*0.5+0.5, let me know.
EDIT3: i guess that the /~ 2 is not a good idea here ... i saw in the past that pow~ is quite a bit faster with integer arguments - but i also saw that *~ is faster than /~. and although i don't know much about the details going on there, i assume that float division won't profit much from an integer divisor ... anyway, this is getting a bit off-topic.

@ben.wes Beat me to it...
David.

@ben.wes just fyi, * is more efficient than /
I believe pow is less efficient than either but haven't checked

@seb-harmonik.ar said:

* is more efficient than /

yep, that's certainly true, thanks! - had measured this in the past as well (and commented above). i was just naively thinking that it might make a difference whether the argument is an int or float (which is the case for pow ... [pow 2] is faster than [pow 2.01] for example). but this thought doesn't make any sense here.

I think some of these have the same issue as my original implementation - if the generated random phase is less than a sample increment and the phase wraps around it will never be bumped to above 1.
e.g. at 1/4 sample rate samples would be 0, 0.25, 0.5, and 0.75. if generated random value is >=0 and < 0.25 no value will go above 1
edit: @ben.wes not sure but everything in pd is a float
edit2: similarly we have to think about cases where random phase is between 1-(sample increment) and 1. Because it could bump the generated values to always be above 1 in cases where the phase wrap around of phasor~ doesn't start at 0. (in which case there would be no transition either)

@seb-harmonik.ar said:

if the generated random phase is less than a sample increment and the phase wraps around, it will never be bumped to above 1

certainly true in my case, yes - there are missing impulses:

@ben.wes As I understand velvet there have to be missing impulses as it should be more sparsely populated than white noise. It's a question of how sparse maybe, but certainly that the sparseness cannot be regular and produce a psychoacoustic audible tone......
.... maybe....
David.