Signature
-
-
seb-harmonik.ar
updated to 0.55-1 on the release page https://github.com/sebshader/pdnext/releases/tag/0.55-1
-
-
seb-harmonik.ar
@hmp did you try opening the zip file I attached? it shows how to use the
[text get]
-
seb-harmonik.ar
@hmp you could hypothetically parse the csv in pd, but it's probably easier to just store the text file in the pd native format, which is just separated by spaces with semicolons at the end of lines
file_example.zip -
seb-harmonik.ar
@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 -
seb-harmonik.ar
@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
@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 -
seb-harmonik.ar
@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.zipsome of the papers were mentioning it, you can get some cool effects
-
seb-harmonik.ar
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..