Reaktor 6.5.0 Crashing Repeatedly When Connecting Wire in Core Macro

This isn't technically a crash. It's what happens when the code is so complex that the compiler takes a very long time to process it. It's a known issue (for many years), and there are ways to work around it. Sometimes you can leave it for 20 or 30 seconds, sometimes for minutes, and it might eventually complete the job. Not really practical though ;)

...in your pic, the first thing to try would be to add a latch before the P output. attach the out of the addition module to the latch input, and connect the SEPR input to the clock input of the latch. That tells the compiler that that input is the source of the driving event in this case, so it doesn't need to completely disentangle the complexity of that network of additions. Might be wise to stick a similar latch between some of the other adds and the P2F modules... the ones that are later in the network...

If that doesn't work, post the ensemble, and we can take a closer look.

Latches like this won't use any cpu, and don't change the result as long as you are sure that the event driving the code is the one driving the latch (need to be careful of stuff being driven internally by e.g. SR.C, and account for that)

Be aware also, with that structure, you will only ever get output from the 8th filter.

In core, merges feed all events from input to output, unless the events are simultaneous, in which case, the one at the lowest input is passed to the output, and the others are discarded. In your case, those filters are all driven internally by SR.C the sample rate clock, so all the outputs from all of them are all (virtually) simultaneous.

If you want to mix the outputs of those filters, you need to add them using basic addition modules. You might want to adjust the output volume, or not depending. If the bands are properly separate, then just adding should be fine (in the general case, scaling by 1/sqrt(N) where N is the number of signal being mixed is a good starting point).

That's tricky to help with because I don't have access to any of the sources of those values/events.

The problem is related to how complex the 'tree' of event sources gets with lots of merging, adding multiplying etc.

One way to help manage all that is to use 'math mod' macros where applicable.

e.g. if you want to add something like a dynamic offset to an LFO modulation signal, if you just use an addition, then the compiler needs to look down both paths to work out what all the potential event sources might be, but if you use an add mod macro, with the main input on the LFO, and the secondary 'a' input on the offset source, then the compiler immediately knows that it only has to investigate the LFO path, because events from the offset path are ignored, only the values are used...

Generally, it's best to use math mod macros wherever they make sense. Important to understand them well though, because you can introduce annoying/confusing bugs if you get it wrong ;)

---------------------------

Not sure about that 'selector'. It's usually better to control core stuff by gating the driving events on the inputs rather than selecting between the outputs. That way you can save a lot of cpu... Primary approaches work best in primary ;). Sometimes they are OK in core, sometimes not ideal. The only time you would want this type of thing is if you were fading between the filters, so they all need to be on simultaneously...

---------------------------

If you want more specific help, you will need to post the ensemble (with the connection that causes the problem disconnected of course ;))

That way, folk can look at it and work it out instead of making assumptions and guessing!

Pretty sure this is BAD

And you have a lot of them!

better would be something like:

Which does the same thing, and is equally cpu efficient as far as I can tell, but doesn't built up a huge web of possible event routes. It's immediately clear, that all outputs will come from the In input. the compile doesn't have to work back from the bottom one, and step up the chain checking for where the even source is.

Routers like this seem a little strange to me anyway. It looks like someone trying to use a Primary approach to work in core. I rarely use things like this in core... not sure why, maybe a different way of structuring or something?

I probably have the signal at 'in' going directly to whatever those selector outputs would be going to, and only having the active one running, the rest switched off via clock gating. Then just a merge on the outputs. So no need for this type of router, and much better cpu efficiency... something like that anyway.

Anyway, first thing to try would be to go through the structure replacing the routers with that second version. Might help...

There are different versions of the tree approach which 'look' the same but are not really the same thing.

The idea that you only go to the second comparison if the first fails, and only go to the third if the second fails etc., that is not necessary in the example in this thread - having individual comparisons with an integer is probably similar and might even be faster depending on the situation.

...with a 'fork' the code that is fed by the 5th router only needs to process a single comparison each time. In the tree version, that code always depends on the outcome of five different comparisons... I really don't know how the compiler does that stuff, but I think simpler is usually better. With the fork approach, cpu pipeling might work better in some situations making it more efficient and faster to compile!

The 'tree' approach is still sometimes the best, in cases where it's not a simple integer comparison... So if you have different routes that depend on ranges, so less than 1 goes to 1st out.. then less than 2 but greater than one goes to next etc. That would be more tricky to set up as a 'fork' type of thing, it just makes way more sense as a 'tree' approach. Just have to be careful, monitoring compile time and finding ways to help the compiler understand what the event source is (not always possible - sometimes the tree is the least complex solution). Even then, a very long 'tree' is bad news if the lower branches need to be efficient, so maybe better to use individual range checks per output...

You've posted a partial screenshot with an R6 filter for a problem that's about R5 filters not working. All we have to go on is a description of a symptom that could have many causes.

Please post an actual example of the problem, ideally as compact as possible (you should be building minimal examples of problems to isolate them for your own debugging investigations anyway)