Seemingly infinite loading times for big ensembles?

I have been working on a project in Reaktor for some Montbs now. Basically, it is an instrument that splits the input into an adjustable number of frequency bands, which then pass through an fx chain whith per-band adjustable parameters and per-band modulation possibilities. Obviously, this instrument has become quite big, and it contains many send/receive and ic send/receive modules. So when i load it into an empty ensemble in reaktor standalone, it takes about half a minute until it has finished loading. After loading, it works well (my efforts on keeping the cpu low pay off... ) However, whenever i try to save an ensemble that contains this instrument, and then load that ensemble in standalone or in a reaktor vst instance, it just freezes and seems to stay freezed forever. I have tried several things to get it working, but none of them really helped yet.

What exactly causes these extreme loading times and what can i try to get my instrument working inside a finished ensemble, so that it is easy to use inside a daw (ableton in my case)?

I have 8 gb of ram and a cpu which should work well.

I've been programming in reaktor for about a year now and have learned a lot about this amazing piece of software, however, i have never registered to this forum for whatever reason, i think i was just too lazy so this is my very first thread. please excuse my english... I hope, there is some of you reaktor gurus who have made similar experiences with big instruments and who have figured out how to solve this problem... the only comparable case i know is herw's ruhr synth, which seems to push the hardware of some computers to their limits... (by the way, great synth, herwig )

symq

 

have you updated to 5.8?

after saving turn Edit Mode off, and load the Ensemble with Edit Mose off.

sowari

 

Thanks for your reply.

yes, i am running Reaktor 5.8.0 on Windows 7 x64.

Okay, i've done that. (I also tried disabling event loops in the parent Ensemble as well as sorting and compressing the automation id's of that instrument, just in case...)

So after saving i restarted Reaktor and tried to load the Ensemble. It freezed for about 3 minutes while causing a cpu load of ~25% and using up 130 mb of RAM, according to the taskmanager. But finally it was there. So even if the loading time is still long and also way longer than the time it took to load the instrument into an empty ensemble, it works.
Isn't this a normal behaviour when handling big Instruments/Ensembles in Reaktor?

symq

 

The reason for long loading time of RUHR 1.0 was the high number of send synchronous macros from partials framework on an event bus. Every send synchronous macro use an iteration. The compiler has much to work. After removing unnecessary iterations (ca. 200?) and send synchronous macros the loading time is reduced from 90 seconds to 5 seconds in edit mode!
There seems to be several special situations where the compiler has difficulties to sort. There is no general solution but i think big ensembles shows these difficulties more than small. Perhaps you can find it when systematically deactivating special parts of your ensemble and watch the time change when saving and loading and optimizing step by step.

ciao herw

 

Thank you for that, i think you're right.

Actually, there IS a part in the instrument which caused the loading times to rise heavily. It's a 9x9 routing matrix built with switches. That means, there are 9 switches with 9 audio inputs for each stereo channel, routing the audio to each other. These switches are controlled by ic sends. When i began to connect these switches together, i could kinda see the times it took them to connect growing slowly.

The only problem now is my style of programming in Reaktor. Everything's a mess. I have just given up programming elegantly in primary but that's me chatting. Thank you for the reply, i'll remember this for my future projects.

 

That shouldn't be a problem. I am using a similar concept: IC-sends controls send-receive connections. RUHR f.i. uses more than 100 send sources and receives (and the limit is higher).
So that should not be the problem. To organize the connection is the „problem”.
So keep on thinking about it!

My thought was (several years ago): every (modulation) input „possesses” a specific source (send number). Every input (receive module) is controlled by its own IC-send. So the IC-send chooses the source. Nevertheless this is only a rudimentary description what is happening in RUHR but the principle.

ciao herw

 

Okay, so you do not think there is a difference between using send/receives or using switches for routing? Then, it must have to do with my bad, or rather untidy, event processing. E.g. i used about 50 send / receives as event busses to control single parameters on many voices simultaneously. There are many iterations and stuff going on, and i didn't always pay attention to the initialization.

I think i can remember that you come from Dresden, so as the rest of this post isn't really important, i'll just switch to german now, because it's easier for me to articulate
Also denke ich ist das Problem für mich soweit gelöst und ich sollte mir einfach mal angewöhnen, ein bisschen schöner zu programmieren anstatt einfach alles hinzuklatschen. Nochmals vielen Dank für die Antworten Ist gewissermaßen witzig mit einem förmlichen "Idol" von mir im Forum zu schreiben......
---
okay it was dortmund...
---
wie auch immer...

 

creating a big ensemble is a job of years! You can follow the whole history of my modular synth in DRF (German Reaktor Forum) on this thread with 372 postings and more than 48000 clicks since 2006. There are many old and new ideas and i like to discuss about REAKTOR.

ciao herw

 

