How would you erase event or audio table with a button?

Hi!

I've seen this question in one of threads and decided to make separate thread. I think there wasn't any User Library upload concerning this problem as well as it wasn't discussed on forum (I've found 2-3 threads where people mentioned this problem, but not the solution).

I've faced next problems.

Event Table. I haven't found any way to erase it except going through it again. Well, okay. I though that fastest source of speed inside Reaktor would be Sample Rate Clock that ticks every 1/SR.R. I've built short core cell, where I made counter with SR.C and Compare with Router modules for comparing with DX. It works great for WX position to erase, but, yes, Event Table has In input that is event input, that means it is controlled by Control Rate (don't forget about CList comments about that events aren't actually controlled by Control Rate, but in global sense they are). So, I've built Control Rate input in my core cell where I divide this Control Rate by SR.R - it worked. But, what if I want to use Event Table with 10000 values? It is going to be way slow, in case I won't set Control Rate to maximum value.

Audio table - seems to work better and faster, without Control Rate speed, because it accepts audio sources, not events.

Conclusion: seems like the best and the fastest way to erase table - our winner - draw mode (or use Audio Table instead of Event Table if it is possible).

Did I miss something or it is like this?

Ensemble attached.

 

According to the Reaktor manual the Iteration module fires all of its events before the next audio sample clock tick - so the events are faster than the sample rate clock. It should be possible to use the Iteration module to clear an event table between audio sample clock ticks.

 

use an ITERATOR (primary level) which is able to push SR.R/2 events in between two sample rate clocks.
So you will be able to erase hundrets of cells of an event table in 1/SR.R seconds! Try!

Gerald (cookiemonster) will post a similar more detailled answer soon.

ciao herw

@sorry PeterW i saw your post after posting.

 

This is not true, Event modules process events between audio sample clock ticks. All events generated within the ensemble complete their life within that same audio sample rate period.

Clist is correct, events are not controlled by the Control rate. Some modules generate events at the control rate but the events are all processed within the same audio sample rate period. Event processing it not restricted by the global control rate.
---

No worries.

 

:angry: I've forgotten about Iteration module again. Recently I've found out its unique features, when I got reply from cookiemonster on my previous thread. Sorry..

 

Well, the most important things have already been mentioned by now.
Hardly anything to add.
Maybe it´s the manual itself which causes confusion.
The decisive passage which is to be understood is the last paragraph of p.132 which indicates that the speed of event management is NOT limited to the Control Rate.
Indeed it is possible to have it even faster than the Sample Rate when using the Iteration module.

Alex,
please remember the part of the "most-often-value"-solution, in which the array has been resetted: The Iterator-construction does it inside one and the same clock cycle.

- At least it should do so. According to CList it is possible to send some hundreds of EVENTS inside one cycle into the cell.
If I do remember correctly it´s about 500 - 600 of them (don´t know if that´s possible via one and the same single input).

On PrimaryLevel things are a bit more comfortable.
There is a great thread in which again CList is discussing the maximum iterations that don´t disturb the audio output.
Unfortunately I can´t find it anymore. But if I remember correctly it was slightly less than half the Sample Rate. 22000 if Sample Rate is 44,1 kHz. Please correct me if I´m wrong.

The starting-point of your thread has been "le Syndicate"´s problem how to erase the data of an event table with 64 x 33 = 2112 cells, which is pretty well less than 22000.
Therefor it will be pretty well possible to achieve what he wants - unless the routine which is triggered by the iteration module is not too long.

What needs to be done ?
Find a construction having an iteration module at its`origin that delivers ALL necessary values (WX, WY, R) to the event table.
Additional hint: You will need to MERGE the normal writing action and the "erasing" action.

You´ve got time until tomorrow morning. Then I´ll post it by myself ;-)
Cheers, Gerald.

P.S.: Don´t worry, these things are not thaaaat simple.
But you are a fast learner and ambitious enough to handle it very soon.

P.P.S.: Part of that construction will be an overroll-Counter. Good luck, have fun !

 

There`s a good point to add a link to the page with the question about "delete the Table entry" mentioned from cookiemonster one text before.


Thanks for Help.


http://www.nativeinstruments.de/forum_us/showthread.php?t=84341&page=2



cheers,

le Syndicate

 

Thanks for your help guys! And sorry for forgetting about this magic module, Gerald. I'm the lucky one to have some parts of CList Essential Events PDF and many things are explained very good there, which I think should be included in official manual, as it lucks very useful and general information about events. I didn't have much time to read it whole tho, but I guess it's time to do it now. I still have one question (and sorry if you will have to repeat same again): Audio Table is still can't be erased with higher speed right, because it doesn't accept events, only audio, or did I miss something again? Thanks! And I'll try to implement solution with erasing 2-dimension table before Gerald is going to comment it.

 

I have solution for erasing whole table - both X & Y!

Gerald, please, take a look (ensemble attached). I'm not sure it's 100% right in terms of programming, but it works for table - erases both X & Y.

Here is my algorithm. First, for Iteration N I took value of DX * DY + DY. In my case it is 100 * 16 + 16 = 1616. You'll understand why later. When I press Clear XY button Iteration module starts to send events to ITR input of event core cell I've made. It checks if ITR divided by DX gives 0, and if it is true, then it strikes counter which adds 1 to WY output, while subtracts counter from WX output. When Iteration sends 0 again my counter resets. Looking at Event Watcher you'll see it works. What actually happens is following (making analyze in numbers):

WY = 0
WX = 0, 1, 2 .. 999 100
WY = 1
WX = 100 .. 199 200
WY = 2
WX = 200 .. 299 300
WY = 3

