5.6.2 bugs

undo/redo stack still sucks. i just noticed setting to mono/poly doesn't work with undo/redo either.

the visible aspect of many modules is completely out of whack as far as i can tell. i just noticed you can set visible to 'on' in the shapers and envelopes. the shapers display just an empty screen with a line across the bottom no matter what you feed it. the envelopes don't really give an accurate view of the relative values of A, D and R.

 

the computer keyboard as MIDI input controller is still not working properly either.

examples of problems include:

when using ctrl-shift to play 2 octaves lower, none of the number keys play notes.

play note 48. then play note 72. then lift either of the notes and the MIDI Gate module will send out off messages for *both*.

for me one of the most frustrating aspects of reaktor is that simple problems like this are not considered important to fix (ctrl-shift didn't even work at all, for years) and it gives the whole program an overall feeling of jankiness sometimes. i spent 10 minutes wondering what i'd done to mess up the gate signals before realizing, no, it's just reaktor having another one of it's quirks.

 

here's an annoying one. in the attached image, the striped multidisplay seems to extend past it's borders, i've outlined the offending areas in red to make them more clear.

 

1) CTRL-Z (Undo) still doesn't work when Reaktor is used as VST instance. 2) Timing errors of Start/Stop and Song Position modules are still unfixed.

 

no key commands work in reaktor in VST mode, if i remember correctly.

 

