Hi. I'm trying to find an object or a method of operating to be able to essentially do what togedge does but with signals. Any thoughts or ideas would be greatly appreciated. Thanks!

You can use [clip~] to create signal rate comparators/triggers like this:

You can modify this to check for as close to zero as you like (limit here being 2^-32), by running your signal through [abs~] and setting the float to your desired limit value.

This does however not output any bangs. 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. 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]

@jenkutler
The helpfile of [cyclone/togegde~] doesn't work here, but I replicated it's behavior in signalrate like this:

togedge~2b.pd

If you want strictly ints, you can add a signalrate [int] like this:

@bocanegra said:

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]

Much later edit: the following is actually wrong, - it is even more complicated (((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.))))
EDIT: edited

@jenkutler I don't know exactly why, but this also seems to work, although the order of the bangs is switched:

togedge~.pd

@lacuna said:

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~].

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

Many control-rate objects operate 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.

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? Also a 1 sample delay is easily ameliorated by compensation, i.e. [rzero_rev~ 0]

@ingox brilliant as always but we still have the problem of DSP block delay. I believe some stress-testing is in order

Probably useless and inefficient, but this does also detect something (not sure if 64 samples means array length 64):

togedge2~.pd

@bocanegra said:

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. )
much later edit: the following in brackets is actually wrong
((([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~].

Also see this post:
https://forum.pdpatchrepo.info/topic/11615/bang-bug-when-block-1-1-1-bang-on-every-sample

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.

Two more attempts that are probably too expensive but with similar results as the others i proposed:

togedge3~.pd

togedge4~.pd

@jenkutler The cyclone library has a few signal rate objects that find crossings.
[edge~] is probably closest to [togedge].
To synchronise a zero crossing to a control event [zerox~] can be fed into [edge~].
For more accuracy [zeropos~] will give the number of the sample within a block when the event occurred.... and the direction of travel........ but of course you still only receive the message once the block has processed.
Their help files will give some more information.
David.

An irritant with threshold~ -- the upper and lower bounds are always exclusive rather than inclusive. The left outlet bangs when the signal was >= lower_bound and becomes < lower_bound; the right outlet bangs when the signal was <= upper_bound and becomes > upper_bound.

The current implementation is, of course, valid for many use cases. But detecting 1 or 0 state in a signal strikes me as a fairly common requirement -- and threshold can't do it 100% precisely! (Unless you go look up the exact smallest float > 0, and the exact largest float < 1.0.) I'm not clear why this untidy approach is more desirable than simply defining the trigger condition as signal <= lower, or >= higher.

hjh