OMega 3 Workstation YouTube tutorial

I just uploaded a moderately detailed YouTube tutorial that shows how to make a snapshot for the Omega 3 Workstation in the User Library.
There are SD and HD versions ready, but the 4k version is still being processed by YouTube at the time of this writing.
The version of the ensemble that I saved in that video was uploaded to the UL just now.

The ensemble (version 3h) is available here:
https://www.native-instruments.com/en/reaktor-community/reaktor-user-library/entry/show/13415/

The video tutorial may be watched from this link:

 

Thanks, Jim!
Really glad you've given us such an in-depth look at your baby. Watching it now with great interest.

 

YouTube required over 1 day to transcode the 4K version - it is is now ready for viewing. I guess it goes through a lot of algorithms. The 4K version would be the only one that allows you to see the text.

It is very long (1.5 hours) and somewhat detailed - only a few will enjoy this sort of thing.

 

My screen is VGA 20" not 4k.

 

I don't mind the length at all. It is such a complex beast that without your help (sometimes even with it), I can't figure out how to make changes that I'm looking for. But I have been having a pretty crazy problem with Event Loops in a lot of Reaktor ensembles. Even with the Monark instrument I eventually shelled out good $$ for. And in Omega 3 I continually hit an Event Loop having to do with the Display Clock...
This happens even in Reaktor Standalone. See below. If you have any suggestions, they would be very welcome!


And the macro in question should be OK, but the 2 Value modules invite my curiosity:

 

Hi Catman. I am unable to reproduce such an event. I can't remember the last time I saw an event loop warning in any ensemble.

