OMega 3 Workstation YouTube tutorial

By 'it' I mean this symptom: Sound stops - volume is at max, but snapshot changes are continuing. Display is changing and the instruments are running. Turn off Reaktor and go in Edit mode.

Find the NAN and discover it is always after a filter. In most cases these are Primary filters. But changing to Core filters from the library don't change the problem.

In the past, the problem occurred maybe once every 8 hours. That would be say in Reaktor 6.1 or whatever was out a few years ago.
Last year with 6.2, or whatever it was, I did not notice any drastic change. With 6.3, perhaps more frequent. Same problem areas, same symptoms.
With 6.4, a bit more serious, same problem, same symptoms.

The affected macros were probably all originally written in Reaktor 5 and most were changed for OMega a few years ago, if at all. Many parts are unchanged from the 'rb_macros' originals.

 

I always thought that the Primary Filters had the necessary denormalization built into whatever internal feedbacks it may have, if that is the problem. Denormalization usually occurs in floating point decay times and for small values. Typically in decaying feedback loops that never quite get to 0.000000. A denormalization interrupt in the CPU causes a massive microcode spasm that uses hundreds of CPU cycles, or whatever. Primary, of course, does have a DNC cancel macro which has been used here and there in feedback loops, but not universally.

Anyway, changing to Core filters did not change a thing.

The NAN's only first appear directly at the filter output and continue on down the chain. The filter inputs appear normal, but the bad actor has long disappeared.

This is not a 6.4 problem at its root, it was there as long as I can remember. And it is not unique to OMega and its parts. One of the Metaphysical Function ensembles I made that does similar snapshot changes also shows this problem in the reschord macro.

And, as I said, the most common culprit these days is SpaceMaster's diffuser delay macro filters.

 

Here is a video I just made. This one occurred about 15 minutes into the test run. I stopped it as soon as I heard the pop and showed what I found.

 

Then doesn't it follow that the core filters in question might benefit by adding a DN Cancel just prior to output?

 

Per my last post:

 

I see there are a lot of 'bad numbers' seemingly coming from different places. Is there a single source, or has something how proliferated the NaNs?

 

I understand what you are saying, but I don't follow the logic. DNC will not change a NAN to a number, it will change something like 10**-38 to 10**-18 to prevent denormalization processes in the CPU.

This last example I posted above in the video did not involve filters at all, it was a multiply operation. The right channel audio is usually non-inverting and the bottom multiplier is +1, but there are a few presets where the bottom is -1 to invert. There are no other possible values

 

The NANs propagate, so one must follow the money back to where they no longer occur.

The earliest case was the multiply on the channel inverter.

 

You can try this test for yourself. Turn on the three snapshot travelers and set the randomness to 100.

 

whether in core or primary, the most likely implementation of DNC will be:

32-bit float:

out = 10**-20 + in

64-bit float:

out = 10**-120 + in

or something like that. I don't know what constant they would use, there are probably audio standards for that. But this is the idea.

So when an input falls into the denormal range, this will snap them back into normalcy with little impact on the floating point value.

The only way this involves NAN is when you divide by small numbers and threaten division by zero.

Both PC and Mac use Intel CPUs at the moment, so these both have the same FP unit. When the FP encounters a de-norm, it interrupts the CPU and the CPU firmware will fix up the de-norm. Something like that. Such a fix up uses a hundred or so CPU cycles, far, far more than a standard FP operation which may require a single cycle.

ARM processors, I believe us some sort of true zeroing, but my memory is foggy. It is different.

 

Here is an example of how DNC does not help.
In the video you will see a zero passing through DNC yielding 10**-100 to avoid problems with the divide by zero.
However, in the 64-bit floating Core macro, the power function does not work, it is at best a 32-bit approximation, so the exponent fails giving a NAN. The DNC after that has no impact.

The video is self-explanatory. I probably should fix that preset.

 

