Re: [PD] phasor~ phase reset detection
As mentioned, If you need a phasor~ with bangs, create a [metro] at the bang speed, and run [vline~] on each bang to generate a signal. [metro 500] | [f 500] <--- fill your metro speed here. | [0, 1 $1( | [vline~] You can then just take the bangs from the metro. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] Re: phasor~ phase reset detection
Here's how I like to do it these days: [phasor~] | [expr~ $v1 < 0.5] | [snapshot~] (with [bang~] | [change] | [sel 1] | BANG! If you need it to be sample accurate, you can set [block~ 1]. Even better if you can keep it all in the signal domain and skip the [snapshot~], but it depends on your purpose. Sam > Content-Type: text/plain; charset="iso-8859-1" > > 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... > -- next part -- > An HTML attachment was scrubbed... > URL: < > http://lists.puredata.info/pipermail/pd-list/attachments/20220316/37d4b25a/attachment-0001.htm > > > > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Choices of IPC when using fast-forward
On Wed, 2022-03-16 at 16:00 -0500, Charles Z Henry wrote: > > other: is there a good way to start/stop processes other than > [ggee/shell]? cross-platform? There is [command] which works on Linux and macOS, but not on Windows. Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] Choices of IPC when using fast-forward
mid-March 2022: I'm finally getting back to normal and returning to projects I was working on before the pandemic. 2 years of shifting priorities... ya know The project I was working towards is doing long-length cross-covariance and deconvolution calculations in a "fast-forward" pd instance and then passing the results back to a real-time process, with minimal risk to real-time A pd process that is running in fast forward does not poll and so does not listen for connections of some kinds. When fast forward is turned off by the patch, it starts using the regular scheduler and starts listening again. At the time, 2 years ago, I had gotten this kind of behavior from batch mode and communication through shmem and some signal handlers (raisestop, sigcont). With [ggee/shell] to start/stop the processes and send sigcont, it rounded out an (linux-specific, and very kludgey) solution. A batch mode process could wake up, read some shmem ID's and be told what to do, transfer data in, do some calculations, write the output to other shmem ID's, and then sleep again. To make the programming a bit easier to read, it was also possible to send lists using FUDI over shmem. My conclusion there was that shmem can be used for asynchronous inter-process communication with minimal risk to real-time. It's very good as a fundamental object--it does not block, it does not synchronize. Notable limitations: 1. Every process needs to know/use the same size for shmem ID's. 2. Once allocated, a shmem cannot be re-sized. 3. Writing to/from an extremely large array all at once poses a risk to real-time. I'd like to write a pair of management abstractions for using fast forward and shmem, then, that make it easy to stage in/out large, variable-length data Anybody else have best practices for IPC when using fast forward? Having a listener on the 2nd process between computing sprints in the "fast forward" process completely changes how I can do things. other: is there a good way to start/stop processes other than [ggee/shell]? cross-platform? Chuck ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ phase reset detection
On Wed, 2022-03-16 at 14:34 +, 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: * converting from signal to message adds 1 block latency * depending on how you generate the bangs, they are tied to block 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 signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ phase reset detection
How about [threshold~ 0.5 10 0.5 10]? The right outlet will output a bang whenever [phasor~] resets its phase. Not sure if its arguments need more fine tuning. On 16/3/22 16:34, 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... ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] phasor~ phase reset detection
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... ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
