Reaktor 6.5.0 Crashing Repeatedly When Connecting Wire in Core Macro

weissmf

Hello Smart Reaktor People!

I am getting repeated crashes in my ensemble when I connect a particular wire in one of the core macros. Here's what I observe: Connect the wire>>>Red status "off" illuminates in upper right corner of window and remains illuminated>>>I save the file and go to quit>>>endlessly spinning beach ball. See screenshot.

If I force quit and go to re-open the same saved ensemble, it opens very slowly, and I get the endlessly spinning beach ball again.

Here's a rundown of the connection that seems to be triggering the behavior. It's a control signal from another part of the ensemble that is wired to a series of cascading filters for a resonator effect. The first screenshot is inside the macro that is causing the crash; the second screenshot is one level up showing the macro ("1") as it is connected to the other macros, which are identical to it. Not sure if that helps, but that's context.

There are some gaping holes in my knowledge of Reaktor, so this may be a simple issue of whose cause I just ignorant. If y'all wouldn't mind weighing in, I would appreciate it. Thanks!!!

colB

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)

weissmf

Thank you, colB!!!!!! Really appreciate that. I'll give it a try and hopefully it works. If not, I'll give a shout back.

colB

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).

weissmf

Thanks, colB. I've inserted latch modules per your suggestion in the Resonator macro, and it seems to have corrected the problem of Reaktor hanging indefinitely as it tries to compile.

Now, however, I am getting a similar problem in a different macro. Very briefly, it's a Filter macro wherein we have a few things going on: a knob input for filter cutoff, an internal envelope providing cutoff modulation, and another control signal from elsewhere in the ensemble providing control rate cutoff modulation originating from a mod matrix. I've got a selector module for choosing between 1) no cutoff mod, 2) env mod, and 3) matrix mod. There is also an internal oscillator for providing audio rate modulation. The oscillator is hard-wired in, so it's always connected.

I am getting the compiler hang when I connect the combined outputs of these modulation sources to the Frequency input of the filters via the QuickBus connection "F." As you will see, there are a couple of scoped bus Pitch inputs upstream of this whole process for establishing filter cutoff keytracking also internal oscillator keytracking. The Pitch inputs seemed to be the source of the previous compiler hang, so I wonder if they are a culprit here, too?

Thanks again for your help!

colB

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!

weissmf

Thank you, colB. I really appreciate your taking the time to make those observations and comments. There are gaping holes in my knowledge of Reaktor, as I mentioned, and math mod macros is one of them. I will educate myself on this topic and update the ensemble accordingly. In the meantime, here is the full ensemble. It's still a work in progress, and I have not done troubleshooting / debugging on it, so it likely won't make a sound when you turn it on :) It's meant to be a device for processing external audio but sort of modeled on the architecture of a synthesizer, FYI.

Perhaps you will be able to get a sense of what might be causing the compiler errors by seeing the larger structure.

Thank you again for your help!

34.3.ens

colB

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...

weissmf

Thank you, colB!! Really appreciate that advice. OK, I will make the changes with respect to Math Mod and also change the present configuration that is using the routers. Hopefully this helps. Thank you!!

weissmf

Hi colB –

Touching back in with a quick update and question. I am following your advice and switching out the primary-style selectors and replacing them with XR Clock Gates. Thank you – this is an invaluable piece of advice.

With respect to your recommendation for replacing Math macros with Math Mod macros – I am wondering how to prioritize these changes. There is obviously a lot of math going on inside of this ensemble, to state the obvious, and I am not certain of where to consider using Math Mod macros and where to leave the current configuration as-is.

If you have a quick top-level piece of advice on how to prioritize the use of Math Mod macros in Reaktor building, I would appreciate hearing it.

Thank you for your help!!!

– Michael

colB

https://community.native-instruments.com/discussion/comment/90541#Comment_90541

If you have a quick top-level piece of advice on how to prioritize the use of Math Mod macros in Reaktor building, I would appreciate hearing it.

Anywhere where an event at one of the inputs should always produce an output and the event at another should not.

So one example would be an audio signal being scaled by the input from a knob on the GUI. When the value from the knob changes, that should not generate an output from the arithmetic that applies it to the signal. Only audio sample events should produce outputs. In that case you should always use a mod macro (or some other sort of latch logic)

Another example would be constants. Adding, subtracting multiplying etc. by some constant, the constant should not generate an output event at the arithmetic module (only happens at initialisation) unless you explicitly need it to for some particular reason.

So for 'signal' processing there is usually a signal and some other parameter that is being applied to the signal, you would often use a mod macro there so only signal events produce output events.

Sometimes you must control the event sources to ensure correct functionality, sometimes you don't need to. But even when you don't need to, doing so can reduce the number of paths the compiler needs to process when compiling the code, so ideally, you use mod macros and latches to ensure the compiler only needs to follow event paths that actually matter :)

I really can't tell you which ones, that just depends on the code, it's different every time. Just try and get into the habit of considering and then explicitly controlling which input events generate outputs for any macro you build.

Retroactively applying this sort of thing to large existing structures is unfortunately a very time consuming and annoying process in Reaktor. And it might not help!

weissmf

Thanks, colB!!! That's super-helpful. Preparing to go through the ensemble and make changes using these guidelines.

Quietschboy

https://community.native-instruments.com/discussion/comment/86834#Comment_86834

yeah, cool, i had 27 seconds compilation time in a core cell. after replacing one single tree router by a fork router, as you mentioned, the compilation time lowered to 8 seconds !!!

Thank you very much, Colin!

I saw NI using tree routings in some stuff, assuming this is better for cpu performance while the ens is running. And i still think it is the case, but on the other hand that are peanuts.

Edit: Replaced another tree by a fork: 3,2sec compilation time left. Man...

colB

https://community.native-instruments.com/discussion/comment/92247#Comment_92247

I saw NI using tree routings in some stuff, assuming this is better for cpu performance while the ens is running. And i still think it is the case, but on the other hand that are peanuts.

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...

weissmf

Hello colB –

OK, after a lengthy school & work-induced Reaktor hiatus, I have once again been working on my ensemble in the past month. I am running into what is likely a very simple problem; but, due to my general ignorance of certain concepts with building in Core, I am unable to figure it out.

Basically, I have inserted a number of Reaktor 5 filters into a Core cell, and they are not working. The filters are switched by an XR Gate, according to your recommendation. When testing the ensemble, the XR Gate is receiving a "1" or "on" signal, so it should be allowing the clock to pass into the filter. The gate is connected to the ".. SR" bus. However, when I investigate inside the filter, it appears that the components that are connected to the built-in SR.C bus are not receiving a clock from that bus. So they are outputting "0" values and the filter is not working. In something of a random, trial & error approach, I have tried connecting different clock busses to both the Gate and the internal filter components. I've found that I get some sound out of the filter if I connect the CR bus, which is encouraging; but it doesn't sound right, also.

I know there is a simple problem here that I am just not grasping – again, because of my general ignorance. If you wouldn't mind helping me sort this out, I would really appreciate it! I have attached one explanatory screenshot but can provide further detail if that's helpful.

Thank you!

Michael F. Weiss

colB

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)