You're probably right about the difference between Core filter Nans and what is happening on your tests.
I thought that you were getting numbers that were too small for the number of bits, and that when that happens the CPU chokes on its inability to make 32-bit sense of it. Thus my thought was either use core filters configured for 64-bit or see if you can't get a number via DN Cancel that fits the 32 bits that Reaktor is using.
But now I think you are saying you can see that the values are not comprehensible as 32-bit anythings. Well, it's true if the value can't pretend to be any kind of (too small) number you can't very well add a small number to it to make it 32-bit sensible.
This sort of problem (something coming out of a multiplier that can be verified not to be a number, even if packed into 32 bits of float) is well outside my diagnostic abilities.

 

I can just sort of see what the debug display (hardly robust in its own right) is showing. So yes I get you. The DN Cancel is more a bandaid than something that safely navigates unsuspecting mariners through Scylla and Nan-rybdis. It can only provide comfort if the problem is a feedback loop output diminishing to the status of too small for the bit-fit.
What can you do now?

 

That particular snapshot in the SF bank has been changed now, but that is not the problem here. The snapshot bank I used was the 'Surreal Snaps' in the traveller when I test (at least it usually is) and these do not use the SF instrument. I try to keep them useful for most folk.
The 'Thanos Snaps' use the SF and are more CPU intensive.

If you remember from the video tutorial, I hit a snap glitch in the SF bank. It was probably that patch.

Most of the SF patches in the 'm1 ~= m2' SF bank were made using the desmos calculator to explore regions in the SF where very small parameter changes make for very large swings in the output. I find some points and save them for later. I have not explored very many of these in OMega 3 yet.

Desmos:
https://www.desmos.com/calculator/z2zkbjyqqa
(I think that is public)


What to do now is what I ask myself every time I get to this point.

Normally I would set a breakpoint in the code, or write an expression like

halt: if (abs(audio_val) > 20) then goto halt; // audio should never get this high - protect the ear

and recompile.

 

Have you had a chance to evaluate the panelset layouts yet?

 

I looked at them earlier this morning. Each of the instruments was (on my screen) in its usual place but all alone.
Which meant that I had to use scrollbars to find them just as I would have had to if they had all their brothers and sisters around them.
I can probably make some panelsets of my own for similar purposes if I can't figure out what I'm doing wrong.

More to the point at the moment is that I have decided to look at SupForm Delay by itself in the context of my own predilections.
I'm what my friends and I call a 'pitch freak'. I guess you could say I care deeply about pitches and rhythms first, when it comes to what excites me most about what the way music gets shaped. (But I have nothing against FX and other sound-shaping devices.)
So my touchstones are in classical music and the modernist composers who reinvigorated it (esp. Stravinsky, Bartok, Berg, Stockhausen, etc.).

