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

Show IC Send source?

Discussion in 'Building With Reaktor' started by Bill Tribble, Sep 18, 2019.

  1. Bill Tribble

    Bill Tribble NI Product Owner

    Messages:
    221
    Any way I can track back and see where a send is coming from?
    Digging into old patches and I can't figure it out!
     
  2. Paule

    Paule NI Product Owner

    Messages:
    5,159
    Set IC-Send module in your structure to visible. Go back to the gui and click it to on.
    A long list appears with structure pathes. This path which is active carry a white dot on the left side.
    On the right side of the white dot is the path through the macros.

    If you build a send/ receive structure give the sends good names you can follow back.
    Name of the macro followed by the function? So you find in you receive list in properties the send names.

    In your headline you ask about IC-Send. In your post about send. This are two different methodes.
    IC-Send is for event only and can use also from one instrument to another.
    Send is inside one instrument but can carry event or audio datas.
     
    Last edited: Sep 18, 2019
    • Like Like x 1
  3. Bill Tribble

    Bill Tribble NI Product Owner

    Messages:
    221
    Awesome thanks Paule, I'll give this a go.

    I wish NI would sort out these basic things rather than add more and more crazy ass blocks stuff (fun though they are).

    I mean... how about a scaleable UI? Or 'encapsulation' (as Max).

    Heh. Anyhow, I don't suppose anyone from NI is reading. (shrugs)
     
  4. colB

    colB NI Product Owner

    Messages:
    3,014
    Not sure why we would need encapsulation (unless Max has redefined that in the usual way marketing types redefine existing words with precise domain specific meaning to cause confusion and ambiguity...)
    ...in Reaktor we don't have functions (or an equivalent) or a mechanism to declare/define new data types, so encapsulation would be pretty much impossible, and certainly irrelevant.

    I totally agree that NI need to clean up the mess of old Reaktor and provide modern replacements so we can ditch a lot of the clunky out of date Primary layer stuff.
    What about updates to the table framework so a 'canvas' can be passed in to core via table framework - that would allow UI stuff to be done in core.
    An extended table framework might also help with communicating between various modules - not quite a replacement for IC-send/receive, but a start...
    I suppose then we run into more compiler problems - so that's another thing that needs fixed...
     
  5. Bill Tribble

    Bill Tribble NI Product Owner

    Messages:
    221
    Sorry yeah 'encapsulation' is basically an 'instant macro' feature in Max. So I can select a load of stuff, select 'encapsulate' and it will add it all to a Macro and make all the 'ins' and 'outs' automatically. Saves tons of hassle when trying to neaten stuff up or organise things.

    Yeah lets have multi-core support and VST hosting while we're at it. Then I can properly dump Ableton!
     
  6. colB

    colB NI Product Owner

    Messages:
    3,014
    Ah, so yeah, reusing a word with a different meaning in a programming context :)
    I would prefer 'wrap' to avoid confusion... or better - macroize. There are issues here though, I suppose it would have to be a non-solid macro, otherwise things like z^-1 feedbacks would break, and possibly other stuff too. If they made Reaktor try to intelligently guess what you intended, you could end up with subtle changes in meaning and bugs as a consequence.

    This keep coming up - how would multi-core support work in Reaktor. I still don't get it, and still nobody has come up with a sensible concept for how it would be implemented so it would function in a Reaktor context. And yet people still keep demanding it.
    Does Max for Live have multi-core support? if so, how is it implemented (from a builder UI POV, not internally), what are the design compromises they followed that would translate to Reaktor?
     
  7. Bill Tribble

    Bill Tribble NI Product Owner

    Messages:
    221
    Multicore: you could do it like Bidule: Choose a core for each instrument or embedded VST.
     
    • Like Like x 1
  8. KoaN

    KoaN NI Product Owner

    Messages:
    147
    I am a big fan of Bidule.
    I remember in the past,several years ago i was considering using Bidule as a host,so i tested it in my setup to see how it would fare.
    The multicore function didn't turn out to work very good,it works well i think when your layout consists of straight lines in the modular view,line 1 assigned to cpu1,line 2 assigned to cpu2 etc. but as soon as things become interconnected and you have connections in between your lines,like you would in Reaktor, the CPU behavior became pretty chaotic and even worse,...so i ended up using Reaper as my main host.
    It seems the only way this would work is if you separate your line of modules from each other completely until they reach the outputs.