1. Please do not install macOS 10.15 Catalina yet, as Native Instruments software and hardware products are not supported under macOS 10.15 yet. For more info, please go HERE!
    Dismiss Notice

REAKTOR RIDDLES

Discussion in 'REAKTOR' started by herw, Nov 10, 2015.

  1. Aaron McPherson

    Aaron McPherson NI Product Owner

    Messages:
    98
    I think I've solved part a, but I can't seem to find the source of the "0" event that keeps cropping up. Here's what I have so far:
    In order to set c# to 1, I changed the routing in the init container macro so that instead of pulling from the router, the c# output pulls from the mod + a macro:
    R8_3 init container.PNG
    Otherwise, the messages come out: {0,2,0,5}, {0,2,1,4},{0,2,2,0.37}...etc.
    In the new {e} mux macro, I hooked up the panel elements as before, only inside I use value macros to pull the correct values for c# and the number of values (2) whenever a panel event comes through one of the ports. Then I pull the id from the index value [] and pass the event value through.
    R8_3 emux.PNG
    Since the proper order of the outputs is preserved into the merge, you get properly formed event messages:
    R8_3 ACEW.PNG
    It seems to work as specified, but yes, I do need a hint as to where that stray 0 is coming from.
     
  2. herw

    herw NI Product Owner

    Messages:
    6,373
    Solution A is correct especially the use of latch-modules.
    It is necessary to use latch-modules because c# and #=2 are only sent at initialization. So you get the whole 4-tupel now whenever you change a panel element. The parameter [] don't need a latch as it is synchronous to $ from input merge 10 macro.

    But i hope that you see the necessary to avoid the initialization value 0. Otherwise you would get an incorrect initialization on loading or re-init the ensemble.
    Hints:
    first you see that the source of tha value 0 is inside core, because outside the corecell you get no 0. I often analyze wrong initialization by locating the macro or corecell where this happens (compare input 1 and 2 of ACEW primary). So the source is inside of the corecell.
    Now you have to go inside core:
    Use ACEW Sensor: (remember the ACEW_A1 output has to allow audio too)
    chapter_8_24_small.png
    You can place the Sensor inside the corecell where you want, but only one is allowed!
    Connect different sources (c#, [] and $). You see that the value $ is important:
    chapter_8_25_small.png

    But we have to go deeper. :)
    Now (again) read the very important thread R6 Initialization info. This is the moment you have to learn something about initialization!
    Many thanks to Mark Wadewitz aka Quietschboy!
    Download his pdf-file and print it. You will use it often now.


    So go deeper and compare several outputs of the core macro input merge 10.
    The init value 0 (yellow init) is sent before the messages {-1} and {-2} are initialized by the second order output (macro init ensemble).
    Look and search in the intialization-pdf-file! This is the hint!
    ciao herw

    I have corrected the pictures a little bit.

     
    Last edited: Nov 17, 2016
  3. herw

    herw NI Product Owner

    Messages:
    6,373
    First find the source, then an explanation and last how to avoid.
    Initialization is really hard to understand and believe me, sometimes i need days to find the source and an explanation. But i am learning more and more :) .
    If wished i can give another hint.
     
    Last edited: Oct 31, 2016
  4. herw

    herw NI Product Owner

    Messages:
    6,373
    seems to be too hard?
    Ok here is another hint:
    delete ACEW sensor and insert one level deeper into input merge 10 macro:
    Connect [] and $
    chapter_8_27_small.png
    you get:
    chapter_8_28_small.png
    What does it mean?
     
  5. Aaron McPherson

    Aaron McPherson NI Product Owner

    Messages:
    98
    From what I can tell, the empty core cell inports on the {e} mux macro- that is, numbers 5, 6, 7, 8, and 9 - are sending default 0 events upon initialization. The 9 appears in the ACEW because the ninth value macro is connected to the bottom input on the merge module, and so it takes priority over numbers 5, 6, 7, and 8. Looking at the partials framework version of the {e} mux macro, we see that there is actually a nested {e} mux macro, and before it a "reinitialize" macro which is simply a set of order modules.
    emux macro.PNG
    This suggests that we need a similar structure somewhere in our ensemble. As it happens, there is such a macro after the "panel" macro, called "post init". It seemed to me the simplest thing to do was to simply expand that macro so it had 10 inputs and outputs instead of 5, each with an order module, and connect the out ports to the core cell in ports like so.
    expanded post init.PNG
    Hence there are no empty inports, and the stray 0 goes away:
    R8_3 ACEW.PNG
    Let me know if I got it right!
     
    • Like Like x 1
  6. herw

    herw NI Product Owner

    Messages:
    6,373
    You are right:
    chapter_8_29_small.png
    That's one solution.
    Is it possible without adding order modules to find a solution insight the corecell? What happens when you delete (or disconnect) the corecell inputs 5, 6, 7, 8 and 9?
    chapter_8_31_small.png

    And add a switch module to your ensemble to test a soft reset (re-init)!
    chapter_8_30_small.png

    BTW: macros reinitialize and post init have identical structures.
     
    Last edited: Nov 6, 2016
    • Informative Informative x 1
  7. herw

    herw NI Product Owner

    Messages:
    6,373
    Well i don't want to protract this subject needlessly, so you get the same result, ...
    chapter_8_28_small.png
    ... but the source of the additional event changes: empty core macro input!
    chapter_8_26_small.png
    A non attractiv solution is to delete the deeper macro inputs until you delete the unnecessary merge inputs:
    chapter_8_32_small.png
    not simple because partials framework is made for universal usage.

    So the question is: how can we avoid the initialization without deleting the core macro inputs?
     
    Last edited: Nov 6, 2016
    • Informative Informative x 1
  8. herw

    herw NI Product Owner

    Messages:
    6,373
    Before i show you several core solutions a word to different initializations.
    From Mark's table you see that a re-power (REAKTOR off/on) is a full reset (hard reset, hard init), which means that core memory and primary values are deleted.
    When using a switch (list, etc.) you get only a soft reset (re-init), only implicit values (from knobs f.i.) will be sent. This behaviour is new in R6! Compare in initialization table (blue part)
    chapter_8_33_small.png
    You have to deactivate Reaktor 5 legacy. As partials framework is made with R5, this feature is activated!!!
    chapter_8_34_small.png

    If it is activated, the soft reset sends the unwished values too.
    chapter_8_35_small.png

    chapter_8_36_small.png

    If you load an ensemble there are two inits: full init and re-init but temporal separated:
    chapter_8_37_small.png

    I have to thank Mark for clarifying in endless discussions :)

    BUT there is a terrible pitfall!
    If you activate enable wire debugging you get the unwished initialization „edit core” although you are in R6-mode, but only for the actual corecell. So if you analyze, deactivate it.
    chapter_8_39_small.png

    chapter_8_38_small.png

    ciao herw
     
    Last edited: Nov 17, 2016
    • Informative Informative x 1
  9. herw

    herw NI Product Owner

    Messages:
    6,373
    so now a hint for the corecell solutions: there are two small useful core macros to avoid unwished initialization.
     
    Last edited: Nov 6, 2016
  10. Quietschboy

    Quietschboy NI Product Owner

    Messages:
    436
    Sorry, i don´t want to disturb this thread, but i just want to go back for short to what Aaron pointed to (post 226):
    This sounds quiet interesting to me, and i have to say that i overlooked this behaviour since Reaktor 5 (just tested, it´s the same):
    upload_2016-11-6_22-22-2.png

    So, in the first place, this says that you don´t need to take care about unconnected inports of the Partial Framework´s Primary Level "b_mux" and "e_mux" Macros (those with "reinitialize" or "post-init" Macros inside), and:
    The Order Module could be used in the same way for Primary Structures like the "suppress init" in Core.
    This suppresses Init events, if the Macro Inport is unconnected:
    upload_2016-11-6_22-34-58.png

    Of course, just to keep this in mind, with the Order Module outport 2, real init events coming from event sources would be delayed/shifted to "post init":
    upload_2016-11-6_22-39-13.png

    Thank´s alot Aaron!

    Edit:
    Init Table updated to R6 V3
    https://www.native-instruments.com/forum/threads/r6-initialization-info.268630/
    (and ACEW 4.0 seems to have a bug at Ens Load (not showing the outport 1 init event of the unconnected Order Module) the "Init Debugger 5.6" shows correct)
    Edit 07.11.16:
    ACEW bug fixed (in ACEW 4.1)
    https://www.native-instruments.com/de/reaktor-community/reaktor-user-library/entry/show/10125/
     
    Last edited: Nov 7, 2016
    • Informative Informative x 2
  11. herw

    herw NI Product Owner

    Messages:
    6,373
    :thumbsup:
    cool Coffee_3.gif
     
    Last edited: Nov 7, 2016
    • Like Like x 1
  12. herw

    herw NI Product Owner

    Messages:
    6,373
    Aaron has kept an eye on Max' documentation (multiplexing.pdf p. 31), good catch:

    chapter_8_40_verysmall.png

    Mark's updated table:
    chapter_8_41_small.png
     
    Last edited: Nov 7, 2016
    • Like Like x 1
  13. Aaron McPherson

    Aaron McPherson NI Product Owner

    Messages:
    98
    I had a look through the core library, and there seem to be two macros that would be relevant to our problem: "No Event" and "No Init". If you look inside the "No Init" macro, you see an interesting "ES" module; this is an event sensitive boolean module that only gives True if there is an actual event at the inport:
    no init.PNG
    Inserting a series of "No Init" macros between the inputs of the {e} mux macro and the inputs of the "input merge 10" macro seems to solve the problem:
    R8_3 no init solution.PNG
    R8_3 ACEW 2.PNG
    I guess I still like my original solution better because it doesn't require modifying partial framework macros and seems to be the same amount of work. I'm interested to hear your thoughts on the advantages and disadvantages of the two approaches.
     
  14. herw

    herw NI Product Owner

    Messages:
    6,373
    That's right but you can do it much more simple with only one no-init:
    chapter_8_42_small.png

    chapter_8_43_small.png

    As you need the latches this is a very small insertion.
    yes.
    Another solution is to use no-event:
    chapter_8_44_small.png

    chapter_8_45_small.png

    Mark mentioned this as suppress init:

    chapter_8_46_small.png

    So if you save this as indexed {e} mux, you can use a lower number of primary inputs or unconnected input etc..
    You can use what you like. Your solution is interesting because it lightens the special 2nd output of the order module.

    So although this subject is very dry, i think we (!) have learned much about initialization. I hope you (and me too) will never forget these posts.

    So now we can finish riddle 8_3. I will insert the postings into the documents and open our next riddle 8_4 next days (receiving indexed messages).
     
    Last edited: Nov 7, 2016
    • Like Like x 1
  15. herw

    herw NI Product Owner

    Messages:
    6,373
    in my modular x i am using reduced inputs ...

    chapter_8_47_small.png

    ... and bundles ...

    chapter_8_48_small.png

    ... and bundle distribution:

    chapter_8_49_small.png

    a little bit exaggerative gadget but i like it ;)
     
    • Like Like x 1
    • Informative Informative x 1
  16. herw

    herw NI Product Owner

    Messages:
    6,373
  17. herw

    herw NI Product Owner

    Messages:
    6,373
    sorry for delay - i had some problems on health grounds
     
  18. herw

    herw NI Product Owner

    Messages:
    6,373
    Hi,
    i am so sorry but i am still not able to do anything with REAKTOR :(

    ciao herw
     
  19. Aaron McPherson

    Aaron McPherson NI Product Owner

    Messages:
    98
    Sorry to hear that - I hope you feel better soon.
     
    • Like Like x 1
  20. herw

    herw NI Product Owner

    Messages:
    6,373
    I have uploaded a new Version 8.4 of REAKTOR RIDDLES.
    I have added a solution for riddle 8.3. I am not sure whether i had planned to show other solutions in November 2016. Have to read my own document after two months. Perhaps i will add the others later and update the document.
    For now i have added only a new riddle (8.4). It is the last riddle for use of partials framework for now.
    Chapter 9 will be about arrays in core (finally).
    So let me add some comments and questions to 8.4 in next post here.
     
    • Like Like x 1