Event rate , input at audio rate is possible

gentleclockdivider

This is something that has always bothered me about primary event rate

See this , the osc takes pitch modulation fom another osc and since the modulatin is going into the event input , the audio from the modulator needs to be converted to events

When using the standard ae module , the event rate is determined in the settings ( default to 400 and max of 3200 Hz )
The result of the modulation is not really high res , even at 3200 Hz

But , when using the "a to e perm" module , we can set our own conversion rate ,in the second screenshot this is set to 44100 Hz , now the modulation is ultra smooth and high res
This proves that event inputs can process events at audio rate , so why is the max settings restricted to 3200 Hz ?
Let it be clear that we're talking about event input and NOT outputs ( meaning an lfo will never output events higher then the max settings in the menu )

Audio files examples
Low event

https://app.box.com/s/vdnece2q7ncjwzui9lmwybrxns4937bj

High event rate ( 44100)

https://app.box.com/s/lu7etrr2wfygvgsjo7f322m1vjpjo6je

gentleclockdivider

Same for filter mod with p input

Just switching the output of the system info between event rate and sr into atoe perm makes a huge difference .
So event input can process their input 44100 per seconds

gentleclockdivider

I would love to see a developer chime in why even inputs are perfectly capable of calculating their inputs at a rate > 3200

KoaN

https://community.native-instruments.com/discussion/38393/event-rate-input-at-audio-rate-is-possible

In my experience if you use the A to E Perm at 44100 in a complex structure with polyphony you get crazy cpu peaks! It becomes impossible to use ,modulating Pitch or Cutoff in core with audio inputs is way more efficient.

colB

https://community.native-instruments.com/discussion/comment/190185#Comment_190185

Not always. It was useful for some tricks!

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

Here I used it to enable oversampling up to 16 times…

The primary iterator cant be driven by audio events, but if you run events at audio rate, each event can trigger an iterator… you can then use the result for janky oversampling.

This instrument has a front panel oversampling parameter.

It's not super efficient, but not terrible either.

(note that i haven't tested this for a looong time, and it might not even work with the current version of Reaktor :))

colB

https://community.native-instruments.com/discussion/comment/190089#Comment_190089

Events are events, the cpu doesn't know how frequent they are. If an iterator generates events, they will occur as fast as your 16GHz 128 core i11 can spin them up and process them. depending on what they are driving, they could potentially be clocking at tens or hundreds of MHz.

I think the clock limit is just for sanity. Reaktor is intended to be usable by folk with no technical knowledge. In Primary, events are not efficient for audio processing, and event modules are not intended for audio either, so might sound terrible if used in that way. …but if the clock was not limited, some newbie folk might just keep making really bad Reaktor code that sounds terrible and runs slowly, and complaining that Reaktor is bad?

In core, the default rate for the control rate clock (CR.C) is the audio clock rate. But in core, there is no distinction between 'event' vs audio' event types, so there are no hidden gotchas* if you use the wrong one - there is no wrong one!

*there are other hidden gotchas, but they come down from the primary layer so…

KoaN

https://community.native-instruments.com/discussion/comment/190195#Comment_190195

I have no doubt for certain situations it might be very useful! You know more than me about that.

I got the atomic pack from Toybox,i am crazy about the atomic oscillator….it can run 72 oscillators using polyphony,audiorate modulation of everything would be impossible so the modulators are clocked at the event rate you want,it needs to be kept low though,above 8000 and it kills my cpu.In certain paths though i found out it was better to make the path fully audio,the cpu rises a little but you can go to 44100 and all is steady compared to event clocked where 8000 is ok but you go up and it fries the cpu! Of course it depends on what kind of path,processing is going on too.

KoaN

I was exploring TRK-01 from NI and discovered an interesting thing,CR control rate synced with the tempo,this can be a very good idea when you want modulation to stay in sync,right on beat with low control rate,the stepping effect could sound more musical.Very low resolution could also be interesting because you would get like a sample and hold on your modulation source synced with the tempo.