Even merge as dummy , for timing correctons ?

Seems odd to me :)

This from two pages before look dodgy to me:

In Primary, ordering of events needs to be tightly controlled. Here, is is left up to Reaktor. That's never a good idea IMO. Maybe this ambiguity created a bug (maybe not*), and the edit involving adding that 'dummy' merge caused the order to be reversed, removing the bug.

Just looks bad to me. It's really just a symptom of Primary, where 'correct' code becomes quickly unreadable due to all the order modules needed to explicitly specify correct event orders.

*It may be that the order of the output ports 'fixes' the ordering issue in this case, but that's a really terrible way to define something as important in a programming environment. I just steer clear of Primary as much as possible.

The one Rule to rule them all in Primary is that each event in turn is propagated to it's ultimate conclusion before other pending events, or any child branches. If that rule is being followed correctly, the merge should make no difference at all.

And there are things Reaktor does better, or are just not possible in Max or Pure Data, or else you would be using those exclusively.

Reality is that every environment has it's strengths and weaknesses. There are always design compromises when developing a complex application… particularly something as complex as a programming language.

Max doesn't do immediate optimised compilation. Reaktor does. That's the killer app for me. I don't know about pure data, does that do instant compilation? The only reason I came to Reaktor was when that was added (core). I crossgraded from sinc modular. AFAIK there still hasn't been another dataflow audio platform that has that feature?

Each time you make an edit in core, it is automatically compiled to binary. Means you can build low level DSP and have it run with reasonable efficiency. As far as I am aware, other dataflow languages are either interpreted like Primary layer, or require extra steps to use a compiler based process.