hi frank...
I added a [r sync-waende-vertikal-rec]->[print] and as hard as I try, there are only zeros coming into this. I would rule out, that the toggle is getting a 1 anywhere. Also when I remove the internal receiver and connect the [r sync-waende-vertikal-rec] to the toggle, I never get a 1. Which is natural, as there are only [0('s connected to everything that evaluates to "sync-waende-vertikal-rec". The only thing that *could* get a 1 outside a toggle is "sync-waende-mittei-rec" and "sync-waende-mitte-rec"
please don't explain the syntax of toggle or the _language_ pd!
just add a |r sync-waende-vertikal-send|->|print| and in parse_sync2_1 behind the |r $1-send| another print object ... (to make shure, do this in a running patch, don't save the abstraction)
inside the abstraction you will receive a |1( message from sync-waende-vertikal-send
Other than that I still do not fully understand the flow of logic in that patch, which "feels" to be more complicated than it would have to be. At least the argument count of [sync/parse_sync1_12] makes me think: this is too much. (One would probably never write a C function which requires 13 arguments...)
in fact, this patch _is_ more complicated ... i broke this out of a more complicated patch ... i deleted a huge stuff to make track down the problem ... and to make shure, there is not some kind of error, coming from somewhere else in the patch!!!
if you follow the logic of the abstraction, (parse_sync2_1) you will see, that if the second argument's send is 1 and $1-send (from the tgl), a message |0( will be sent to $1-rec (to the tgl). this will send the |0( to $1-send ... but there is the problem! ... the last message arriving at $1-sen is a |1(
cheers ... tim