Best way to optimize a primary sequencer?

Octaviu5 · 2022-12-17T07:52:47+00:00

There was an error rendering this rich post.

Octaviu5

seq button.ens

Hello.

Im currently at a very early stage of development of a new idea for a sequencer.

Attached to this post is a brief ensemble of a single structure that im developing.

It works as i expect it. However, im gonna need lots and lots of the same structure.

And when i replicate the macro multiple times the cpu usage can go to up to 30% Which is really undesirable.

My question is. which of the primary modules that im employing would be the most cpu demanding? Can you think of a simple way to optimize the thing?

Also, if i was to do this in core... would that give me a noticeable difference?

And if i was to do it... what would be a good starting point? i've never used core before so the thought of jumping into it for this sequencer is daunting, but would do so if it is going to pay in big cpu savings.

Thank you in advance.

You guys are awesome. This community has been very helpful.

I really appreciate all of you fine folks who take time to reply. For now im the annoying guy who has questions all the time, but please know that i really appreciate all of your help.

Find more posts tagged with

Comments

colB

In general you shouldn't need to optimise a sequencer - it shouldn't be doing much most of the time. Each time it gets (or generates) a clock tick, it does some processing, but that happens at most a few times a second.

e.g. midi clock is 24 ticks per quarter note, so at 120bpm, that's 48 ticks per second

At 48KHz, an audio process is doing its thing 48000 times a second - it makes sense to do some optimisation in that context.

In this example, the audio process has to run 1000 times for every 1 time the sequencer process would run... not a whole lot of need for optimisation in the sequencer, assuming it works in a reasonably sensible way ;)

errorsmith

as colB already wrote you usually could built a sequencer only with event processing. that means without any modules that run at audio rate.

if you are unsure if a module runs at audio rate turn on 'options menu'/'debug structure'/'measure cpu usage'. if on all modules that run at audio rate will show their consumption. if a module doesn't show anything it means it doesn't calculate anything at audio rate.

to optimise, try to find these modules and see if you could replace them with event processing modules.

eg it looks to me that you can replace the "A to E Trig" module (runs at audio rate) in all the 'bt' macros with this:

you can also turn off 'limited speed' in the properties of the iteration module. you only need this if you get cpu spikes because of heavy event processing caused by the iteration module and the event processing that its events are causing. But that doesn't seem to be a problem here.

With 'limited speed' off, the iteration module doesn't do anything at audio rate.

With these two edits, you should get a structure without audio rate modules and save a lot of cpu.

event processing with core is more cpu friendly but the cpu demand is not so high for an event based sequencer, so you wouldn't gain much cpu wise.

ANDREW221231

https://community.native-instruments.com/discussion/8744/best-way-to-optimize-a-primary-sequencer

im not a sequencer guy, so all i have is an old hunch which came from using the stock sequencer and getting really annoyed with seemingly extraneous hoops to maintain operation so developed the habit or strong preference for using the selector module for anytime i needed anything that would repeat a bunch of numbers over and over in almost any capacity

you give it a number at its index and it gives you whatever value constant is connected to that input

always easier time getting the result, always at less opportunity cost. its also as simple as it could possibly be, besides a modulo and clock to get it going proper which are also simple stuff. also the selector is something that has no core counterpart and getting something that worked the same would be its own sizeable task

probably i'm missing something that it can't do, but i don't know what that would be. i always said if i did make a sequencer it would be based on the selector module. what i can say is that someone had a arpeggiator type thing built on the sequencer and i ripped it apart and changed out the sequencer for a selector which was much simpler and it actually worked much better after

edit: @colB maybe you know a reason why not to use the selector module as first choice for sequencing stuff. i assume there probably is one but i was never able to figure one out

colB

https://community.native-instruments.com/discussion/comment/45439#Comment_45439

edit: @colB maybe you know a reason why not to use the selector module as first choice for sequencing stuff. i assume there probably is one but i was never able to figure one out

#1 reason: it is a primary layer module. I try to work in core where possible.

Other than that, there will be times where one of the more dedicated sequencer modules is better suited, or where an M->1 router works just fine...

