Can i block initialization events from reaching certain modules?

In Primary, i have a knob connected to the Panel Index module in a Stacked Macro, via a Compare/Equal module. The smoother makes it so that when the knob is turned, there's a temporary value lag/difference and the Compare puts out the 1 that makes the "HELLO" visible.

When i use this setup in an instrument or ensemble, changing snapshots creates initialization events that temporarily make all the hidden elements visible. And if there's a lot of them, that looks rediculous. I would like to make it so that this does not happen.

Any ideas?

Greets,

Bolle

Find more posts tagged with

Comments

Bolle

I found the No Init module in Core. It works perfectly and solves the initialization event blocking part of the problem.

What remains is the fact that switching between snapshots (and thus jumping between knob positions) obviously still makes the hidden parts (temporarily) visible. Trying to figure out a way to handle this.

Bolle

Solved.

Built a macro that normally puts out a 1, but when switching between snapshots temporarily puts out a 0. In the Stacked Macro for the display, the Panel Index input is multiplied by the output of the Display Block macro. The Hold time is slightly longer than the Smooth time of the display macro. The No Init core module is not needed in this scenario. Boom.

Thanks all.

Greets,

Bolle.

Studiowaves

You have to look at how things work withing reactor and go from there. Everything gets inititalized whenever a patch is changed. All of the gui elements have to be read and sent as a starting value for the code to follow. All of the modulation macro's in the code also get loaded. Think like the machine is your best friend in these situation. I would recommend using delays or smoothers to time delay something that prevents the problems. In other words, trigger something that will stall something else during a program change. Here is something for you. It's a very low cpu usage time delay that switches to 0 the instant a new patch has been changed. Then wait a brief period and spits out a 1. You can use the logic level to stall something from happening. You can easily adjust the time by changing the value of the buffer as shown. For 1 second choose a value of 100. Half a second set the size to 50 , 2 is the minimum. Just right click the blue buffer and select properties. The window on the left pops up, under function is the size of the buffer. Note if you can't get the time as fast as you want then increase the F value of the clock gen to 1000. Like that your time delay can go as low as 2 milliseconds. But this eats more CPU. You can also set F to 10 and the buffer size to 10 for a 1 second delay but at 2 on the buffer I think you'll get 2/10 of a second. You might optimize it by leaving the buffer at 2 or 3 and changing the F as needed. The lower F is, the less CPU gets used. However at 10 then your wait time also depends on something else which I don't want to get into, but if it works at 10 it hardly uses any cpu at all. That's a sample rate of 10. lol

have fun!!!!!

low CPU delay.ens

That should get you going. Open the ensemble and change between patches and it should work. Basically it turns the amplitude off for a sec then it starts up. Of course the 0 to 1 and it's time delay should solve many of your initialization problems. Have fun….

Studiowaves

Here's something that should cover all the bases. This ensemble allows you to specify the reset value for a gui element. Then after the delay the actual panel value will come out. In this ensemble you hear the waiting value first then the knob value. The hold could index the stacked macros to whatever one you want, then after the time is up the outputs read whatever is on the gui. Also the Gui control still works as usual after the initial period. Here's how it works. Whenever the snap value is changed or the start button is pressed on reaktor it starts the initialization process. Reaktor will not read the gui knob but instead read the output of the Low Cpu delay. Then after the time is up the gui knob shoots thru as though it's been turned even though it hasn't. So the init values are the hold values you choose. Let me know if I can be of further help. I do love those Red/Green buttons you made for me a while back. They fit perfectly in the solid bar of main macros and I use them to activate or bypass the macros. Thanks again, now we are even. lol

low CPU delay.ens

colB

https://community.native-instruments.com/discussion/comment/248508#Comment_248508

Relatively straightforward solution. Use a custom smoother, and a snap value to store the latest input from the knob.

On snap recall, the value is sent inside the smoother and updates the internal state, so it initialises at the snapshot value, instead of smoothing towards it from some default value.

Here's the smoother:

and the edited latch[-1] showing the injected snapshot value:

I used the display clock to drive the smoother. No need to weigh the cpu down with audio rate smoothing or counters for something like this. Also means the core cell can be 'GUI events only'

When you turn the knob, the hello message appears instantly, but takes 'time' seconds to disappear. snapshot changes never cause the hello message to appear.

I would bring the comparison into the core cell too.

(Not sure how well this smoother works as a smoother, untested :). Never tried making a smoother this way - based on a feedback slew… EDIT …seems to work quite well)

You can likely use the factory core smoothers for this too, they have a reset value input port.

Studiowaves

Colin, do you realize I made him an interface that is inserted between the panel knobs and their destination. What I did was allow you to input a value of your choice instead of the value from the gui control. I can last for a second or a millisecond. I suspect Bolli is using stacked macro's or something similar and a previous macro is lingering on for too long or something. If you look at the low cpu delay module you'll notice 3 :="HOLD" inputs. The thing is, this system immediately inputs the value at the HOLD input, then stay there until the delay lets the panel control thru. Being that it immediately sends in the hold values, it might be possible to immediately turn on a certain preselected "Stacked Macro". Something that would be make the transition from one snap to another look picture perfect. That's all it does, I just made three presets that play the holding notes followed by the panel control value. The are three of the to work with but you can copy and past them inside the core cell for as many as you need. Even one for each panel control. Have a look at it, it's very simple but I'm not sure how well Bolli understands what it does or how to use it. I know you can, so if you think it will solve Bolli's problem. Thanks

Studiowaves

Bolli, are your stacked macro's staying on longer than they should after a program change. If so, what I made allows you instantly select any stacked macro that you want. Then after a brief period of time the actual value of panel control will go replace it. So in short, you can call up any stack macro you want and then wait for the control value to select what you have saved in the preset. Colin can help you with it because for him, it's extremely easy to understand. It's done with core but interfaces perfectly with any panel control. Even switches. After reading your problem, it seem like you have a timing problem with your macro's. Like one stays on too long. If that's the case, this should fix it because it initializes any stacked macro that is associated with the index pointer. The pointer that recalls stacked macros themselves. Happy Thanksgiving Guys!

Quick links

Unanswered questions