Pulse getting lost in program

[gweimer]

Is this a bug? Program seems to be dropping pulses.

As you can see from the counters, the pulse gets to the 2nd max-buffer, but never goes beyond that. I would assume programing error, except it is the same node that works in one case, but not in an identical use case.

The max-buffer code simply takes PUSH pulse, defers it, then passes it to DONE, so I don’t see how it could be lost through error or similar issue.

I was having the same issue with 0.34.?, but upgrading to 0.35.2 didn’t help. Same issue in simulation and upload to UNO.

[danya]

Hello. I removed the defer from the max-buffer. It seems to work.

[gweimer]

That’s…disconcerting… Besides being just wrong that defer would drop a pulse completely, that “fix” means that DONE will likely pulse before NEW gets updated…

[danya]

The defer is needed in order to create cycles, isn’t it? Why use defer in max buffer at all? There seems to be no feedback, everything goes sequentially and without cycles.
I decided to make logic out of defers. Here’s what it gives me:

Everything works exactly until the third defer. This is really strange.

[danya]

I decided to put the delays between defers, for a very short time. And everything worked.

[gweimer]

The current buffer value does loop back to the top of the patch, so defer should be used there. Without a defer before DONE, this results in DONE pulse before MEM is updated, which is not a problem in this example where MEM is just tied to watch node, but would be a problem if DONE triggered an action using MEM value. In this case, the buffer defer could be moved after the from-bus-OUT, but without defer on pulse wire, there is still the chance that DONE will pulse before MEM is updated.

Good thought to narrow the problem down to just pulse passing through 3 defer nodes without all the extra code.

[cesars]

A bridge from input to output produces a defer, I pass with the nodes of output-self.

if the implementation is in C ++ …

emitValue <output_OUT> (ctx, getValue<input_IN> (ctx)); 

no delay occurs.

[gweimer]

I think you are saying a link from input node to output node in XOD code has an implied defer node, so manually adding defer is not needed. That provides a long-term work-around for my code, but doesn’t fix the problem that a chain of 3 defer nodes will lose a pulse as demonstrated by @danya code above.

[cesars]

the defer(pulse) node has an implementation for error detection, could that be it? I have not tried with previous versions

[gweimer]

If there were an error in defer, wouldn’t the node turn red in debug mode?

What could cause an error in defer??? has-error doesn’t seem to work with pulse as input.

[cesars]

There would not be an error, but when checking if there is an error to pass it to the next node, it happens that the pulse is lost after the 3rd cycle. Is what i believe

[evgenykochetkov]

Hi everyone.

Yes, this is a bug. After looking at the generated code, I discovered that nodes are evaluated in the following order:

The first defer in chain is executed last, and because of that is able to pass a pulse only to the next one.

While I am working on the fix, the temporary solution would be creating a custom node that delays a pulse until the next transaction, something like

node {
    void evaluate(Context ctx) {
        if (isInputDirty<input_IN>(ctx)) {
            setTimeout(ctx, 0);
        }

        if (isTimedOut(ctx)) {
            emitValue<output_OUT>(ctx, 1);
        }
    }
}