Serious reaktor crash when trying to delete gui elements

gentleclockdivider

Select all the modules as shown in the screenshot , and press delete
The modules will be deleted
Now go to the gui panel and drag a marquee around all the controls at the right ,( the marquee will not be shown because the macro frame is set to none , but that's not the bug )

Now press delete , reaktor will crash
Here's the ensemble to try it with

gentleclockdivider

I also have encountered some more serious bug

While pressing cut-paste , only a portion of the modules are pasted and in some cases making the ensemble corrupt

The above bug can be 100% reproduced , not really expecting a fix …

gentleclockdivider

Even more weird , I can't make the macro smaller , there are no gui elements at the right side of he macro ,yet it remains big

gentleclockdivider

Nevermind about the last issue , solved
First bug report is still valid

colB

you didn't attach the ensemble

gentleclockdivider

https://community.native-instruments.com/discussion/comment/201487#Comment_201487

2op-back up.ens

Here it is

colB

Yes its a strange one, likely some sort of existing corruption somewhere in the structure.

…you don't need to delete as much of the structure to create the issue, just the envelope, or the multiply that applies it… or even just the wire to the G port (or A, D or R)…

…hmmm, just deleting - or even muting - the outputs then deleting the GUI elements causes the crash, so that's interesting.

colB

I've isolated it pretty much now. It's not a corrupt file, so that's a relief.

If anyone reading could please test and report to be sure, that would be great.

Open Reaktor, create a new ensemble, and build this structure.

The only parameter that must be changed from default is in the Multi-display where you need to switch 'Always Active' on.

The multiply is just protection to ensure the output stays at zero.

In the edit pane, delete the outputs, and then select both the mouse area, and the multi-display, and hit del. The crash will happen.

I Always Active is off in the multi display, then there is not problem.

If you turn off write-thru for the snap value, then it also stops the crash.

You can replace the mouse area with a knob, and probably other things, and the crash still occurs.

I haven't yet found anything that can replace the Multi-display that still crashes.

An order module seems to be a workaround:

Get the order right though, this alternative will still exhibit the problem:

As an aside, this is why you need to be explicit and use order modules everywhere in Primary. When two wires come from the same port problems can occur!

Without an explicit order module, you cannot know which path will be processed first, the actual order is arbitrary, and can even change depending on edits elsewhere, or edits within the local structure. I had some trouble finding the source of the bug, because sometimes when editing to remove unrelated code, it would magically 'fix' itself, and then be broken again for no apparent reason!

In this case, one could potentially build this and have it work, then later start getting problem because the arbitrary order has changed.

(still shouldn't crash though :-))

gentleclockdivider

Good work col-b

I use the order module when it's def. needed , when precise event processing is needed .

In this case , not using the order module would just result in the multidisplay update an event later or earlier , which I don't consider an issue since it's hardly noticeable and not audio related .

The crash , resulting from deleting the gui elements ( and not using the order ) is not something I would have expected .
I consider this a bug , deleting gui elements

colB

yep, definitely a serious bug.

Arbitrary processing order in Primary just made it harder to track down - that's bad.