A selector is really just a wrapper round an array, and that is easy to set up in core and much more flexible... maybe slightly more hassle in Primary. If I wanted a sequencer with e.g. 256 step pattern lengths, and 64 selectable patterns to choose from in song mode, I'm not sure I would try and build the main sequencing engine using selectors.

ANDREW221231

https://community.native-instruments.com/discussion/comment/45583#Comment_45583

suppose i've maintiined a situational preference for certain primary modules with suitable performance and a certain convenience factor for building. recently broke a core cell only to get an add module with selectable # of inputs rather than labor over an unwieldy labyrinth of sequential 2x2 adds to pyramid down to a single output

i suppose a selector/ with the array broken out with direct access to the constants per input could be done in core but dragging menu function to change up the number of inputs is still goated (Grestest Of All Time-d). i learned from the only selector in core i found on the UL that it requires planning and infrastructure and discovering a bug in it did not inspire confidence

wwe just need them to extend the selectable # input the core merge already has to a few other key modules. think its the last thing in primary that still seems preferable at times

ultimately yeah better to do it in core, but anyone still using primary and trying to manage the stock sequencer would do well to ditch it for the selector. it worked surprisingly well for stuff where everything needs to happen perfectly with no room for "primary getting the order of events mixed up" shenanigans, when you know it probably wont work but if it doesn't you only wasted three minutes. that's the real enduring value of primary

colB

https://community.native-instruments.com/discussion/comment/45606#Comment_45606

i learned from the only selector in core i found on the UL that it requires planning and infrastructure and discovering a bug in it did not inspire confidence

This is something to avoid IMO. Trying to recreate Primary modules in core so one can then use Primary approach in core is likely to result in bugs due to the inherent difference between the two paradigms. Particularly with modules that will become part of the logic of your structure.

I think for the most part - could be completely wrong here of course - any Core recreations of Primary modules in the UL will be written either by core beginners, or folk who never fully made the transition to core, so need the crutch of Primary-alike functionality. I wouldn't trust anything written by either overly generalised stereotype to be bug free, so I'd need to test them systematically, at which point I'd be better off just rolling my own.

Back on topic, for sure the selector is a useful module, use it where it makes sense to do so! Primary is great for simple step sequencers. It's one of the few areas where it really competes with core.

ANDREW221231

https://community.native-instruments.com/discussion/comment/45622#Comment_45622

yeah, even custom macros i specifically saved never get used as anything but a bundle of ingredients. it its useful it usually not generalized, and if its generalized its generally not useful. a selector is kind of a special case though, the demand for one makes sense but there's no way to have one without also having to deal with the nuts and bolts every time its used for something different

i think with core, building everything out of different combinations of the same four things that behave exactly as you expect starts to sound like a good deal or it doesn't. the issue with macros isn't whether they're good or useful, they're just of limited use, a solution to a problem you're not solving

getting rid of all the library stuff that was primary ports was probably a good idea tho because people will try to do primary in core and have a bad time then develop negative feelings about it as something to avoid, but it depends... to someone who uses the pseudo low level stuff in primary as i did it just became apparent core was another way to do the same basic functions with the 'maybe' factor removed. it was less a decision as just seeing a way forward. as long as its understood at some point that the primary versions are the goofy dressed up versions and the person is willing to give up the idea of chains of events happening in order (probably the latter is the main obstacle really)

in general there's too much apprehension over which one to use that's mostly unwarranted, a product of de facto team sorting... people like their side and want to stick up for it, its all tied up with identity

@ OP i can say with certainty 30% seems high, and certainly there are things to do for this. there's always an angle to get something to do the same job but with less work, there's ten million dirty tricks and that's after eliminating any big obvious inefficiencies

about that... it'll be easier to pinpoint if you upload a version that is already running at this limit you're running into.. its hard to say what could be wrong with it as uploaded but an active problem can be tracked pretty easily

i will say about whether or to do it in primary or core, the most important factor may be whether or not it is intended to be polyphonic. a single voice can be optimized better in core but its generally not as strong at polyphony

Quick links

Unanswered questions