Merge module - Primary versus Core

arachnaut · 2022-10-13T06:49:01+00:00

There was an error rendering this rich post.

arachnaut

I was always confused by the differences between Core and Primary Merge modules.

So about a year ago I made a test ensemble that would show various properties and how they differ.

I used 3 different streams at adjustable rates to send events to Core and Primary 3 input merges.

I'm not sure I ever figured things out, but maybe this will help others.

Turn Reaktor OFF to stop the clock and see the counters.

Merge macro analysis.rar

Find more posts tagged with

Reaktor Building

Comments

Paule

In primary the Merge have one function.

In core are more than one function (different merge modules).

colB

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.

arachnaut

I guess the attempt in Core to achieve simultaneity is the reason for the results to differ. Or maybe there is a logic flaw in that analysis ensemble.

Either way, this makes my head hurt.

Paule

Colin, your description is about blue one (Merge)

The other one is Event Merge

In core are more than one function (different merge modules).

colB

https://community.native-instruments.com/discussion/comment/35724#Comment_35724

The OP was about Merge, not Event Merge, which is a different module and wasn't mentioned. There is no Primary version of Event Merge anyway, so a comparison of that functionality would not be possible.

colB

https://community.native-instruments.com/discussion/comment/35712#Comment_35712

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.

arachnaut

One could see the wiring order displayed in one of the menu selections of Reaktor if necessary, I didn't think that would be important here.

I do want the A to E Perms to be as random as possible and I don't care which order they occur in, I just want the same sequence of events to arrive at both merges.

I guess that is not happening here even though I thought I was handling that.

Thank you for spending the time to look over this and provide a thoughtful analysis.

An example of what would be a need for such a thing is if one were to analyze a keyboard chord played by a human and wanted to get the first key hit in the chord. It is unlikely that all keys would be hit at precisely the same instant, whether deliberate or not.

I wanted to see if Core or Primary would agree.

colB

https://community.native-instruments.com/discussion/comment/35856#Comment_35856

One could see the wiring order displayed in one of the menu selections of Reaktor if necessary, I didn't think that would be important here.

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

I wanted to see if Core or Primary would agree.

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.

arachnaut

I made the test complicated because I am dumb. I found things confusing so I tried to test what I did not understand. I just got more confused.

Thank you for always trying to explain things to me over the years.

colB

https://community.native-instruments.com/discussion/comment/35973#Comment_35973

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

Studiowaves

https://community.native-instruments.com/discussion/comment/35712#Comment_35712

Core can be difficult to learn. Sometimes it can be like a game of chess. I picked up on it pretty fast but I was also into electronics before hand. It's all a logical process. I think early on like in Reaktor 4 everything was high level and core was introduced in version 5 or something. It seems most likely that core has always been there and the devs made core so they could make the primary macro's. So you're definitely diving deeper by using core and yes, it will give you a headache mainly because primary was made for the majority of users. I'm glad they included core, once you get the hang of it, there's a lot you can do. I will say that primary modules don't always sync up with core so expect hassles. It's pretty easy to use core modules in a core cell but it does take some learning.

arachnaut

Actually, it is chemotherapy that makes things difficult for me right now. My memory is shot from all the drugs and treatments I have been taking since 7/2021.

arachnaut

REAKTOR 4 out now!

https://www.burningoc.de/reaktor

Paule

Is there no trademark on the software Reaktor?

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

Quick links

Unanswered questions