How to drive LEDs from an Event Table?

Hi everybody,

I'm right in the middle of my biggest Reaktor project so far and after some success I'm stuck. I'm trying to build a 16 step sequencer for my Akai LPD 8 which has only 8 LEDs. I want to have the upper row of 4 LEDs show the beats and the lower row the 16th steps, 4 steps for every beat.

So far, I've managed to have a light move through all of the steps. But in order to update the display of 16ths on every step I have to read values from my Event Table on every fourth step of the sequencer without disturbing the regular outputs that go to the sampler. Then, I have to send these to the four bottom LEDs so that they display the values in the Table and work independently from the moving light while still being able to be updated by note input.

I've read a lot about Events in Reaktor and I do understand a lot more than I did when I started 3 days ago but can't seem to find the right module(s) to put four values from the table in four Lamps and have them keep the values until one beat later or a user input. Also I don't know how to block the output from the table to the sampler until I've done my LED readout.

Can anyone give me some hints or point me to some useful examples in the user library that use LEDs to display Event Table data?

Thanks very much in advance,
Axl

 

What are the lights intended to indicate? I ask, because the simplest way to a solution is not always just to finish the way you've started it. Also, if you could post a screenshot it would help us understand the circuit.

 

I have 2 rows of 4 leds. That's the screen representation of my actual hardware (Akai LPD 8). I want a 16 step sequencer to do this:

top row led 1 lights up for the first 4 steps while the bottom 4 leds display the data (1 or 0) of x[0]...x[3] in the EventTable.

top row led 2 lights up for the second 4 steps while the bottom 4 leds display the data of x[4]...x[7] etc.

What I've managed so far is a moving light. It's in the LEDs Macro screenshot.

What I need is a way to read 4 values from the Table on every 4th step and make the bottom row leds show these four values, i.e. light up or not depending on the value in the Table. Of course, I don't want these values to be sent to the sampler or MIdi out or whatever I eventually gonna use.

PS: Is it just me, or is the text editor of the forum broken on Firefox 3.6.8 on Snow Leopard?

 

Well, I would probably use a level meter to display the beat number. It's a much smaller module count.

There's a module that outputs a fixed number of incremental counts when it gets one event on its input - sorry, I can't remember its name. With that, you could address your table and send the table values to the distributor modules. Since event values stick until another event comes along, you should be able to pulse this arrangement once per beat and update the LEDs.

Next thing you'll need is a way to ensure that your LED updates and actual sound triggers don't interact with each other. One way you could do it is to serially read out the LED signals as note triggers, using a Scanner module (opposite of a Distributor). Again, forgive me if I got the name wrong.

 

don't know if this will help - and you will need to update to 5.5.

you need to do some maths with the Lamps so that they trigger at different rates.

with my Ensemble, the Side Lamps Trigger on every 1/4 Beat whilst the other lamps trigger every 4 1/16th.

they are driven by a Clock not an Event Table.

there was a tiny Step sequencer there - hence the weird shape- but i have removed that.

you can of course make the lamps bigger/move them.

sowari

 

Thanks for the replies. I'm looking forward to try them out later this weekend.

Cheers,
Axl

 

Hi there

I've been offline today, but I took your screenshots with me and had a look over lunch... So here's a primary structure that I hope is going in the direction you want. Apologies if you know all of this already...

To make things easier in terms of wiring the event table, I used 2 tables sharing the same data (one for writing incoming MIDI data, one for reading out to the LEDs). To do this, I made one table, and saved its data into a .NTF file; then, I added a 2nd table and opened that same .NTF file as the data for the module. If you want a 3rd table to play the data out to MIDI, that's fine. Should save you some tangled connections.

Here's what the main macros do:

1/16th Clock starts with a Song Pos clock, stops it down from 96ths to 16ths and uses a Modulo module to limit its output to the range 0 ... 15.

1/4 Beats stops the 16ths down to 4ths, and drives the top row of LEDs with those (just like in your 1st screenshot).

MIDI Gate On takes incoming MIDI Gate signals, and filters out all the 0s (the Gate OFF messages). This might not be what you need, although it keeps the processing simple.

MIDI > Table writes the MIDI Gate On events to the "write" event table.

TABLE > LED reads a quarter of the "read" table, corresponding to the current 4th, and sends it on to the LEDs when either a 4th note signal arrives from 1/4 Beats, or there's a MIDI Gate On signal. This is where the complexity lives, to here's some more on how it works under the bonnet. From left to right:

Value module: when a MIDI gate signal comes in, sample the current 4th value (0 ... 3) and send it on to the...
Merge module: merge incoming clock 4th signals with those triggered by MIDI gate. So this module outputs the 4ths as they come in from the clock, plus a "reminder" of the current 4th value when a MIDI gate event arrives.
Order module: I might over-use these, but they guarantee that one branch of processing happens before another and I think help me understand the flow of an event process.
The 1st branch multiplies the 4th value by 4, so that 0 ... 3 becomes 0, 4, 8, 12. This defines a quadrant - 1 4th's worth - of the table, each quadrant is 4 cells, whose index starts at 0, or 4, etc.
The 2nd branch uses an Iterator:
* Incoming event triggers the number 0 (Value module) which goes into the Iterator.
* All in the space of a single audio clock tick, the numbers 0, 1, 2 and 3 come out of the Iterator, in sequence. into the 2nd Order module.
* 1st, each number sets the Pos input of a Router 1->M module (there's a redundant Distributor in there too - that can go, sorry, Distributors don't work in this context). * 2nd, each number's added to the value coming out of the * module, and sent first into the RX input of the table (to tell the table what cell we're interested in), then into R (to read the cell's value).​

Hope that's a start - good luck with it.

Dave

 

Now why can't we get NI documentation written like this?

Clear, concepts explained, useful.

 

Friday. I was avoiding day job work

 

Hi,

here's a little update:

First, thanks a lot for your ensemble, Dave. It has helped me a lot. Especially the shared data between Tables is a neat trick that I think has saved me from madness.

The other thing that I'm wondering about is the interation that reads out the values from the current four table indices and displays them. So, the order Module makes sure that the next iterator value does not get sent until the table spits out a value?

I have tried to add a midi output to this structure to send those values to the LPD8 but it doesn't work correctly. Some of the output is correct, some is not. Can someone spot the error?

Thanks for your patience.

 

Nevermind. I figured it out myself. I had to set all outgoing events from the table to the LEDs to 1 or zero. Now everything seems to be working. I'll do some more testing and cleaning up before uploading it.

Thanks again everybody. Before this, my Reaktor knowledge was pretty much non existant. Now, I'm at least getting more familiar with event processing on primary level. That's a start.

Cheers,
Axl

 

Hi there

Good work getting the ensemble to actually talk to the LPD!

Those two Order modules in your screenshot: the first one's there because I definitely want the "Pos" of the Router to be set before I send anything to it; otherwise, the wrong LED might be lit up. The second one's there because I definitely want to know I'm looking at the correct Event Table cell before I read out its value. So the 1st Order module achieves the instruction "Set the Router to access the correct LED... then trigger the Event Table read process". The 2nd Order module achieves the instruction "First move to a cell... then read its output".

They prevent the processing from potentially going out of sync, because in Reaktor Primary (Core's different) events always happen at different moments: only one event happens at a time. So the order in which they happen is important.