etc.

Yes, it repeats 1 step of WX, but I think it's okay as long as it works. Also, it doesn't send value of 0..DX to WX, but again as long as it works..

Practically I understand that's not the best solution, but probably after some fixes it could be?

 

Hi Alex,
you are right concerning the AudioTable.
Please give me some time to dig into your solution.
My knee is hurting really badly again today, so I am not really willing to concentrate right now. But I sware I will analyse it this evening.
Until later, best regards, Gerald.

 

Get well, hope it will be better soon!

 

nice; very, very nice !
Really, I`m not kidding.
I´d change the button to trigger mode, then there´d be no need for the separator.
Except that: Wonderful !
I will post two alternative solutions later. I´m quite excited which solution will be the most effective one concerning CPU.
The divide-modules might be a little hungry, but all the same your solution might be the best.
Chapeau !
´Til later, Gerald.

 

Thanks for compliments, Gerald! I also thought about improving modulo part for division - there is one in NI's library, probably it can be used to reduce CPU a little. Looking forward to your solution!

 

Reaktor is cruel.
Let me mention at least two reasons why:
- You can´t even sit on a toilet without thinking: "Is REALLY anything correct ?"
- You think you got it and afterwards you realize that there´s something missing.

While having a longer sitting ... it suddenly came up:
Sry, Alex, there are two mistakes in your structure, the second one is pretty serious:

- The erase action will only work once in your structure.
The OBC-chain which contains the y-rows has to be resetted, either after a reset or everytime time before it.
- Only the 0-row (the one that is displayed) will be erased correctly. What you want in your case is 16 times counting from 0 to 99. Yours is counting once from 0 to 1600.
What a pity !

Think about how to change that and you will have a nice solution.

Man, this knee is really aching.
`Til later, Gerald.

 

EXACTLY.. :lol:

Isn't it perfomed in my structure by Merge module between + and Write modules? I've looked WY output with Event Watcher and it shows values from 0..4 every time I press Clear button. Hm.. Do I need to recet OBC chain itself?

Yes, I corrected it now - I made independed counter for WX that counts from 0 to 99 and it resetted through Merge when it is equal to 100.

I will post picture of my structure when I get back home.

Thanks for your comments! And I really hope you'll feel better today!

 

Yes, you´re right. No need for further resetting.
Btw, I forgot about the Ini-Event problem at the Iteration-Input.
Your Seperator behind the button definetely makes sense.

... looking forward to see your corrected version.

I´ve posted two other versions.
Do you remember our all-beloved Master-Jedi CList talking about the PrimaryLevel-Eventsystem being at least as efficient as EventCore-Cells, if not even more efficient (please correct me someone if I got things wrong) ?
My version Nr. II seems to be a good example for that.
Cheers, Gerald.

 

Gerald, thanks for your versions! To tell you the truth I find your second solution the clearest and the easiest to understand and implement, however I'm core addict. I'm posting my solution - hope it works finally (checked it several times with EventWatcher - seems to work properly).

As for CPU usage and which solution is most efficient one, we have to check it out, but I think that all solutions take almost same CPU usage - at least they doesn't change it dramatically. And I've replaced modulo in my solution with NI's one, I hope it will take less CPU now.

Also I was wondering, because I've recently found out this space in my knowledges of tables so far: why do we keep range between 0..DX-1 and not between 0..DX? I was making a simple knob attached to WX input and 99 seems to be latest position, but not the last one. I have same question about DY, as we have outputs of 0..15 and not 0..16. Is it because we start from 0, not from 1? Thanks for your contribution!

 

I started to get to know reaktor well and build my own stuff with it about two years ago (after three years of just using UL ensembles). In the beginning I preferred Core to Primary, because i found the event processing more intuitive (especially the simultaneous event paradigm). After a while I felt forced to do some event processing in primary for processing table data in one clock cycle and programming GUI elements. Now i prefer primary, and only go into Core for audio work (playback ramps, granular stuff and the like), but not for event processing.

All this because I think it could be useful to you to force yourself to get to know primary as well as Core, Aleks.

As for the tables: DX gives you the number of table elements. They are adressed with a zero-based index, so if there's 16 elements, they count from 0 to 15.

Greets,

Nicolaas

 

Thanks Nicolaas. I knew it has to do something with 0-based element, I've asked to be sure in this. I'm too far from using Reaktor for two years - it's been..hm..3 months till I started to use it (4 months ago tried demo version, 3 months ago bought it). And yes thanks for your advice, I should definitely study all modules - but one thing is to study them, another is too apply right and at the right moment. I'm really happy to have such support here on forum and happy to share my thoughts, without these posts I wouldn't be on level I am now if I studied Reaktor myself only. But yes, I will try to stick more to primary, but together with core anyway. I will change my % priority to 60-70 primary, 40 core instead of 80 core, 20 primary. Thx!

 

Hi Alex,
had too nice an evening yesterday to engage in the Forum; sry.
Your ensemble is working now. Great !
You can see that very often there are lots of different ways that lead to the same happy result. I could even provide another one:
Leave the Iterator´s Inc-port unconnected and build an overroll-Counter inside a CoreCell. Done.
My first version was solely meant to show you another nice feature of the Iterator:
Its´ gate output. Very handy !
Nicolaas has already answered your question.
Surely you could handle the tables in a 1-based way in most cases. The waste of RAM which is induced that way is neglectable on modern machines.
But it´s not only a question of economy and style:
In case you wanted to load ntf-,xls- or whatever-files you were lost if you wouldn´t treat the tables in a 0-based way.
All the best for you, Gerald.