Is there a way to pass a signal straight thru a core macro and use the xr gate on the macro.

Studiowaves
Studiowaves Member Posts: 749 Pro
edited March 16 in Reaktor

I have 4 selectable filters by using the xr gate using the comparators as shown in the middle picture to get it to work correctly. Once I got it working I was hoping to not use the top one pole filter and instead make a straight pass thru when it's selected. The problem is how to do that without a function of some sort. About the best I can do at this point is replace the top filter with the comparator shown on the bottom pic without the xr gate and top filter and send it directly to the top plus input of the adder. This should work but it adds a multiplier which multiplies on every audio clock just to pass the input thru. I think the router remembers the last value before it switches outputs and that could leave a value other than 0 that will remain fed into the adder. Is there any thing else I can do? Also the merge function has been avoided because it might use more cpu than the adders. Also the select and F are events, not audio. Not sure what's the best move here. Any suggestions on bypassing the top filter without using a multiplier?

image.png

This is the select module before the gate

image.png image.png
Tagged:

Answers

  • Big Gnome
    Big Gnome Member Posts: 42 Helper
    edited March 17

    the merge function has been avoided because it might use more cpu than the adders.

    It doesn't. In fact, at least in most scenarios, merging uses infinitesimally less CPU than addition, but it's not something you'd notice unless you're working with hundreds or thousands of voices. Also, with adders, you're summing the last sent value from all of the filters, both active and inactive (read: incurring DC offset), whereas a merge will only pass the most most recently received value (favoring the lowest inlet for simultaneous events). Just use a merge—it's the correct tool for the job.

    the select and F are events, not audio

    Core does not distinguish between audio and events—they're only distinct signal types in primary. In core, everything with a discrete value (i.e., excluding logical- or memory connections) is an event.

  • Studiowaves
    Studiowaves Member Posts: 749 Pro
    edited March 18
    https://community.native-instruments.com/discussion/comment/216594#Comment_216594

    I think the manual says the merge functions use more cpu than simple math. In this case the filter output are reset to 0 after the xr gate shuts them down. I assume it's the reset in the xr gate that does it. I can't remember if reactor 5 or 6 manual showed the order of low to high cpu usage. But I'm almost sure I read the merge was high on the list when used in the audio chain. It might be but I've also discovered something that actually started this whole problem. Here's the deal, whenever you open a macro with the debugger on it can reset things in the macro. Like you said, the adders can still add what's on the outputs of the filters. Then I said no because they are reset to 0 possibly by the reset. That's probably not true at all but the debugger told me they had a zero value after I opened the macro and probed the output. They weren't exactly 0 but way way down like .0000000000000000001. So I thought, hey wait a minute why not dead 0. That's when I started thinking something was odd here. Turns out they do have a remnant value, probably the last value when the xr was shut off. But not when you open the macro and read it with the debugger. I was fooled, I think things get initialized when you open a macro with the debugger on. That's the whole problem, it explains everything, the routers were even outputting a value of 0 after opening the macro. Which went into the xr gate, but without opening the macro it was actually passing the value of the router input to the gate. Which could have been a 0 1 2 or 3 depending on the front panel knob value. My guess it also tossed a value of 0 into the inputs of the filters too when I opened the macro. Then when I read it I didn't get a dead 0 on the output of the filter because the filter probably does have a small offset with a 0 on its input. Moral of the story, don't trust the debugger, trust your friends.

Back To Top

Categories