How to shift an event table?

Octaviu5

I've been loking for some simple way to shift the values in an array.

like moving entry 0 to 1, and then 1 to 2 and so on and so forth.

but cant seem to find a simple way to do it which allows me to do this while my sequencer is playing.

Can you provide me with a suggestion?

Thank you very much.

Find more posts tagged with

Comments

colB

Your explanation is a bit vague.

You want to do this while the sequencer is playing, but do you mean one move per step... so on some step, you move entry 0 to entry 1, then on the next step, move 1 to 2 etc... Or do you mean that while the sequencer is playing, you hit a button, and all steps get shifted all at once?

What do you want to do with the edge case? so what goes to entry 0? what happens to the last entry?

Is this something where you don't even need to move any entries, just use an offset when accessing the array, and change the offset?

It really depends on more precise details about exactly what the desired functionality is! and what other functionality also depends on the array. So you need to provide a lot more detail :)

Octaviu5

https://community.native-instruments.com/discussion/comment/44140#Comment_44140

YES i actually discovered before going to bed.

I didnt know about the offset. It does exactly what i need.

Thank you. YES! offset!

Studiowaves

Yes, offset, indexes the array. Does Reaktor have a shift register by chance. Like a left or right shift, not that it matters.

Octaviu5

https://community.native-instruments.com/discussion/comment/44466#Comment_44466

I could def use something like that.

colB

https://community.native-instruments.com/discussion/comment/44466#Comment_44466

Reaktor has integer operations in the core layer, you can use right and left shift operations on ints.

As far as an 'Analogue Shift Register' like you might find as a hardware module, there isn't one in the factory library, but its a pretty easy thing to build. A good first project maybe.

It's basically just a chain of sample and hold units. You can build one using multiple instances of the factory sample and hold block...

Sample and hold is just a memory storage thing, so trivial to implement in core... just string them together and make sure you work backwards from last to first, when shifting/copying each time there is a gate/trigger.

So for a 4 stage S&H, set up four separate OBC lines, or a size 4 array, then when there is a trigger, copy 3 to 4, then 2 to 3, then 1 to 2, then input to 1, then update the outputs with the new stage values (or incorporate that into the copying process)... that's literally all there is to it.

Studiowaves

https://community.native-instruments.com/discussion/comment/44984#Comment_44984

Cool, I though I ran across some shift left/shift right module but couldn't fine it in the search using shift register.Guess I'll look under integer operations. Yeah, I can see stringing sample and holds. There's on module that holds the new and spits out the old. Think I used it during start up, I think you could initialize a value on its output memory and it held some other value from a knob or something that didn't thru put until it received a new event.

ANDREW221231

https://community.native-instruments.com/discussion/comment/44984#Comment_44984

yeah core dues index arrays like primary does polyphonic oscillators is what finally sold me on core some years ago

chainging audio tables like that will make them choke in short order while core can manage chain lengths until it becomes ridiculous seemingly nearly for free

must be the compiler optimizing all of it as a redundant part of the process?

ANDREW221231

https://community.native-instruments.com/discussion/comment/44986#Comment_44986

there are modules that do this, a user upload project

i think if you search 'peek' in the UL you would find it. i considered their use but never found a clear situation that fit their use . had many situations over the years where that i had some kind of problem and their use almost looked like a hammer

Studiowaves

Oh, I can see using it in some sort of sequencer but not really much else. Are you thinking of a peak detector. I think he was asking about shifting a binary number left or right. Maybe circling the out back to the in for sequence of highs and lows that repeats itself.

ANDREW221231

shifting an index is something i understand well, functionally my signature move. but the other thing you're describing i only know from here, and the only thing i know about is confusion and ultimately disapproval over its possible use

https://www.native-instruments.com/en/reaktor-community/reaktor-user-library/entry/show/10695/

like it looked interesting so checked it out, that was in service of trying to solve some ballpark related problem to what this purported to do, it looked promising but instead, on closer inspection, i just ended up getting pretty mad.

twice this happened if memory serves. like i get that its for holding stuff, but it doesn't seem like a good place to keep things. you push the button too many times and then what? the stuff gets pushed out of it? pulled into the void? they can only be redeemed that they fly out the back in order? cant see such a need for sequential items that instead of just like opening a drawer to look, you gotta push it enough times til everything is destroyed before you can even remember if something was in there you needed? or it if you lose count? when it said "danger of going out of bounds" that was it. if a tool or macro needs to be handing out warnings then, ya know, no thanks

think 'peek' might be the worst offender tho. if a bunch of items are occluded and i have to press a button to get a single reminder of what might be in it.. just display things where you can see... ig the real problem is the description only talks about how to use it and never why... leading to inspecting it at length enough to notice all this

seemed like something made because he knew how not necessarily because reaktor would ever need one. but if you know anything... not that i'll use it but wouldn't mind to know any reason its not stupid :p

anyway @ op

sounds like you want, not to read from an event table shifted by one at each step, but to actually have everything rewritten into the event table shifted back one at each step instead

not sure what the difference would be, but this could be done with two clients of a global event table. when you read it out have its output writing into another copy of itself but with the write index shifted by one

depending on the setup you may need to read out into a single client buffer so you can stage the payload so writing it is delayed and wont interrupt the read before its finished and then trigger an iterater after to read from that into the second copy

Quick links

Unanswered questions