snapshot master functionality has been reverted but still snapshots works differently compared to 5.6.0 and older.
Basically on older versions if you had an instrument inside another instrument and you save a snapshot on the outer instrument, values on the inner instrument was discarted, only the current used snaphot number of the inner instrument was saved on the outer instrument.
from 5.6.1 and newer if you save a snapshot on the outer instrument it keep tracks of all values of the inner intrument aswell, this has changed the behaviour of my livemachine and so i need to fix it, else everytime i change a snapshot on the inner instrument i have to modify all snapshots on the outer that was using that snapshot on the inner, as it remembers how it was before modifying it.
Basically snapshots on the inner instrument has become nearly useless.
to make it like before i must pull out the instrument from inside the other one and make a connection on snapshot module (that i've done already to workaround for 5.6.1), i only hope it will not create problems on snapshot changes as i need both instrument to change snapshot simultaneously...
hope is clear i've done my best to make it readable I'll let you know if i'll be able to workaround this change with no problems.

EDIT:i've noticed there is a "snapshot isolate" option on the instrument, enabling this on the inner instrument will isolate it from the outer one. By the way i have to add a snap value on the outer or change the inner snapshots from the outer then, because it's totally isolated so also the currently used inner snapshot number is not saved on the outer snapshot. I will probably be able to use it as before without pulling it out thanks to that "snapshot isolate" checkbox.

EDIT2:Ok i think i've found a bug now, i was trying to use snap value to fix the above changes and i've discovered a weird bug, look at the ensemble below where i've recreated the problem, try moving the knob, that actually changes the snapshoot on that instrument, in the other instruments the numeric readout changes accordingly, before and after the snap value module.
Instead, try changing the snapshot clicking on the snapshot names with the mouse, as you can see all numeric readout changes aswell, except the one after the snap value, that is crazy!
It looks like when i change snapshots using mouse the value is sent by the snapshot module but the snap value module doesn't recognize that, it's driving me mad but i think that's not my fault.

 

modules cap

i've found this problem in 5.6.0, honestly i don't know if it was present in older versions aswell.
the problem is that if you are making complex intruments there are some modules that stops working when you reach a certain number of that modules in the same instrument.
i've tried recreating the problem in the zip below.
try opening "complex AToE.ens", i've repeated the same macro several times, as you can see, after the 132th AtoE module all the following stops responding.
If you look at the oscillators, the one i've putted at first works, while the other i have duplicated after the macros is not working.
Unfortunately this is not only related to AtoE, there are other modules somewhat connected to this one and that are counted to reach that limit, to prove this try opening "complex systeminfo.ens", here i have duplicated a macro with a systeminfo+accumulator+numeric readout several times, as you can see i've reached that limit also here, after 264 system infos all the following stops working, but this is reflected also to AtoE, in fact the oscillator below doesn't works, even if there are only 2 AtoE modules in the entire ensemble.
On standard Reaktor developing i've reached this limit twice on 2 different ensembles, on the first one everything looked working but when i've saved then re-opened the project some AtoE stopped working, even if i had inserted them before the latest additions.
On the other one some midi out started responding erroneously after a paste with a complex macro.
The only workaround to this for now is to avoid using too much main level modules and try converting event operations in core cell as much as i can.
We need a fix for this, thanks.

 

Re-opening Logic sessions with large sample maps fails

Recalling ensembles with large sample maps in a Logic session crash Logic now.

Logic 9.1.5/OSX 10.5.8/Reaktor 5.6.2

For example, recalling:

http://co.native-instruments.com/index.php?id=userlibrary&type=0&ulbr=1&plview=detail&patchid=10973

crashes Logic until I 'hide' ensemble' from Logic BUT, then manually loading from that same session/instance still fails (in this case locks up Logic). I have to remove and re-insert Reaktor before I can successfully load in the ensemble again. Resaving this new session then begins cycle all over if I try to re-open session again. I have worked with large sample maps before and had not encountered this in re-opening those sessions with earlier versions though that could be all the way back to 5.6.0.

EDITL

I just verified problem with Logic 9.1.6/OSX 10.6.8 (still 32 bit mode).

The only difference is the ensemble (which in this test case I saved without map) brings up the dialog that samples are missing which it didn't on 10.5.8 system. AFTER 'cancel' (which means no sample map is loaded or was ever loaded) Logic still crashes so it seems to be the algorithm for reloading and not a memory problem BUT so far only happens for ensemble with sample maps (and the corresponding 'handler' for locating/loading/replacing map)?

Process: Logic Pro [6153]
Path: /Applications/Logic Pro.app/Contents/MacOS/Logic Pro
Identifier: com.apple.logic.pro
Version: 9.1.6 (1700.43)
Build Info: Logic-17004300~1
Code Type: X86 (Native)
Parent Process: launchd [110]

Date/Time: 2012-01-15 09:30:54.835 -0800
OS Version: Mac OS X 10.6.8 (10K549)
Report Version: 6

Interval Since Last Report: 573989 sec
Crashes Since Last Report: 20
Per-App Interval Since Last Report: 57669 sec
Per-App Crashes Since Last Report: 1
Anonymous UUID: 68299506-C13D-4B51-A9F9-DB55AE291E8E

Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000050
Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Application Specific Information:
abort() called

Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x927fac5a __kill + 10
1 libSystem.B.dylib 0x927fac4c kill$UNIX2003 + 32
2 libSystem.B.dylib 0x9288d5a5 raise + 26
3 libSystem.B.dylib 0x928a3679 __abort + 124
4 libSystem.B.dylib 0x928a36f5 abort_report_np + 0
5 com.apple.logic.pro 0x003e3b59 std:stream& TraceOutContainer<CEvs>(std:stream&, CEvs, char const*, int) +

 

Is that running as 32-bit or 64-bit? If 32 it may be memory-limited. The auralis map is about 1GB in size.

 

Sorry Jim, I deleted my reply because I needed to turn 'smiles' off but still couldn't with a new post then forum wouldn't let me leave a new reply so had to merge into previous message.

It seems it is something else other than map (and my map says '469.8' MB, does saving out map from older version as I did reduce bit size/quality?)

And mother F! I have been taken to the NI homepage over ten times just trying to post and research here this morning...your web designer needs to address this, sites that 'de-promote use through frustration should be refunded! The 'navigation' Flash crap takes TOO LONG to initialize!
---
Hey Jim...I just re-downloaded your map from recent link (in this thread), still 469.8 MB...is there something I am misunderstanding when you refer to the map being 'over 1 GB'?

 

There is a bug in the Snapshot-Morphing I think. Menus of Receive-Modules do not get morphed... they change when i click the Snapshots, but morphing is not possible.. that worked with the reaktor player-version which i had installed before..
now i have 5.6.2 and it doesnt work...

regards
carsten

 

the modulo module is inaccurate enough to be close to worthless. while using it to make (what should be) a very simple numeric display replacement i get all sort of weird behavior such as

300 div 100 = 2
300 mod 100 = 100

:/ come on.

EDIT - heh, my mistake, looks like values were .00000001 off from where they should have been... crazy.

 

I’ve found a bug in multiplier module arises during values conversions. This is really stupid mathematical error, which in particular macroses causes linear incorrect values accumulation, and serious errors as the result. I've prepared the test ensemble for demonstration of this bug, where works simple conversion 1 to 100. But if you try to manage Y-axis of an Event Table using converted values which should be 100 – there is an error that the cell 59 isn’t read, but the value from cell 60 is read instead. However, if you make this conversion multiplying 1 x 100.001, instead of 1 x 100 – all the Event Tables cells are read properly.
In my ensemble I store the values in the Event Table and these values are matched to properly converted values for easiest error finding. For example 0.01 x 100 = 1, and this value is matched to the value stored in the 1st cell. Thanks to this it’s easy to recognize which cells are skipped due to the error. In this particular case it is the cell 59 with the appropriate value 59 stored.
However, if you connect Numeric Readout to the multiplier, it shows that all is correctly. But this is not so in real !
By the way the same error is recognized if you manage Multipicture module converting the values by multiplier module – the values are skipped as well.

View attachment Multipler bug.zip

 

Haha, this is so lame bug indeed, it's very strange how NI didn't recognize it before releasing 5.6.2 ! :lol: By the way, when I set the knob to 0,59 in your test ENS - the value from cell 58 is read, not from cell 60 as it works for you.

Also there you can see very interesting things when convert type is set to 1x100.001, and if you slowly move the knob from min to max looking to numeric readout display.

P.S.
It seems salamanderanagram and Z Gabr talk about the same bug, meaning very poor math of 5.6.2.

 

UGH

and here is proof - REAKTOR math modules cannot be trusted, at all. apparently you must use a quantize module in any situation where you need to have access to an exact number.

i've modified z_gabr's ensemble to prove that there is indeed a mathematical error when performing the calculation

.59 * 100

the error is equal to .000003815

there are also errors when multiplying either .27 or .15 by 100.

is this just standard floating point error? seems a little too large for that but what do i know. also the amount of error is the same in 64-bit core and it seems 64-bit should be able to handle this.

I would REALLY like to hear from someone at NI about this. i've heard it said that they read this forum, but given the lack of response from them about any bugs for the last several years i find that hard to believe. if they are, please respond to this.

 

could you send a report to tech support please.

Edit: I did mention these emails elsewhere, hence the reply from Martijn below

sowari

 

The error seems not to be the math. More a typical 32 bit floating
point rounding error.

The mantissa of a 32 bit floating point consist of 23
bits that translates to little over 6 digits of precision.

you're right that 64 bit floating point has a way smaller error. However having a 64 bit CPU does not mean that reaktor now starts calculating in 64 bit floats. It does that still in 32 bit floats so ya get the same error...

Why some numbers seem to have more error than others have to do with that we are talking decimal numbers here where in the computer theres only binary numbers. Some decimal numbers can be represented more accurate than others in binary.

Be aware of the Index inputs of reactor classic table modules. in the case where interpolation is off the inputs are not rounded to nearest integer but they are truncated instead. than 58.999 turns in to 58 instead of 59. So if youre math has a verry small negative error ya might end up reading a table value of the previous index instead of the one ya wanted...

A way to avoid this is by adding 0.5 to the index than 58.999 + 0.5 becomes 59.499 and if ya turncate that ya get 59.

Greetings,

-Martijn-

 

Floating point numbers are in binary; 0.59, 0.27 and 0.15 are not exactly representable as binary floating point numbers.

http://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_conversion_and_rounding

I've also been up against some floating point problems recently. Try to convert a floating point number to a string of decimal integers in Reaktor in an exact way. It's extremely difficult! I wish I had access to Core modules that returned the sign, exponent and significand in integer format... Also, an iterator would really help!

 

hi martijn, thanks for explaining that. i was hoping there was some more benign explanation than what appeared to be going on.

it seems odd though, and i've posted a picture of what i'm talking about to be more clear.

if 59 cannot be represented in floating point without some amount of error, shouldn't both of the quantize modules spit out an error? the first one gives an error like before, the second one appears not to. IE after a quantize it does seem like the value is exactly 59, but if i'm understanding correctly, that's impossible.

 

I hope you noticed the same happens when using core multiplier as well. The suggestion of salamanderanagram to use quantize isn't too helpful in the structures with floats with many fractions.