Serious reaktor crash when trying to delete gui elements

gentleclockdivider
gentleclockdivider Member Posts: 321 Advisor
in Reaktor

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

1.jpg 2.jpg

Comments

  • gentleclockdivider
    gentleclockdivider Member Posts: 321 Advisor
    edited January 1

    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
    gentleclockdivider Member Posts: 321 Advisor

    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

    image.png
  • gentleclockdivider
    gentleclockdivider Member Posts: 321 Advisor
    edited January 1

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

  • colB
    colB Member Posts: 1,097 Guru

    you didn't attach the ensemble

  • gentleclockdivider
    gentleclockdivider Member Posts: 321 Advisor
    https://community.native-instruments.com/discussion/comment/201487#Comment_201487
    2op-back up.ens

    Here it is

  • colB
    colB Member Posts: 1,097 Guru

    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
    colB Member Posts: 1,097 Guru

    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.

    image.png

    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:

    image.png

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

    image.png

    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!

    image.png

    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
    gentleclockdivider Member Posts: 321 Advisor

    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
    colB Member Posts: 1,097 Guru

    yep, definitely a serious bug.

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

Back To Top

Categories