Enabling the wire debugging tool will also clock and latch a modulation macro's a input.

When you enable wire debugging, it also latches the current value at the a input of this modulation macro all by itself. This produces false wire readings which are confusing.

Who else thinks it should be fixed. I feel we shouldn't have a debugger that interferes with the logic as in this example.

Talking about the wire debugger above.

Find more posts tagged with

Reaktor 6

Comments

colB

Something you don't understand happens and you react by publicly reporting that Reaktor is faulty... every time!

There is no bug here.

Studiowaves

Lol, you crack me up. I know the debugger reinitializes things but others may not. And it's true that it can confuse someone who doesn't know it does. So if you have two panel knobs connected to the A and X inputs of the modulation macro and move one knob that changes the A input, nothing happens until the other knob is moved which clocks the A value into the latch. Yet when you engage wire debugging, it sends the new A value waiting to be clocked right into the latch because the wire debugger latched it, not the panel know connected to the X input. So in essence, the wire debugger gives you a false reading. It should read the output of the multiplier with the value currently in the latch. So in effect, it's wrong.

colB

So in effect, it's wrong.

It does exactly what it should.

You know there is a re-initialisation in this situation (think it through and you will realise that there must be). You know that some elements generate events during initialisations, so you know what happens, and that it is exactly what should happen. And yet you are framing it as a problem by suggesting it should be 'fixed'.

Why not just write code that does what you want, instead of writing code that doesn't, and complaining?

Quick links

Unanswered questions