Merge module - Primary versus Core

Core merges do exactly what Primary merges do - but there is an additional input state in core that cannot occur in Primary - there is a very simple extra rule to handle the additional input state

Here's a breakdown:

PRIMARY:

two possible input states to consider:-------------------------------------

no input at any port -> no output

an input event at a single port -> the event passes to the output

CORE:

three possible input states to consider:---------------------------------------

no input at any port -> no output

an event at a single port -> that event passes to the output

two or more simultaneous* input events -> the active event at the lowest (visually) input port passes to the output (others are discarded)

* Simultaneity in this case is 'logical'. This input state is impossible in Primary with it's depth first event model. The actual behind the scenes implementation may or may not be simultaneous, but the 'meaning' is - in core, events that share the same source event are treated as simultaneous events. This requires a 'tie breaker' for merge because we can only have one output. None of this detail matters in terms of understanding what merges 'do', just those simple rules based on input state.

Colin, your description is about blue one (Merge)

The other one is Event Merge

I think that if you want to examine possible differences between the merges of Primary and Core, you will have to use a different approach.

The reason for the behaviour in your structure is nothing to do with core and all to do with how difficult it is to understand what's going on in a seemingly simple Primary structure.

First of all, you have three A to E Perm. modules. How do we know which of those will send out an event first? they all internally divide down the audio clock. We have no access to that process, and cannot explicitly control which will send an event first. So how do we know what order the events arrive at the merge testing modules?

Worse is that there are six wires directly from the outputs of the A to E Perm. modules. The order that these are active is arbitrary, the order that Primary uses being based seemingly on the order they were connected... at least sometimes.

To prove all of this to yourself, put an order module after each A to E Perm., to guarantee that the order here is always the same (can't so easily fix the other ordering issue), then replace each of the core cell with copies of the primary version. Comparing identical Primary merges in this manner shows the same/similar behaviour as comparing Primary to Core, demonstrating that the test harness is as fault...

This doesn't prove that the core and primary merges are identical, but it doesn't prove otherwise either - you need a different approach.

For fun, try doing this without the order modules, then randomly remove and reconnect wired between the A to E perms and the merges. just doing this can change the behaviour, proving that the meaning of the code is dependent on the invisible order in which the structure wires were connected. This is one of the many reasons a lot of folk steer clear of Primary. These problems do not exist in core.

What I also found was that if I swap out a core merge for a primary one, then use 2x undo and redo to swap back and forth (CTRL+Z / CTRL+Y). Sometimes they seem very similar, and sometimes not - one or the other changes - at least based on the numeric outputs you have set up. Not sure if this is related to arbitrary wire order, or different synchronisation in the A to E Perm modules relating to the audio clock and the event processes being asynchronous.

If the meaning of the code changing is not important, then ok ?!

They will agree if you send them the same thing. If they don't then the test is faulty, or you have found a bug (unlikely, because this is a fundamental construct in both Primary and Core, so if it was buggy we would know for sure).

Why did you make the test so complicated? It seems to me that for something like this, you would want the simplest possible test, and use something like ACEW to analyse the results. Then you run a test using a Primary merge, and a test using a core merge, and compare the results.

Trying to compare event streams in real time in primary using nulling is gonna be difficult, you will need extra support structures for ordering and storing results, because of the depth first event model in Primary. For nulling to work, the results need to arrive simultaneously, and that is not possible in Primary. You can sometimes fudge it with more order based tricks. An extra output on the bottom of the order module that is used to trigger value modules on all the other outputs, so they are only used when they have all been updated... still needs very careful handling. Funny that this problem doesn't even exist in core ;)

You could maybe do some sort of non real-time test by populating an array of some kind for each merge, then running an iteration to compare the results in the array. Then all you need to do is ensure that both really to receive an exactly equivalent input event stream, something your test does not guarantee because of the three separate A to E processes, and the way they are all wired up.

You're not dumb, just stubborn. Keep being stubborn ;)

Is there no trademark on the software Reaktor?

If yes they have to rename their REAKTOR CPU at once!