Is there anything like a global variable in reaktor?

Octaviu5
Octaviu5 MaxicoMember Posts: 43 Sine

Hello!

Is there anything that works as a global variable in reaktor?

Id like to be able to read from and write to an event table, from anywhere in my ensemble. without having to define lots and lots of ic modules in reaktor.


Does such thing exist?

Best Answer

  • colB
    colB Member Posts: 365 Saw
    Answer ✓

    You can create multiple instances of the same table in different parts of your structure. These work up to ensemble level!

    Process is something like

    Save the table in preferences and also choose backup withs structure. The use copy past to create instances that reference the same data/memory.

    This can be used for various 'tricks' and works with event and audio tables

Answers

  • colB
    colB Member Posts: 365 Saw
    Answer ✓

    You can create multiple instances of the same table in different parts of your structure. These work up to ensemble level!

    Process is something like

    Save the table in preferences and also choose backup withs structure. The use copy past to create instances that reference the same data/memory.

    This can be used for various 'tricks' and works with event and audio tables

  • Octaviu5
    Octaviu5 MaxicoMember Posts: 43 Sine

    wow! this is incredible.

    A few questions arise though.

    Do i need to keep the .ntf file in place?

    Is there any way in which this can become corrupt?

  • colB
    colB Member Posts: 365 Saw

    This used to be somewhat buggy (many years ago), but I think most of the associated crash bugs have been fixed over the years by NI.

    I'm pretty sure that you don't need the .ntf file in place as long as you have selected to 'backup with structure' in properties. Easy enough to test though!

    It may be good to keep the .ntf while in development, maybe you can use that to link tables instead of copy/paste... could help with workflow... I don't know though, because I've always used copy/paste for this approach.

    I've used it plenty though and it does always work!

    Last time I used the event table version was in an example ensemble I posted a few days ago - if it works for you, then that would prove that the .ntf is not required:

    I do always save my work first before trying to edit the properties/size of a table that has multiple instances, this used to be an easy way to crash Reaktor, but I think its more stable now - old habits die hard as they say :)

  • Octaviu5
    Octaviu5 MaxicoMember Posts: 43 Sine

    Thank you very much.

    You saved me of madness by way of having to create hundreds of ic connections.


    I wish reaktor had an actual "global variable" module.

    But this does the trick as well.

  • colB
    colB Member Posts: 365 Saw

    I wish reaktor had an actual "global variable" module.

    But this does the trick as well.

    I think most folk who know what a global variable is will be using the core layer where possible.

    In core, you can set up a constant (or anything else) at the top level, and attach it to a distribution scoped bus, then 'receive' that value/signal anywhere in the structure at any depth. Basically globals, but within that core cell only.

    You can also override distribution busses within a macro, so some control of scope (hence the title scoped busses)

  • Octaviu5
    Octaviu5 MaxicoMember Posts: 43 Sine

    Well, i mean, yes, probably.

    But i haven't explored core yet.

    Primary has been up to the task so far and i haven't really needed core.


    But i mean, probably i should look into it in the future, because it will probably give me much better performance.

  • colB
    colB Member Posts: 365 Saw

    i should look into it in the future, because it will probably give me much better performance.

    Not necessarily. Performance can be better using Primary for some things.

    Core allows you to implement (many) things that would just be impractical or impossible in Primary. It's also much better from a workflow perspective.

    I would suggest that the longer spend learning Primary without also learning core, the harder it will be to learn core!

  • ZooTooK
    ZooTooK Member Posts: 3 Sine

    "I would suggest that the longer spend learning Primary without also learning core, the harder it will be to learn core!"


    And you are tell me this now! I'm soo f....d ;-)

  • ANDREW221231
    ANDREW221231 Member Posts: 253 Saw

    my polyphonic pitch detection started out happily in a monophonic core cell, but it needed to process itself with itself an indeterminate number of times, not sure if it would have ever been impossible in core or just prohibitively unpractical


    the killer feature here is being able to write to a mono table and open it up in another instrument with 20 voices because something needs to be done with it 20(ish) times. its not just that its handy for that, but information needed to be able to propagate laterally across the processes for some things, and global event tables is the only way excelling at the kind of voice management simply not possible in core


    this all actually had to be done twice, everything on the second instrument got packed into another global event table to yet another (final) deeper instrument, this time 80 voices, as it is fact that the only way to get polyphonic midi out is w/ one note per voice


    the main issue with doing it in core is it all had to happen dynamically, as in what happened on voice 2 in one tick might be on voice six for the next, so if a detection event (which will absolutely need ti end up on, say, voice 20 in the final stage) will be on another voice before it can send an off pulse for the detection, everything will hang, nothing will ever turn off. so not only do you not know where it will go next, but also it requires keeping track and following it after it does


    in core there's just no sending things around willy nilly like that, if something needs to go somewhere you need to build it a way to get there. cant think of many things that need this level of unrestricted information throughput/routing. but another one was a chord detector from midi input that never quite worked, but same thing basically: "load it up one way then send wherever" which limits the truly wild stuff (at least that i've built) squarely in the domain of primary ftw, at least for those crucial steps

    if anyone's wondering what that looks like LOL


    ofc its bad news if either of these ever have to be made visible in the panel for any reason, but for everything happening it runs relatively light and pretty stable. have to assume its probably not technically threadsafe? but as far as a stress test for failure modes of global tables nothing catastrophic has ever happened, (save maybe from deleting something while running, and also avoid event feedback, its never necessary anyway when another client of the table can be used instead)


    and as to how well the thing actually works, well it detects fundamental frequencies and not incidental fret noise, or "maybe a pitch" like others, and much of that is down to using tables in this way (sharing information like some american three letter agencies). even one of the final processes that's written to a polyphonic table gets shared back to the beginning monophonic core cell to help prep its for detection


    to @Octaviu5 question

    Do i need to keep the .ntf file in place?

    so, to get multiple clients the table must be saved first, but only as a formality, the trick is after saving pointlessly, always select "backup with structure" immediately afterward. a bit annoying but not quite as annoying as forgetting the ensemble depends on a local file reference and then trying to send it to someone, the table will zero initialize and lose all set parameters

    .

  • ANDREW221231
    ANDREW221231 Member Posts: 253 Saw

    also to balance out what i just said, primary is better for polyphony, voice management, and global event tables. core is better for literally everything else. especially anything complicated i recommend everything possible in core and then primary only if requiring one if its quirky advantages

  • ANDREW221231
    ANDREW221231 Member Posts: 253 Saw

    fwiw i disagree with that entirely . core is just primary but everythig can be disassembled into 'atoms' and everything dumb about how primary works, works instead how one would want it to. very confused by the idea they're that different, which a lot of people seem to share. the basic principles are pretty interchangable and the ones that aren't can be understood as facts immediately


    the memory arrays a bit fiddly to someone used to primary tables but aside from that its just little things here and there

  • colB
    colB Member Posts: 365 Saw

    The event model is fundamentally different. That's what makes core better for those that like it, but also really quite tricky for some users who have spent a lot of time with Primary.

    Primary's depth first event system means that some things have to be handled quite differently (and some things only work 'as if by magic'). Core's logical simultaneity system means that some things that you can ignore in Primary need special rules - like merges for example.

    You really have to manage event order carefully in Primary, and if you've spent some years doing that, I imagine it's quite alien to switch to an environment where there are no tools for that purpose! because it's completely unnecessary... but how can that be possible?! Some folk get it, and some don't. For that second group, it is a problem, because a significant part of their mental model of how to code up an idea doesn't work any more. Something integral to their whole approach is now just gone.

    Maybe the idea that the wires are like pipes with sound/signals flowing through them works better primary (or something) but not so well in core... there are probably other mental analogies that different folk have. Some will work just fine in core, other will not.

    There is also the distinction between audio and events in Primary. In core that's another thing that's just gone - completely missing. Again easy for some to adjust to, and difficult for others... probably depending on their internal mental model of what's happening to the 'signals'

  • ANDREW221231
    ANDREW221231 Member Posts: 253 Saw

    Core's logical simultaneity system means that some things that you can ignore in Primary need special rules - like merges for example.


    yeah, that's the big one people seem to struggle with, which i'll never understand


    suppose i probably lucked out there, there was an UL old project Sparky, that recorded lo fi "audio" spectrographs by clocking filter envelopes at event rate, had it doing a bunch of extra ***** on top of that, comparing amplitudes inherently time sensitive as it was all ran off one clock, so learning how primary events are sequential plagued me, imagining what would go wrong if this 'one after the other' fell on the wrong side of stuff that needed to happen together, so hearing about core i was instantly in


    yeah ig hadn't thought of that, suppise i defaulted to core but just got by in primary by crossing fingers and praying, designed as if it was in core then if something didn't work would just fiddle with the order module like guessing around in the dark but its seemed to work.. just the amount of added complexity having to think that way is uhhhhh unpleasant. gotta love those primary multiplies just stop working for some reason lol


    well whatever side one falls one... the really tough thing to model is what the h3ll happens to event streams that start in core, wind through primary a bit before ending up back in core. there's a fair bit of that in my pitch project mentioned above


    i mean it all works, but really how? think there was some headache getting it going, stuff that got wired up the same way but finally in some special correct order that primary blessed. iono, seems primary mostly handles index driven stuff well enough usually, the project actually is old enough to have random bits and bobs handled by primary before a transition back to core against all sane judgement or reason.. needs replaced eventually but seems to work enough to avoid messing with in the near term


    there was a time where everything going into this core cell was just piped in from all over (before learning about discontinuous clock events and merges) the function was to count harmonics but it kept counting impossibly high numbers. despair just about sunk in but the day was saved simply latching everything to the index piped directly from core back to core

    core problems are things like not realizing compare modules won't work correctly if both inputs aren't driven by the same clock, at least that's consistent and understandable... primary event streams are an unknowable horror but also sometimes work better than it seems they should?


    a great example is here where there was no other option but to manually combine all 20 voices of the output of a core event cell with fr. voice modules. the events were all triggered at different points of a running index across 20 voices, then piped straight into core as monophonic event signals, to be summed with naive core adds... how exactly this results in an outcome where if five of them fire a 1 over the course of this cycle, a sum of five is presented at the core cell's output... it almost seems like it shouldn't. i guess cause they're all ultimately from the same clock but man.... i feel i understand this whole process enough to be a prototype for rebuilding in some more proper development environment, it starts to seem possible some parts could well be 'right on accident' in ways that might not be reproducible in any straightforward way


    thankfully this basically the single point in the whole circus that's somewhat critical and has the two systems interfacing like this in a way possibly not well defined


    guess its better to think in core and deal with primary than it is to think in primary and deal with core because with primary you can always just juggle the handle lol

Back To Top