I'm trying to use the xr gate to switch between different filters.
The xr gate is rigged to activate with a 1 going in or deactivate with a zero. Is there a way to change the value from 1 to 2 or 3… So I can use a panel knob to switch between different filters. Something like this.
Below is the gate module.
Is there a way to modify this gate so it can turn on with another number besides 1 and off with any other input number on the G input.
Say I wanted to use a number 3 to activate the gate instead of a 1. Can it be easily modified or should I just add a comparator on the input that passes a 1 or 0 to the gate and use it like it is? TIA
Well, this works so why bother.
Comments
-
I always use these little selector indexes, it's the most clutter free approach that I have found.
0 -
Well, this works so why bother.
Are you sure?
When you select one of the three filters, it becomes active. So that's good…
Then when you select another it becomes active too, they are now both active… then if you select the third, it will now also be active.
You are summing the outputs, so what you get after selecting them all is the sum of all the filters.
Unless that is what you were trying to do?
That G input on the XR Gate macro requires a gate. It needs a positive input to switch on, and also a zero input to switch off (that second part is what you are missing).
If it's working properly, you should be able to use merges at the output of the filters. If that's not working, then there is clearly a problem elsewhere.
Here are a couple of (untested) implementations of a macro that takes the 1, 2, 3 select input, and generates gate outputs that will drive the XR gates.
The top example is more obvious, and should work OK with three options, but it's not very scalable. The lower example is less obvious, but easily scalable.
0 -
I used the bottom one already, just switching between them, they don't work in parallel. The merge functions are ok when triggered by a panel event but use more cpu than the adders when using the audio clock. Pretty sure they said that in the manuals. As it stands I figure a multiplier set to 0 before the adders will block the audio when one of the other filters is used. Can't think of any other way except to use a subtraction module and feed the audio to both inputs when you don't want to pass the audio. Seems like a subtraction module could use less cpu than a multiplier but maybe not as most processors nowadays can multiply in 1 clock cycle anyway. You can't use a router before the adder because the output of the router will hold its last value after it switches outputs. In other words if you do that the top adder connected to the current filter will have a value fed to it. IDK, maybe using a modulation multiplier macro might help, there might be a way of setting the multiplier to 0 and disable the audio events in that state. That way the adder wont receive and event on one of its inputs. Seems like that might work if an adder passes one of its input with the other input open.
0 -
Yeah, those are nice. Perfect for customizing the output value for each linear input like from a panel knob or something. I'm just trying to stop the input to the adder and not using the top filter. Think a modulation macro might stop the value going to the adder no matter what the value is when I don't want the audio getting into the adders while one of the other filters are working.
0 -
I used the bottom one already, just switching between them, they don't work in parallel.
They work exactly as they should.
The merge functions are ok when triggered by a panel event but use more cpu than the adders when using the audio clock
That is incorrect.
In one of your other threads on this topic* you've already been advised by an experienced builder that merge is more efficient and the correct option. Why do you ask for help, and then refuse to accept it?
*Why have you started three different threads on the same topic?
@Sunborn can you merge these threads? not sure if you have the permissions, but it would be helpful
0 -
Indeed i was wondering the same! Why so many threads for the same topic?
…if i didn't knew who he was i would probably marked them as spam…
Anyway, no i can't merge… if they were in Reaktor, i could! But, they are on this special category "building with reaktor", so i can't.
I can ask an admin to do so, but you must be specific… post the exact links… and of course Studiowaves must agree first… it's his posts… :-)
1 -
I guess I should have kept it in the other thread, sorry, I was pretty tired when I opened this one. My fault . I was about the merge problem triggering the xr gates. That did get solved. This thread is about avoiding the merge in the audio path to optimize cpu. I'm pretty sure the merge was listed as using higher cpu than simple math functions. However I think I was fooled when using the debugger into thinking the filter outputs actually do reset to 0 output when the XR gate stopped the filters operation. I don't think it actually does and leaves the last value setting on the input of the adder but resets it to zero when it starts back up. That's probably one of the problems with the debugger, It's also why I started the other thread. Nothing was making sense, the event from the panel knob was actually send its value out of the bottom output and the merge was forwarding it into the xr gate instead of a zero. However when you use the debugger it did say it was indeed a zero. So I finally figured that out and forced a 1 and a 0 just as you did with the latches being triggered but the events coming out of the router. Then the merge passed on a 0 or 1 like I wanted. So it's not like I'm asking for help and then blowing somebody off. It's a problem with the debugger giving false information. This happens when you actually open the core cell and start reading values. Not sure why that is but at least I have learned that it does this and was the reason for asking why it doesn't work. I did not get an answer in that thread about that either but I'm telling you guys not to always trust the debugger in case you don't already know. No harm in doing that. I think the problem is solved now. I have to compare the difference between the adders and the merge with 40 voices. I also have to follow each filter with a multiplier that uses the same 0 and 1 inputs for the xr gate if I have to use the adders because of the probable hanging offset of the filters. I suspect the merge is the going to be the best way to go even with 40 voices. Because now a have 4 multipliers and 3 adders instead of one 4 input merge. I do have one question left though, how do I use the modulation macro to prevent a merge of the straight audio before the filters from getting into the merge. I guess even cancel that request because the router can be used to do that. To think all of this was not necessary if the debugger wouldn't have lied to me. I guess when you open a macro it reinitializes things when the debugger is turned on. So something was learned here the hard way.
0 -
Difficult to process such a massive W.O.T.
This whole thing is very straight forward. The only non-trivial part is creating appropriate gates for the XR Gate G input. I've posted two alternative macros that provide that functionality (both now tested and fully functional).
The examples you posted pics of, including in this thread are broken code that will not work as intended. It is surprising that you are blaming a 'debugger' (which debugger?) when your code is clearly at fault.
This is simple and works correctly, and efficiently, it uses the second macro I posted above, three factory XR Gate modules, and three example filters, followed by a merge. That is all you need.
If you have specific questions about why your version doesn't work and this one does, or why the debugger displays values different to what you expected, ask. Much better than blaming it on someone else's tools.
0 -
I got it to work the same way, all I'm saying is when you open the core macro, it can fool you. It doesn't leave things in tact exactly as they were. That's why I could figure it out. As soon as I opened the macro to use the debugger and look for unusual values it changed the values and actually selected the correct filter. All xr gates had a zero on them except the active one which had a 1. I made the mistake of not using latches with 0 and 1 on them so the xr gate was actually receiving a 1 or 2 or 3 input because the select values were being preserved when then the router switched it's states. But what happed that threw me a curve was the moment I opened the macro to use the debugger it somehow changed those values to 0 which made it work properly. I suspect the macro's get initialized when you open them up and that's why the debugger was reading 0's instead of 1, 2 or 3 on the input of the xr gates. Maybe it hit all select ports with a 0 then connected the panel select value afterwards. That would do it. Anyway I got it going and the played 8 voices and compared it with another one with the adders instead of the merge and sure enough the merge function does indeed use a tad more cpu usage. It was about 53 percent cpu and the adders were 52 percent. But if the bottom input of the merge was active the comparisons were almost equal. I guess the routine starts with the bottom on first and if it is active it doesn't have to stobe the others above it to which one generated the event. Or something like that. Doesn't matter that's a small enough percentage to not make any difference. It's working exactly like it should now. This all started when I used the equal macro and read the info, stating a 1 and 0 output. 1 on the top and 0 on the bottom. First time I used the prefab ones and thought it spit out a 1 or a 0. Turns out they work exactly like the others where you pick your own comparator and hook it to a router, they are just in there own neat little package but don't spit out a 0 or 1 like I thought. That's what fooled me. Later, it's all good now.
0 -
That would do it. Anyway I got it going and the played 8 voices and compared it with another one with the adders instead of the merge and sure enough the merge function does indeed use a tad more cpu usage. It was about 53 percent cpu and the adders were 52 percent.
That is odd, because I just did some comparative tests, and the merge version comes out ahead of using adders (With or without the zeroing mults).
By debugger, I am assuming you mean Debug structure → enable wire debugging? is this correct?
AFAICT, this wire debugger only peeks at values in the current macro layer, so as you noticed, moving to a different macro/layer will reset values, because at least that macro needs to be restarted with wire watching enabled. BE CAREFUL with this feature when cpu testing. If you are inside a macro with this enabled, that macro will run slower because the extra code to watch the wires is active. For a useful comparative test, you MUST turn this feature off before running the test. Preferably click out to the primary layer to be sure. Otherwise the currently visible structure will be penalised in the test, giving false results. Ideally, save it, then load fresh before testing. Sometimes after editing one or other macro with debugging etc., it's possible to get odd results that are not repeatable, maybe due to caching of compiled code or something. These anomalies go away after a reload.
I've definitely learned one new thing today, so thanks for that! The code into the bottom merge input will run faster!***, this is interesting, particularly how much faster (according to the cpu % readout anyway).
FWIW, I ran a test multiple times (yes, sometimes the exact same code can give different results!), with 100 - 250 voices to guarantee that the cpu usage is stable enough that differences are outside margin of error (8 voices is unlikely to be enough, any deviation is as likely due to other influences). Each voice is set up to have its driving oscillator run at a different frequency to try and ensure more general conditions and prevent the cpu from using unrealistic optimisations
As expected, merge is very slightly faster, and cleaner code too. Except on the bottom merge input where merge can be weirdly much faster (~40% faster!!!)…
***interesting, I edited it to give the merge a 4th input, and left the bottom input empty, now it's not just the bottom input that has an larger advantage. My guess is that with the lowest merge input left empty, initialisation is simplified, because that input generates a single zero event. This might help the compiler to optimise the other paths more easily leading to better binary code. It's definitely an area to explore when trying to optimise a cpu heavy structure.
Anyhow, here is my test ensemble. Please post yours to compare.
Remember to turn off wire debugging before running the test, and give a few seconds for the cpu% to stabilise. If your cpu maxes out, reduce the voice count and rerun the tests (multiple times).
0 -
Definitely good to learn about leaving the bottom merge open as it helps with proper initialization. If I remember the manuals always showed the like that. I'm going to start doing that. Here's the same module that started the whole thing. When I did this I assumed the routers were different in these packages and really did only output a 0 or 1 for logic circuits. If they did that the xr gate would have worked correctly. However this one I made outside of the other ensemble and it doesn't reset anything. In fact it works exactly as it should. Wrong xr gate drive but does output a 0 1 or 2 from the select. The other one somehow managed to reset the XR gate inputs as soon as I opened the macro. I might still have that entire ensemble on my other computer if I didn't fix it then over write it. It definitely did though because I could hear the filtered sound change when I opened the macro. But as you can see the packaged logic module would only work properly if they truly did produce a 0 or 1. In fact I wish they really did. So I blew that by assuming the made them did output and 0 or 1 logic level. I'll see if I have saved the other one and send it to you. At least your ensemble makes a realistic test. When I tested it, I have two identical sections in the main ensemble and tried on with the the adder without the multipliers except the top on which was a direct pass thru with no xr gate but one multiplier instead. I don't know why a single multiplier was slightly faster than a 4 input merge when I tested it with 8 voices but it definitely isn't in this test. I hope I still have the other ensemble that reset the xr gate logic when I open the macro but this one certainly doesn't. If I find it I'll let you have a look at it because that was strange.
0
Categories
- All Categories
- 18 Welcome
- 1.6K Hangout
- 66 NI News
- 857 Tech Talks
- 4.4K Native Access
- 17.5K Komplete
- 2.1K Komplete General
- 4.6K Komplete Kontrol
- 6.1K Kontakt
- 1.6K Reaktor
- 397 Battery 4
- 887 Guitar Rig & FX
- 450 Massive X & Synths
- 1.4K Other Software & Hardware
- 6.1K Maschine
- 7.8K Traktor
- 7.8K Traktor Software & Hardware
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators