A way to avoid the CPU spike when changing SQP snapshots?

Hi,
i tried to build a snap chaning by midi keys module for the SQP but i cant get rid of the cpu spike that occours when changing the snapshot. I tried it with morphing wich gets the best results until now but its still there. I dont understand why there is no cpu spike when changing or morphing snapshots from the snap panel? Doing the same with the snapshot module in the structrue produces a cpu spike wich creates dropouts in the whole ensemble? I tried it with delays but this doesnt solve the problem.
picture of the current status attached.

thanks in advance
whathe

 

reducing voice number seem to be the clue. 64 voices is perfect but not enought voices for recording four bars. 96 voices are the edge. recording 4 bars is possible and cpu spike is not so bad anymore. any other suggestions to solve the problem? could there be any possible sideeffects by reducing the voice number?

best
w

 

Ive encoutered this problem LOADS! Its really annoying! Ive found if you sequence snapshots to change on a bar (using a clock, Its fine when selecting maually), or by changing via midi, with a sequencer like the sq series you will get spikes (really noticable by the little yellow "event load" bar just under the CPU readout). So in a word..... NO..... theres not a lot you can do about. Ive emailed tech support once about this.... (it was doing this in one of my home made ensembles).. didnt get a very clear answer... maybe I should contact them again to see if theres anything they could do about this for reaktor 6. Ive only just realised that pretty much all the sq series sequencers do this aswell....as will anything with a massive amount of event messages going on (like MASSIVE) especially when theres a bar/pattern seqeuencer on the go (you get small event load spikes when the bar/patterns change).

This is of course dependant on how good your CPU processor is....The bad news is (that Ive found) that this is all amplified when using these type of ensembles as a plug ins (I use LIVE)

I now program any sequencer I make with this in mind, and try to keep the event load to as small as possible (but is sometimes unavoidable, and can be REALLY restricting)...

It will be reduced if you lower the number of voices, but thats not really a good idea with the sq sequencers, they might start doing funny things.

I feel you pain.....

Matt

 

Just to add to that, I seem to recall (I think... I had this problem about 10 months ago, and my memory is rubbish) that making changes with panel elements (knobs, buttons etc) dont cause these spikes. I think this just happens when snap changes are triggered using internally generated event messages... i.e song position, clock osc, delay....midi.... or anything which produces event messages without some sort of gui interaction. But as I said it was a while back now, and I could be wrong........ It may have even been a dream :S

Matt

 

i almost positve this is because of internal MIDI out, esp with alot of voices. i get the same thing using Newscool, and also my squar3 sequencer, both of which use alot of voices and internal MIDI routing (squar3 is poly for playback only, since using iterators was even more CPU-heavy, the sequencer GUI and other parts are mono with SnapValueArray). its very wierd, i think its due to Reaktor polyphony, since other apps like Max/MSP never have these CPU spikes when sending MIDI out.

 

The midi out does aggravate the problem but I have noticed the same thing in self contained instruments that have no midi out and lots of event processing.

It's not just automated recall of snapshots either - when you hit a certain threshold of event activity, that ominous yellow bar starts fluttering. Not sure why event processing is so much more intensive than audio processing... you'd think that the 400hz rate would be a snap for Reaktor to handle.

I'd really love to see this tightened up in R6 because it's the number one thing limiting what I can do in programming Reaktor at the moment.

 

I totally agree with you there!

 

The event rate only applies to a handful of modules... You can easily generate vast quantities of events that aren't limited by any rate. Make a 1024 voice instrument, add 16 snapvalues to it, merge, event vc all, value 1 -> counter up, numeric readout. Hook a knob with very high mouse reso to the input of all the snapvalues and start turning it, about 400,000 events per second (new events from gui only occur at 25hz I believe).

Another example. Add a sine osc and set some pitch and amp constants. Add A to E Perm, connect sine osc to "A" input and "SR" output from System Info to "F" input. Connect A to E perm event output directly to audio out. Or do some processing if you want.

Also I don't think events generated by interaction with the GUI (either the instrument or reaktor itself) show up on either of Reaktor's usage meters? I don't think there is any actual difference in load when changing snaps via the GUI or by MIDI if you check with some external cpu meter program. I could be wrong...

Also a little bit of fluttering on the event meter is usually fine, it is not inherently bad for it to appear. How much is ok depends on what else you have got going on, I just listen for glitches in the audio most of the time...

 

