Has anyone noticed that main macro's can use a lot of cpu?

Studiowaves
Studiowaves Member Posts: 651 Pro
edited October 2024 in Building With Reaktor

I consolidated several sections or an ensemble inside a macro. I also removed audio ins and outs and converted them to events on all non audio sections. The macro ended up with around 30 output terminals which were attached to a core cell with all input set to event type. I also disconnected all send and receive module that use the audio clock and used more output terminals on the macro for a direct connection instead. After hooking it all back up the cpu went up from 60 percent to over 95 %. The only thing that makes sense is I put it all in a main macro and I have a feeling removing everything from the macro and pasting it into the ensembles main edit window, hooking the outs directly to a core cell the cpu will drop. I've seen this happen before and avoid macros in general. Anyone else experience higher cpu's when using macros?

Tagged:

Answers

  • colB
    colB Member Posts: 1,013 Guru

    All sounds very hazy to me. Feelings are not usually a good metric in programming, particularly in the context of a programmer's massive yet fragile ego!

    To find your error (or a problem with the language implementation - unlikely but possible!), do some systematic testing:

    *Create a simplified framework to test your hypothesis

    *Change one thing at a time

    *Don't always trust the per macro cpu metering (sometimes it gets added to the previous or next module in the chain)

    *make absolutely sure that things you think are functionally equivalent really are functionally equivalent

    It's good to apply common sense as well... a 'sanity check' if you will... Many folk have been developing using Reaktor for literally decades. Packaging code into macros is a very common process. Is it possible that in the probably 100s of 1000s of times this has been done, nobody noticed a 40% drop in cpu efficiency?

  • Studiowaves
    Studiowaves Member Posts: 651 Pro
    https://community.native-instruments.com/discussion/comment/5842#Comment_5842

    I agree, Intend to look this over real good.

  • Studiowaves
    Studiowaves Member Posts: 651 Pro
    https://community.native-instruments.com/discussion/comment/5842#Comment_5842

    Yep, the macro's do seem to add a tad of extra cpu when they have minute code in them and a lot of voices to amplify the subtle difference. I used the event counter and tapped around looking for something. I had a module running rampid with events. After I got that fixed with modulation macros things were better. But I did discover that trying to use audio events with "enable audio events" turned on to get a module to work with event outputs is not much. I can reduce static power draw with an event stp filter but it seems possible using straight audio ports actually uses less cpu when the ports are running constantly. I haven't full verified it but I had some overloads with event ports trying to handle audio but not with straight audio ports. The main problem though causing a 40 percent difference was an up front audio stream of events {almost} thas suppose tp be 1 event per midi note. This caused a downflow stream that triggered several modules and they were also running rampid. I was pretty tired , no, it's not the macro in this case.

This discussion has been closed.
Back To Top

Categories