A to E (perm)

Something I've recently noticed...

If you set the frequency at which events are produced by the A to E (Perm) module to 44Khz it actually seems to produce events at that rate. The quality improves and the CPU usage shoots up.

So it's not limited by the default control rate. Or am I hallucinating?

 

I think you are correct. Notice also that the step filter can reduce the event rate (possibly to zero).

 

Much of event processing in Reaktor is asynchronous... meaning that it is not dependent on any sort of control rate (although it may only be calculated at a certain max scheduler rate... I do not believe 44100 pseudo-event rate is possible in Reaktor, it caps far below that). If you have an a-to-e perm running at 10,00Hz, everything triggered by that module will run at 10,000Hz as well. The control rate only really affects objects that send at a fixed rate (like LFOs) that need some way of knowing how fast to send. Max is another example of a program which uses asynchronous event processing (even more heavily than Reaktor). Asynchronous events give you a lot of flexibility and let you save a lot of CPU if you do it carefully.. but they also give you a lot of rope to hang yourself with if you treat them as synchronous objects.

 

Similarly, an event coming out of the EventHold or EventDelay modules are not timed up with the global control-rate clock. They can happen at any time.

I'm not sure about knob-movements, and X/Y mouse movements, however - these may be timed to the control-rate clock.

- CList

 

This could link up with the other thread relating to internal connections.

if I make an internal connection from a lamp to a knob and I send events at the lamp at 5000hz will the knob be updated at 5000hz or at the default control rate?

 

I would say that modules, which only send events, do that with the internal control rate (if no other value is given like you can do it with the a-to-e (perm) module), like, as already mentioned, the LFO. A lamp receives events, so I would say, but I'm not sure, that it would be updated with the incoming control rate and also sent with that rate.

 

The knobs output will be updated at 5000Hz, but the actual image of the knob will be updated at whatever the graphic redraw rate is (obviously).

 

Bzzzt!
Sorry, not the case, see my post in the other thread on direct-connections...

http://www.nativeinstruments.de/forum/showthread.php?s=&threadid=12991

 

Not sure how this relates to the previous replies, but I do believe that a-to-e perm can send events at 44.1k. Look up a-table recorder in the user library. It uses an a-to-e perm into a counter to drive an audio table.

 

So do I...
I use it to quantize the signal with a lower rate and I have seen many other instruments which use it therefor, so it must be possible.

I at least hear no difference between the original sound and that which goes through an a-to-e perm with 44.1khz

 

Huh, I'd alwys used a pulse wave driving a Sample&Hold for when I want to do Sample Rate reduction (BitCrush) style effects. AtoEPerm is probably much more efficient - nice one!

- CList

 

What is this, dig up three month old threads day?

 

It's also useful when you want to do non-realtime processing from one buffer to another. I've made a couple of sample-editing utilities this way. You can even run it in excess of 44Khz to get jobs done faster.

 

well,,,some of us dig up threads that are 2 years old;-)

sowari

 

I'd love to see these sample-editing utilities, if you wouldn't mind.

Respect.

 

It's mainly on the fly stuff like, create an impulse response from a wav file, so I can use it to control the amplitude on a reverb trail. Nothing comprehensive, just things that are difficult to do in cool edit.

But if you're still interested I can make a little example when I'm at home again so you can see how it's done... with a <insert per-sample based algorythm here> macro.

I guess it could be developed into a toolkit for all kinds of non-realtime functions.

 

Sure, I'd like to see whatever you've got.

Thanks.