Dropping SF into the latest pitch-based ensemble I've been working on, replacing Rounds Delay, has been instructive to say the least.
I think you've done tremendous work here, even if I focus only on the extraordinary capacities of your CPU-hungry delay!
Thank you for all those helpful and illuminating snapshots.
I find for my purposes that modulating a lot of the knobs is less good than simply moving them to a different setting and leaving them there for a while to hear what they can do. (I don't like having my pitches wobble around!)
My thoughts rested briefly on the possibility of seeing if the Rounds Delay's Grain algorithm might mitigate the pitch wobble, but thought better of it as there is already so much to play with in the snaps as you've done them.
I will report back in a bit with more specific findings, but you can take some solace in knowing that your work on SF has definitely landed solidly with someone who takes its musical possibilities (comb filter effects, beautiful timbral subtleties rather than lots of overflowing repetitions) very seriously!
More soon...

 

Huh????!!!!! That is absolutely not supposed to happen.

I put each instrument or small group all by itself in the upper left so that it would fit in an HD display.

Here is a 10 second video showing each of the panelsets as I made them.

Maybe this is a MAC/PC thing?

Anyway move them into the corner and save them.

 

That was my plan. It's not a big deal anyway, though panelsets of the expected LH corner type will help.

Meanwhile I'm having great fun with SF.
'Spectralizer' and 'Spacializer' come to mind. There is a subtlety to this 'delay' that I'm sure I've never encountered before, at least consciously.
It has now, already, a permanent place in my favorites list of FX of any kind. The words 'enhancer' and 'enchanter' and the like get bandied about for certain effects, and they definitely apply to your wonderful instrument.
I'll attach a short clip of audio later on after I capture some. I have an ensemble that is distinctly 'plucky' that SF is adding just some other-worldly qualities to, though I tend to use absolutely as little as possible to keep the 'effect' from being something one consciously remarks.
What to say except: many thanks for your work!

 

Thanks.

Originally I had 10 stages in that, but probably no one would ever find a use for the higher ones, so I dropped it down to 5. The 10 stages were mostly focussed on acoustic dispersion effects.
Usually 2 or 3 stages is sufficient to get unusual timbres.
When using 5 stages and long delay times it is impossible to predict what is going on. Of course one must use very tiny modulation depths or everything goes to noise very quickly.
It is very hard to manage its properties usefully and all I can suggest is that it is an exploratory tool.
It requires a lot of patience, as does just about everything in building for Reaktor I guess.
Sound exploration is what mainly interests me.

Many of the 'm1=~m2' library settings are carefully chosen to mathematically interesting spots in the graph - spots of high density and extreme sensitivity to small changes. I made it 64-bit precisely to focus on these small areas and I was disappointed that Core isn't truly 64-bit floating point.
And changing core macros is extremely painful because Core crashes so often in edit mode and frequently hibernates inside the compiler for 10 minute intervals.

The desmos site I posted above was used to find these spots and I have found that the Reaktor GUI matches the desmos graphic, so it validated the algorithm to my standards. Find something that looks like it may be useful and then transfer the m,n,a,b parameters and start exploring.
There are some built-in limits, like 10 seconds of delay memory, etc., and some protection against division by 0, but it isn't foolproof. So it must be reset when choosing some points in the n1 and n2 parameters that cross from positive to negative through 0 during modulations.

I also had the SF in stereo, but that did not seem too useful.

For me, I always struggle with simplicity versus complexity. I like sonic clarity but I also like a little imprecise pitch smearing. I am not interested in metric sync at all nor in repetition.

If you make any presets for any of the instruments, or find some interesting affects to add from the newer Reaktor libraries, I'd be happy to add them in. As you probably know, most of the stuff inside dates back to Reaktor 5.

It is easy to add more effects and inserts, mostly just copying a lot of wires and adding another selector. As long as it fits in the stack macro area. But since Blocks are instruments, adding them requires GUI panel space which is at a premium.

 

Here is an earlier version of SF in 32-bit mode as a block.
It does not have the m2 parameter, so all the delay time curves are symmetric, and it is easier on the CPU.
This is the last version I made for Blocks and the last for 32-bit mode, so maybe the Core compiler is happier.
It was probably compiled in Reaktor 6.0 or 6.1. so it might have better initialization responses.

A similar Block is added as well. It uses the same band-splitting architecture as SF, but uses manual delay times. It is better suited as a static delay line effect.

Whoah!!

I just noticed that Reaktor has new startup modes!! I *always* start Reaktor and open an ensemble from the browser panel. But just now I started it by clicking on these blocks and it is pretty hard to figure out what just happened! I am really behind the times.

I wonder if that is the problem you are having? It looks as if 6.4 initializes itself to play Racks. I have a 'New.ens' that starts with an empty ensemble and never use Racks. It just opened the block instrument ism file as an nksr file.

Racks do not support the automatic panel layout which is an immediate disqualification for me. I have no idea how panelsets might behave in the rack environment. And racks only make presets, right? A big turn-off for me.

I am not in favor of this direction NI has been taking Reaktor.

Maybe you need to put these in your user library and open them into an empty ensemble to see how I made them.
The same may be true for the OMega3 stuff. If panel layouts are disabled and instrument placement is removed you will have issues moving my 3440x1440 placements to your screen dimensions.