Ah, that's a good point, Contrast. Thanks for pointing out bandwidth of events versus frequency of events, so to speak. Still, I'd like to see the performance improved because heads are knocking against the ceiling of the current engine. (god what a horribly mixed metaphor!)

And there's no doubt in my mind that automated snap change creates a huge spike versus manual snap change. I've experimented enough to confirm this. If snaps change on the beat synced to midi, there's a spike. This is true whether the trigger comes from within Reaktor running standalone, or from a host like Live.

 

Yes, less CPU use is always good of course. They aren't horribly inefficient at the moment, though, is all. While some sort of global improvements to the efficiency of them wouldn't be bad, I think I would probably like to see them take the approach of some more modules that take care of things that are tough to do (and tougher to make efficient) with Reaktor's approach. Sorted lists, for example.

 

Depends on what you're trying to do, doesn't it? It's only natural that if you haven't hit the limit in some area, you won't see it as a problem.

That's where an embedded scripting language would rule.

 

I mean that in terms of the overhead just from the nature of events, I think it is pretty reasonable. But clearly if there is no way to avoid very large quantities of events being sent around, you can still run into trouble.

I'd be curious to know what you are doing exactly, just for curiosity's sake.

I agree about the scripting language, that would be a great feature. Seems unlikely though, I would have thought they would have done that with core if they wanted to go that route.

 

I have live performance ensembles with a bunch of instruments each of which has an awful lot of clock driven doodads. I have tried many programming strategies like using one clock source and wiring it to all my doodads (I tried with both wired and wireless connections), using clock oscillators as clock sources, and so on, but nothing seems to cut down the event overhead except using fewer doodads and raising the latency.

I was thinking about your point re: 400,000 events per second - is that such a huge workload for a modern computer that runs at 1 or 2 or more gHz? How many clock cycles does an event consume, I wonder? (of course it depends how far it has to propagate and how it's processed... hmmmmm)

 

It sounds like we do similar things, but probably I do not have as many doodads as you, mostly only a few sequencers and whatnot... I try to thin out the events as early as possible in various ways but I am sure you use similiar techniques. The most horrific things that I use are some midi loopers based on SQP but I keep the voice count fairly low and it is somewhat more CPU efficient than the stock SQP. An old version is in the UL somewhere... In any case that's a task that Reaktor is ill suited for and it chews up more than I'd like.

After reading your response I had the thought that probably it would be more useful to run some audio through identical structure, as both events and audio and look at the CPU usage numbers (as far as I have ever been able to tell, event CPU usage shows up on the CPU meter when it is ultimately generated by the audio engine, so I think this is ok).

So I took a Sine osc and ran it through multiply, add, divide, and subtract, another add and then to the audio outputs. I tried this both with the sine osc straight into the math, and also with sine -> A to E perm at samplerate -> math. Only the math modules were poly, the Sine, System Info, and A to E Perm were mono.

Reaktor running with nothing connected: 0.9%

1 Voice Audio: 1.9% (1%)
1 Voice Event: 3.3% (2.4%)
5 Voice Audio: 2.3% (1.4%)
5 Voice Event: 9.7% (8.8%)
10 Voice Audio: 2.6% (1.7%)
10 Voice Event: 16.4% (15.5%)
20 Voice Audio: 3.0% (2.1%)
20 Voice Event: 29.5% (28.6%)

These are just rough measurements from watching the CPU meter of course. This also includes whatever overhead there might be in going from the audio engine to the event engine and back again.

In a real situation it's not quite as bad, there are many event modules with a higher level of functionality, and of course there are things you can do with events that you cannot do with audio (like loops without a 1 sample delay on each iteration).

But, even inserting one order module that just uses the 1 output into the event chain results in a quite large CPU use increase.

My assumption would be that the audio modules, having less complex possibilities, are implemented in a more optimized way that avoids lots of function calls, and the events which are probably implemented in a more generic way that does result in many function calls are getting saddled with the associated overhead.

(so I guess we are back to horribly inefficient )

 

Wow! That's some pretty thorough testing. I agree that the events have more complex possibilities, or more general usage possibilities... maybe it's like where you trade off some efficiency for flexibility in a scripting engine. Anyways I hope they can tune the performance a bit in the next release. I can't imagine how the in-house builders would develop ensembles much more complex than the R5 factory library unless they do.