That's why there's a float margin you can set yourself in the patch i proposed. I have to admit the one sample delay differential detector is neat tho
That margin makes it slightly imprecise, and doesn't replicate [togedge].
And again, there are even zerocrossings in a pulse-wave with an amplitude of -1 and 1
(Sorry for being pettifogging.)
Good point. And a cause of a great deal of frustration too >.< - We can only speculate as to what OP is looking to control, but if it's a [vline~] fade in / out I think that would be sample accurate?
(I was slow: edited my other post while you where writing. )
[vline~] only can start in one of the following blocks, after it has been receiving a message.
This message can contain a delay for starting a ramp within a block, but the actual message will be send in between block boundaries of 64 samples only.
(For sample-accurancy with at least one block of 64 samples latency you could fill a buffer with [tabsend~], then [bang~] parse the array and compose a message for [vline~] by calculating the timing with the sampleposition and [samplerate~]. )
Here is another slide, unfortunately in German: https://iaem.at/kurse/ss19/iaa/pdscheduler.pdf/view
My confusion has been the misleading documentaion and tutorials I learned beforehand,
PD's scheduler is actually very clear.
The helpfile of [cyclone/togegde~] doesn't work here, but I replicated it's behavior in signalrate like this:
If you want strictly ints, you can add a signalrate [int] like this:
The logical output is signal rate (which can be very useful). If you want bangs look into [threshold~]. You should be able to set that up as a zero crossing detector.
I don't know about [threshold~] never used it, but my example above is not suitable as zerocrossing detector, as the chance of a sample being actually 0 at zero-crossing is very small!
Detecting zero-'crossing' would be a transition from postive to negative or vice versa, or to zero. There is also [zerox~].
The DSP block size will affect the accuracy of the timing though so if you need a bang exactly when your signal crosses zero, you will need to do [block~ 1]
Message-handling happens in 64-sample periods, only. You can't change that. Even if [threshold~] would go down to 1 sample (still one sample late), the following message-chain won't.
while (xdotool search --name "window name"); do
Yes, this looks like "pinging" a window.
There might be a way to "catch" the OS' closing message, too?
I think about a PD implementation:
sounds like an idea!?
Hard to tell the best way, without being into your specific environment and requirements. More ideas:
A scheduler in your python main loop
Or have a look at [hcs/tkconsole] and [hcs/sys_gui] with a deep dive into TCL / TK:
poll open windows:
winfo children .
doesn't receive anything when closing other patches or abstractions.
Seems like closing is handled on the OS side. You might need to monitor window closing messages on the OS side (I don't know how yet), and communicate towards PD via [netreceive] or [ggee/shell] ....
Maybe you have more luck asking such a question in the mailing-list.