Event retrigger methods

What is the best way to create event re-trigger for use in firing samples or triggering midi? I am a 1st week beginner, and I've found these options:

1. Iteration module, but it only gives you one resolution, frequency is iterations per-second and fixed in priorities.

2. Clock oscillator, using tempo info multiplied by integers to provide frequency (retrig rate). Hold can be used to hold it open for number of retrigs.

Is there a better way to create retrig rate and iterations relative to tempo? Is there a way to use a counter instead of a hold, so it shuts off after a certain set number of events instead of a time window? I'd rather have a counter instead of having to do the math converting tempo and current resolution into ms.

I'm inspired by the re-trigger function on Octatrack, it has a knob for set amount (number) of retrigs, and a knob for re-trigger time (resolution), but the time knob is related to current tempo, "1" is 1/16 note, "0.5" is 1/32 notes, "8" is 1/2 note, allowing triplets and quintuplets and other off grid in-between resolutions

 

Hello Bypassvalve!
Iteration is mainly meant for tasks that need to be processed in one rush, meaning as fast as possible. Nevertheless, it is possible to reduce the iteration speed in reaktor (to iterations per second), but i think that doesn´t match to your task and isn´t the maiin profession of iteration.

To achieve a simple finite repeating delay you are absolutely right using a counter for the number of repititions. The clock comes from the host, meaning tempo info module (EDIT: which isn´t a "clock"), or probably better for your task, the song position module´s outport "96e". 96e is nailed to the actual song position and gives you the number of 96th notes since song start - with each 96th note. Use a modulo module to break them down to the base note length of your delay´s need.
This is your clock. Don´t worry about high numbers that have to be divided, that´s ok.
Next step is to gate the clock events to trigger the counter only when they are allowed to do it. -> Compare module and router (in Primary or Core).

Especially for beginners, i really can only recommend to use a debug tool like the EW Event Watcher from the R6 factory library, or the ACEW in it´s latest version from the User Library from beginning on! A debugger, or better let´s say an event watcher is an absolutely indispensible tool to learn Reaktor fast. While EW can show up to 4 test inports in a color coded manner, ACEW shows inports and time stamps in XY coordinates. ACEW can also be used in Core cells directly.

cheers, Mark

 

is there any advantage to using System Info module to calculate tempo resolution instead of using tempo info module? Tempo info seems to send steady quarter notes at the project BPM, it's very easy to multiply to get higher note resolutions, will that cause timing issues somewhere later? I'm only using this method now for rhythmic retriggering of samples, from quarter note to 1/128th notes, not using it for syncing any oscillators.

 

Hm, the system info module doesn´t deliver any tempo based information

No, the tempo info module fires only once at initialization. It must be something else in your .ens that fires quarter notes.

I re-read your post again and think that i now understand what you want to achieve exactly and how you are probably doing it.
Maybe you already noticed that the 96th notes coming from the Song Position Module or MIDI Clock In Module are too coarse to allow quantuples of 32th notes or shorter notes like 64th or 128th just by dividing the clock.
So, indeed you need a tempo information, means Tempo Info Module, to calculate the note length in ms or samples and a far shorter clock.
I suspect you still use the Tempo Info and the Primary Hold Module or some other ramp. The Hold Module internally uses the Sample Rate Clock (called "SR.C" in Core Level) and that is the only clock that can do it precise enough. In opposite to that the Control Rate Clock "CR" from the System Info Module is too slow. Furthermore the CR is user-variable from 25Hz to 3200Hz (default 400Hz).
Actually, we do not need to talk about the 3rd System Clock here: Display Clock "DClk". It is something about 25Hz, often lower, jittery and depends on the refresh rate (load) of the Reaktor Graphic User Interface. Use this only for Display purposes.

Building an own clock that can achieve that short lengths of 128th notes etc. is definetly a Core task, in my opinion.
I don´t want to go into the Core Level details, now. Let´s keep it general.
What you need is a SR.C clocked ramp that loops (wrap) with each set note length (in samples). For this you need to calculate the note length in samples from Tempo Info, set note length and Sample Rate. Each wrapping of the ramp means a clock tick and can be output downstream as a trigger event. To achieve a limited number of clock events after the initial input event, a counter could gate the ramp´s output and the ramp clock (SR.C) to save some tiny CPU.
A new trigger event must be directly forwarded to the output, resetting the counter and resetting the ramp.

Is that what you search for?