Maybe you can try Globally disabling event loops (I don't have that disabled) or disabling it at the macro level?



If you send me the snapshot I will try to debug it.

That multistep envelope gives me a lot of trouble, but usually I only see it getting 'stuck' or unresponsive. If you've spent any time at all looking through it, you might agree with me that it is quite involved.

I have gone through all the snapshots in my banks and none of them using the multistep envelope show this.

Since Reaktor 6.4 came out, I have found issues with MIDI notes, particularly note offs being ignored, I think. This behavior was not present in R 6.3. I have not isolated the issue except to find it just appeared in 6.4 in modules that have not been changed, literally, in decades (the polyphonic voice macros from James Walker Hall).

Version OMega3d in the U/L archive was compiled in R6.3.

When I test, I run the 'snapshot travellers' which randomly generate snapshots in various instruments. Over many hours of run time, I sometimes see NANs or INFs, but I have not usually been able to create a simple reproducible way to debug these.

I always try to keep this particular ensemble in excellent shape, so I take such things very seriously.

 

Sorry, Paule, I don't think this is something you can use very easily. 640x480 is hard to build for.

I don't think this is practical in HD either, for that matter.

I don't build for such users, but they can extract what they like and make ensembles for their size.

Scrolling around such a small screen on something this size would be agony.

Have you considered a modest upgrade? I don't know how this reviews, but the price seems nice. The one I use is 3440x1440 but this might do fine.

 

I'm glad to hear that. YouTube analytics from the first day showed me that 36 users watched it with an average view time of about 10 minutes.

 

Youtube section 640x480 at 4k, HD and SD quality:

 

With glases on my nose it isn't sharper.
So I build along my iOS.

 

The 4K version won't appear sharper unless you have a 2k or 4k monitor.
iOS may have a 4K screen, but is it a handheld? You also need a magnifying glass to make the fonts readable.
You choose the gear you like, as do I. Getting a big monitor was the best audio tool I ever bought.

 

You use an Apple machine, right? Since this is apparently trying to synchronize an update with DCLK, there may be a difference in the way Reaktor calculates the DCLK signal between PC and MAC.

Here is what I know about DCLK, and it is just a belief more than a knowledge. It is a signal that is updated irregularly when Reaktor feels the need to update the display. It may have a very low priority. It may be off when panels are hidden or VSTs are hidden in order to reduce display refresh.
It may have nothing in common, no sync, with the audio rate or the control rate clocks. I believe it is handled in an independent Reaktor thread.

In OMega, the performance display will show the rate, or rather two rates, because I have found (on my machine) that DCLK is either above or below 20 Hz. So I split it two ways and show the values above and below that.

This may be unique to each person's graphic driver, I don't know. (I use an NVIDIA 1080 Ti card).

Here is the logic:

 

Thanks, interesting. Yes I'm on a Mac Mini at this point (lack of AVX support on my 2012 Mac Pro was the 'unmoved mover' for the change).
On MacOs Catalina Apple appear to have let go their support for NVIDIA. There is apparently no current NVIDIA driver for the graphics card in the machine, so I can't test whether a driver change would get rid of all the bloody event-loop dialogs.
They appear to be totally 'benign', BTW.
And your conjectures about when and on what sort of whims these things fire is generally spot-on.
They didn't used to happen to me with any of the ensembles that cause them now, so maybe the cause is in what we've just been chewing over.
On one of my own blocks I get them at Init and once in a while on snapshot changes. Then, mysteriously, they settle down and go away.
Disappear entirely for 15 or 20 minutes. And then a few poke their heads in like they just remembered they had a job to do.
Sometimes the 'offender' is a Router in Primary, sometimes a Snap Value Array, or in Omega's case DCLK.
I will try to get further into the weeds and see if I can eliminate some of them. So far no real help from Reaktor Support, though I have sent them screenshots and they say they can't reproduce the problems.

 

I'm sure you do take these very seriously! Omega 3 is a very serious assemblage of instruments.
I'll try the event loop enabling to see what it does. I don't know about globally allowing them because from time to time there might be a 'real' one that would actually matter and allowing it might not be such a good idea.
Thanks for your help, and I'll keep you posted, because I really want to explore your lovingly curated ensemble.

 

As you are well aware, the init area of Reaktor is the source of so many problems. It is little understood and hard to debug and reproduce. As the ensemble gets more complex and with more switches and complex snapshots, the init time increases and become quite complex.

I increased the Control Rate in OMega3 to give things like this a bit more processing speed and I see the CPU hit on every init event clearly in that ensemble.

For myself, I used to have far fewer switches in OMega 1. When I first posted it many years ago, the vast number of people complained about the CPU. And back then it didn't have all those extra instruments like rachToys, Blue Grains and the SF bank.

So I added lots of switched parts, rewrote the rachToys to turn themselves off, etc.

In so many of my User Library postings from the past, the major complaint was CPU. So I relented on many things and worked very hard to optimize them for others.

I no longer do that. I make these things for myself, and I'm happy and gratified if others find them useful. I will fix bugs if I can, but I no longer address things like CPU, display size. look and feel, appearances, etc.

If you have a Bosendorfer, you have no right to complain that it won't fit in your bedroom.

When I upgraded to Reaktor 6.4 I noticed some changes, but nothing that was too concerning. One that I looked into was that occasionally the last note played on one snapshot played again after a new snapshot change. That had never happened before. I noticed that in those cases the MIDI NotePitch wasn't initialized to 0. It's last voice retained the last note played before the init. This rarely happened and I could not isolate it, so I just ignored it.

I suppose it was introduced in an attempt to fix this bug:


OMega uses a very large number of MIDI internal events, particularly in the rachToys. Maybe over a hundred:


And just the synth part has about 2400 panel elements (knobs and controllers, etc.), not to mention adding in all the other instruments:



So I imagine that the internal memory structures used by Reaktor are pretty heavily hit by this ensemble and there may be memory issues that it may run up against. An ensemble snapshot in this synth switches in 15 sub-instrument snapshots along with it, and many of those snapshots have banks. So every snapshot literally changes the whole world of OMega 3 and many instrument switches, routers, events, etc. will occur. If a user has a small amount of memory and a slow CPU, perhaps they are greatly impacted. Perhaps Macs and PCs do things differently, it wouldn't be the first time. When we get ARM Reaktor we can have a third opinion.

There are also 256 (some) very large samples in the sample maps, about 500MB in size. That probably doesn't help, either, since they stay memory-resident.

Some of the stacked macros contain stacked macros which contain stacked macros... So the display elements tend to be quite dynamic and may stress DCLK processing.

In short, this ensemble is quite stressful to humans and machines. But I think it is worth the fuss. I picked the name OMega in reference to the last letter in the Greek alphabet and a hint that it is the last tool I will ever need.

 

Thanks for the helpful comments.
I will continue to explore Omega 3 irrespective of silly interruptions by Reaktor programmers' zealousness.
The video is VERY helpful. My screen isn't big enough for all the instruments but right now that's nothing to worry about.
For what it's worth, here are my computer's specs, which you will have a better idea about their possible influence than I:

 

The Core i7 at 3.2 GHz is a little under what would be ideal. I think 4.2 gHz might be the lower limit I would feel comfortable using. I would find it a bummer not to be able to see everything at once and it would slow me down a lot. If you take out the Mastering limiter and Final Processor that might help.

Maybe you can delete some of the parts and re-arrange them to better suit what you like to do.

You could make panelsets with most instruments off, then make other panelsets with other parts in view.

For example:

Panelset 1: Just Omega Synth to make a patch
Panelset 2: MT seq and Spacemaster to test a melody and supply reverb
Panelset 3: rachtoys for when you want to explore
Panelset 4: Blue grains for when you want to explore further
Panelset 5: ensemble, mastering limiter and final processor (make a snapshot with limiter and final processor off) for final mix.

You can have 8 panelsets, each showing whichever instruments you like in whatever order or position you like. Just go to the panelset browser, turn instrument view on or off (or collapse the header), move them around, and save the panelset. Auto panel layout must be off, I think for that to work right.

I would be happy to make more videos on OMega 3 tutorials. They could be more focussed without the need for having an overview. For example, one on making those panelsets.

But so far only a few views; 30% of the viewers watch for less than 1 minute and the average time is about 10 minutes.

I didn't expect many views, but I imagined they would at least watch past the intro.

Maybe I should have warned that 4K viewing is advised.

 

Here is a version for you with several panelsets made. Select from the panelset browser menu to change the view and lay things out to fit your screen size.

EDIT: OOPS - I left it running a heavy snapshot, it may overload. I usually save it with a safe one.

EDIT2: Let me know if this works for you and I can make it a permanent part of the ens.

 

I had mentioned about the test method I use and I have found that Reaktor 6.4 seems to provoke this ensemble with issues more frequently than version 6.3. I have no idea why, but I have noticed one general failure that I can't track down yet. This happened before, but now somewhat more quickly.

If I run the 'snapshot travelers' - the three macros that randomize the snapshot for the instrument at various rates - the ensemble runs for maybe one hour before a failure. It use to be much rarer, Often I could run things overnight with no issues at a very high change rate. Now this happens quicker at slower snapshot change rates. Usually within a few hours.

The failure mode is always the same - a NAN (infinity) - from a filter.

The location may be anywhere, but naturally, it may be where there are more filters likely to be found.

I also noticed this in the Metaphysical Function ensemble.

Yesterday, I found it most likely to occur in the SpaceMaster reverb, in the early diffuser macros. This is relatively unchanged from the Reaktor Factory Library. Three times I saw this at the same spot.

Another common spot is inside one of the rachToys delays.

All of these featured Primary filter macros, so my first step in changing was to switch to an equivalent Core filter.

That made exactly no difference, and since this happens more frequently now, I have thought about why it may be happening.

The only thing that comes to mind is that the error may occur when a filter is changed quickly from two extreme settings - such as when at one moment it is set up with a cutoff of 200 Hz at resonance .98 and the next moment it sees a cutoff of 20kHz and a resonance of .4, for example. I would like to think that the Reaktor filters were stable under any conditions. I'm not talking about self-oscillation, this is an output value out of range. It may be +NAN or -NAN, I don't see any real preference.

There is no 'order' module for panel elements - I don't know how I can make sure that one control changes before or after another. I suppose that happens according the the panel element IDs.

There are smoothers in front of most of these panel elements, I think.

Perhaps the Control Rate setting is too high? Maybe that is sending events faster nowadays than it once did?

I could try changing that to test the idea, but I could also try making a test bench that randomly changes filter parameters and see what happens to the various filters.

This has never happened to me while actually playing a single snapshot, it only occurs while changing snapshots randomly. So that points to an init problem, a notoriously difficult area to troubleshoot in Reaktor. In other words, although there are many places where filters are dynamically changing inside a snapshot, I've never seen a failure while that happens.

EDIT: changing control rate from 1600 to 200 makes no difference to this problem. It seems to happen even more frequently.
EDIT2: a control rate of 3200 also makes little difference. But the display updates become erratic at this level.

 

You say 'it only occurs while changing snapshots randomly.', do you mean you can narrow the field of the problem down to random snapshot changes, or did you mean 'in the past'?
Is it possible to run the filters through a core cell that weeds out denormals? I see there are many filters, so that seems unlikely to be a viable solution however. If the NaN happens not at the filter output but at the next input, a reasonable assumption I think, the idea of removing denormals prior to passing the output to an input would at least be theoretically possible as a way to prevent the bad events from blowing everything sky high.
I DO believe that my event-loop problems came in with Reaktor 6.4 BTW.
Keep posting your test results? Thx
Edit: from core manual concerning denormals and other bad numbers:
'In order to mitigate the above problem, REAKTOR Core offers a DN Cancel Module whose pur- pose is to kill the denormals. In the current implementation it is done by adding a small value to the incoming signal.

• If the incoming value is within a typical signal value range (approximately above 10-10), then the addition of the denormal compensation value will not change the incoming value at all, due to the limited precision of the floating point.
  
  
• If the incoming value is lower (including the denormal range), it will be possibly modified, but, due to the limited precision of the floating point, will also never produce a denormal result.'