I know that Reaktor really takes time. And i also think, although that "big" instrument of mine i talked about in this thread is really big, your modular synths are even way bigger... and then there might be the fact that i am a pupil who has the possibility to spend some hours each day on reaktor... I mean, I don't know how hard you are working on your projects...
anyway, i'm babbling again... I also like to share thoughts about reaktor and to discuss them, but as i said, this is just my second day here on the forums
whatever! reaktor is a neat piece of software...

 

After a bit of experimenting, i found out that all the event stuff doesn't affect the loading time in a significantly negative way. It's actually the audio routing i talked about earlier in this thread, which causes the long loading times. It's a routing matrix that defines the order of 9 different effect macros in their signal chain. Originally, i had 9 switches, each with 9 inputs on it, to route the audio signals. When i connected these switches to those macros, reaktor began to freeze for a short time every time i made a new connection. With the number of connections done, the amount of freezing time rised.
So now, i tried to make a similar routing matrix with send/receive modules. Same issue: The more connections i made between the sends/receives and the effect chain macros, the longer was the time it took reaktor to make the connection. It seems like the time it freezes rises exponentially with each connection. Maybe it's exponential because of the number of order combinations rising (e.g. when i have 4 effect macros connected, there theoretically are 4*4 routing possibilities. when i have 5 effect macros connected, there are 5*5... (okay, that's parabolic and not exponential...whatever...))
When i use selectors for the routing instead of switches or sends/receives, everything works well and there's no freezing. But selectors unnecessarily use up cpu, especially when the instrument has many voices.
By the way, these effect chain macros i talked about, which get routed into each other in a certain order, they also contain some switches and stuff...

So now i'm wondering why this behaviour exists and furthermore, how can i do my routing in an cpu-efficient way, but without getting those annoying long loading (and internal connecting) times?

 

you are not right: it is more than exponential:
n!=n·(n-1)·(n-2)·...·3·2·1 .
So the number of order combination of 4 sources is 4!=4·3·2·1=24, for 6 sources 6!=720 and 9!=362880 for 9 sources.

without any look into the structure there is no answer possible, so please load up here a screenshot which shows the principle how you are distributing and connecting the audio signals.
I have a guess that you are using send-receive in a wrong manner.

ciao herw

 

Okay my brain isn't that good in maths at 1 AM But i think it isn't the factorial of n, but n^n. Each receive has n possible states. For each state of the first receive, the second has its n individual states. So the first two receives have n*n states, the first three receives have n*n*n, and n receives should then have n^n possible combinations. However, i know that you have much more experience with routing, so i might be wrong.

Okay, but that doesn't really matter anyway. In the screenshot i'll upload with this post, you can see the inside structure of the macro i built. Inputs 1-8 are in event mode and control some ic sends. Inputs 9-16 are audio inputs which come from the different effect macros i have inside my instrument. They are connected to a row of send modules that i called busses. The input at the top isn't connected because reaktor would freeze for a long time if i connected it... Just imagine it was connected.
The outputs pass the audio to the effect macros again. As you can see, i have selected one of the receives. They have only a "use" number on the send modules, and the "Automatic Use of new Sends" property is unchecked. Each receive is controlled by one ic send. Each ic send is set to be "always active" and has max = 0 and min = 7. The event inputs feed numbers from 0 to 7 into the ic send modules to tell the receive modules underneath, which send to "possess".
I'm pretty sure my structure works. Still, my only problem is that freezing reaktor compiler or whatever thingie....

 

Oh, and please don't wonder why the audio outputs are called strange numbers. That's because i had even more effects macros some time ago, when the instrument wasn't finished... But the names of the outputs aren't important...
By the way, the instrument has an adjustable number of voices, so the receives and sends are polyphonic...

 

if you have connected any effect macro out to a send module why do you use inputs here again? Is there a wire harp too?

i don't know, how you lead the outputs to effect-macros again (your comment of n^n possible orders); do they have IC-send-controls-receive too?), perhaps this is problematic because there are long distributions to compile. How do you initialize the IC-sends (use snapvalue!)?
The whole construct of choosing send-receive by IC-send cannot be evaluated due to your screenshot.
Seems to be not simple.

ciao herw

 

Sorry for not replying for that long time, i was quite busy for the last weeks. But now i have solved the problem myself. It actually wasn't that hard.
There were two points which slowed down the loading times. The first one was a core cell which did a lot of event processing. It seems as it took the compiler a really huge time to compile that core cell. At least, when i loaded the instrument, there was that orange indicator at the cpu meter which shows that the core structure is being compiled, and that indicator just stood still for minutes. I'm not sure what exactly the problem was with that core cell, the event processing it contained was quite simple. But after i deleted it and implimented the same event processing in primary, everything worked well and the instrument loaded faster.
But there also was a second issue. As i have mentioned in posts from the past, i had lots of routing going on inside that instrument, with many switches and feedbacks. So i went through and tried to remove every unnecessary switch and btw do the routing with send/receives instead of switches... And after having done that, my instrument finally loads up in just a few seconds. Nevertheless i want to thank you for helping my fixing the issue