Made a custom LFO

i spent time making an LFO from event modules, it even has pulsewidth and phase inputs and seems at least as accurate as the built in LFO module, but it uses alot more CPU... how come there is no way to deliver tick signals in reaktor that doesnt take tons of CPU usage?

for example a 1 voice clock oscillator will use 15 percent cpu useage if you plug it to masses of modules downstream... yet on it's own it uses just 1 percent in monophonic. same with an LFO...

same for A to E modules etc.

is there a way from making a tick signal from core?

if you put a normal LFO to modulate 10 other LFO's it will take up 10 times more processor while the 10 other LFO's also each use a normal amoung ot CPU. why is that.

 

There are immediate answers to your questions, but I think it's best that you post some examples of what you are doing so we can put things in context.

I'm very curious to see what you've done.

Just zip up a few of your attempts for us to see.

 

thanks arachnaucht for the reply,

here is a super example of reaktor taking up 50 percent cpu on one element at the top of a dsp sequence and the same macro taking up .3 cpu at the end of the sequence, i figure it is a bug to do with the CPU monitor perhaps,,,

also here is a new LFO that is the same as the module one with added difference that it can be reversible which can be useful for sound control, i didnt finish smoothing the freq changes because the cpu level was not low enough.

 

I looked over your structure briefly, but it isn't easy to follow what you are doing.

I guess you know how to observe the CPU load with the debug.

I didn't understand why you have A/E modules in there.

But anyway, I think what you are doing might be done better in Core where you have much better control over signals.

 

thanks jim, i haven't delved into core really for the moment, could you tell me if it is possible to initiate a control rate signal in core? i am pretty sure that core only can react to incoming signals, and cant generate events in itself as would be essential for an LFO... for control rate modules it is equivalent to module level processor useage...

if you use the debug>measure cpu in that structure there, you will see that in the lfo chain, the first lfo uses around 25 percent, the second uses 12, the third uses 4, and the fith uses 0.4... maybe Clist knows why they dont all use 0.4...

my puzzlement is that an A to E mono can use 25% of the processor...

A to E is often used in reaktor to make a control rate tick, you can use a to e perm, and clock oscillator and a number of modules for the same purpose, but the result would be the same at 25% processor useage. it is puzzling.

 

About core, I don't use it often enough to give any more advice than I have already done.

About the CPU usage. I've seen Reaktor give a huge amount of CPU to one thing or another - often the CPU load will move about a complex structure.

I believe what is happening is that certain audio buffers take a hit here and there by chance and we are seeing that happen. So the CPU load should be taken as only indicative.

 

it's just an lfo, it isnt too tricky to figure what is happening there.

 

You can use Core.

You are correct that Core cannot initiate control rate signals. It doesn't matter, though, since you can just connect the CR output of the System Info module to a Core Cell input and create events with any timing you'd like.

My advice is to not use Core. I've looked through your ensemble, and I think you need some practice before you're ready for Core. Here's some programming style tips:

- You should be using 1->M Routers for your branching instructions, not Selectors and Distributors. This is part of your CPU problem. Using a Selector (or M -> 1 Router) is a bad idea the vast majority of the time. Sometimes it makes your code more elegant, but it never saves CPU. Use 1->M Routers all the time, until you find the few places where it's acceptable not to.

- Avoid using Switches. It seems like a good idea at first, but in practice it causes a lot of issues. If you're using 1-> M Routers properly, then the benefit of turning off a signal path with a Switch is negligible.

- Use more Order and Value modules. Whenever a calculation requires a split path, then merges two paths (i.e. addition, multiplication), you're doubling your CPU overhead for every module after that if you don't put a value after the merging module, then use the Order to continue the calculation. This may or may not make a difference in the result, but it will make a difference in how much CPU is being used.

- Set as manly of your modules to monophonic as possible. I don't see the necessity of using a polyphonic instrument for this application. You have the voices set to 4, so changing it to 1 quarters your CPU load right there. If it must be polyphonic, take a close look through your signal paths and find the places where every voice along a path has exactly the same value all the time. These modules can be monophonic.

You may be getting good output, but your method for doing so is very messy. You really need to design the whole thing from the beginning, using the principles I've outlined for you.

 

Hi James,

Thanks alot for that information on good flow control... very interesting i hadnt figured that value modules can halve the data going through the lines... and the
1-m module sounds like i should know alot more about it!

i will make a comprehensive study of the data going through the lfo based on your advice when i have a moment as soon as possible. thankyou.

one mystery certainly still remains to me is how a system info module in mono mode can display between 0.4 and 20+ CPU useage in measure cpu mode depending on the number of modules that go after it.

i guess that the number shown on the system info represents the processor toll of all the modules downstream from it of which it is the control signal generator. i think audio to event converter is equivalent to system info for processer level.. .

 

The CR output of the system module outputs events at control rate. So, if your control rate is 400hz, then 400 events will be produced by the CR output every second.

Add a step filter after the CR output. This way an event will be output only when the control rate is changed.

I managed to almost halve the CPU requirement of your ensemble by doing this on every CR output.

 

hi, yes it's great to put a step filter/value module on the system info, it makes the processor toll go from 5 to .5 percent which is always cool. system info can also be used to send tick/cr events.