On Wed, 2022-03-16 at 14:34 +0000, Jeppi Jeppi wrote:
Hi there, I assume this has been discussed many times before but...what could be simplest and most concise way to detect a phase reset of a phasor~ with only plain vanilla objects? I only need one bang when it goes back to 0. It seems I should need snapshot~ and fexpr~ which is not that elegant...
Instead of detecting the phase reset of a real [phasor~] object, you could emulate a phasor~-like object with [vline~] and [metro~]. This would automatically give you bang with _precise_ timing.
Compared to the [vline~] based phasor~, detecting a real phase reset of a [phasor~] has two drawbacks:
boundaries and thus not very precise and thus not suitable for a higher frequncy phasor.
Nevertheless, I think it could be done with a handful of objects. Delay the [phasor~] signal by one sample and subtract the undelayed signal from it. The result is a signal that is usually slightly below zero and has one-sample-peaks close to 1 each time the phase resets. You then feed that to a block-sized table with [tabsend~]. On each block, you check the table with [array max] for the highest value. Actually, since the non-phase-reset samples should be below zero, anything above zero can be considered a phase-reset. Of course, you need to trigger [array max] every block with [bang~]. Filter out any values below zero and consider the index for all values above zero. The index tells you how much time passed since the last block boundary. You could convert the index value to ms and feed it to a [delay]. The result are bangs that correspond exactly with the phase resets. However, they are one block late, because you can only analyze a block of audio data _after_ it has been computed.
I hope what I said makes sense and I did not make any mistakes. I haven't actually tested it yet.
Ah, I should not forget to mention: [array max] detects only one peak. So this approach works only for phasor~ frequencies up to samplerate/blocksize (689 Hz @ 44.1k | 64 bs).
Roman