Reaktor 6.5.0 Crashing Repeatedly When Connecting Wire in Core Macro

weissmf

Thank you, colB, for the response. Somehow I thought the TSK LP (NL) filter was Reaktor 5. The macro that contains the fliter(s) has that "Legacy R5 SR for Audiocell" macro up in the corner, but maybe there is some other R5 component that is responsible for this that I have lost track of.

At any rate, here is a more complete account. I hope that this is useful. I've attached 5 screenshots with text narration that shows how audio enters the filter but does not emerge from the SR.C latch in the ZDF component inside the TSK fiulter. This makes me think there's some problem with the clock bus that controls the latch.

I am also attaching the ensemble here. There's a lot of moving parts, but I've hardwired an isolated signal path around most of the pieces. It's an external audio effect ensemble. It's got an included short audio sample that you can play to test it.

Please let me know if there's more troubleshooting I can apply on my end that would be helpful in making sense of this. I have an intuition that this is a pretty simple problem, but who knows. Thank you for your help here!

34.9.ens

colB

OK, so you need to go read up about what 'solid' means in relationship to a core macro...

In your structure you have this arrangement:

Those dotted boundaries mean you have the macro solid parameter unchecked. This means that Reaktor will ignore the macro boundary - so there is no parent/child relationship, everything inside the non-solid macro is treated as being on the same layer as everything in the parent... and this works over multiple layers of non-solid macros... it's as though there is no macro, and the macro is just a tidy up convenience, and a way to save/store a collection of components...

So in your case, that SR distributor in the Frequency Modulator macro isn't really 'inside' the Frequency modulator macro, it's actually active at the SYNTHESIZER top core cell level (all it's parents up to that level have solid toggled off!!)... so at that level or lower, any references to ..SR will be picking up the SR distributor from inside the Frequency Modulator macro... so if that is switched off via it's gate, nothing else inside the core cell will get any sample rate clock.

...best option is... don't uncheck solid unless there is a very good reason to do so... the only time you really need to uncheck it is when you have an internal z^-1 feedback situation. In that case, it doesn't work correctly without the non-solid macro (e.g. 'latch' is solid, but 'latch[-1]' is non-solid because it has an internal z^-1 mechanism... a one sample delay). For everything else, leave solid checked.

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

AND... learn how to use, or build your own control multiplexing scheme. All those control connections are a nightmare in terms of maintenance!

The multiplexing in partials framework is likely very comprehensive if a little incomprehensible... Blocks modules have a nice simple multiplexing scheme for the A/B modulation scheme that's easy to understand and extend for your own purposes... I use a custom approach (very clunky and simple) that I built before either of those things existed... it's really not too difficult!

weissmf

colB –

Thank you! This is invaluable advice and saves me hours of puzzling. I will dig into the Reaktor Core Manual to see what it has to say about solid vs. non-solid.

In the meantime, to answer your question regarding the FM macro – there is indeed a feedback loop in the SINE OSC macro inside of the FM macro. That's why I set up the FM macro as non-solid. But it sounds like I need to re-think this arrangement somehow? If you have any pointers on how to do this, I would appreciate it. Screenshots below show a navigation down through the structure to that feedback loop.

And yes, you are right about the nightmarish control connections! I will school myself on the Blocks multiplexing per your advice and work to implement a new scheme in place of what I currently have. Thank you for that advice.

Best,

Michael

colB

That feedback delay is completely internal to the 'SINE OSC' macro. Why do you think you need that or any parent to be non-solid? (not a rhetorical question btw)

====================================================================================================

An easy test would be to make it solid and see if Reaktor applies an implicit delay and turns wires orange...

Here's a sketch to demonstrate:

The only difference here is that I toggled the latch[-1] in the lower version to solid... so even though it has the correct unit delay internally, Reaktor doesn't 'see' that because the macro is solid, and adds another implicit delay (orange wires). The non-solid option is specifically to resolve this issue, and is required for this structure to function correctly.

AFAICT this is not a problem in your structure. the feedback is purely internal to the SINE OSC macro.

weissmf

Thank you, colB!!

OK, I toggled the macros back to solid, and now all the filters work again. I will go read up on this issue so that I understand it better in the future and don't make similar mistakes again.

Thank you again for your help – I really appreciate it it!

Best,

Michael