Event Timing / Events in Core (was:looking backward or forward)

Discussion in 'REAKTOR' started by ehdyn, Feb 20, 2008.

Thread Status:
Not open for further replies.
  1. ehdyn

    ehdyn NI Product Owner

    Messages:
    468
    Is core any good for event tasks?
    Would I be able to construct a high-speed, sample-accurate sequencer with it? Or is this better left to higher levels?
    I've barely dipped into core at all. Looks very interesting though.

    Any starters for this line of work? My DSP books don't cover anything like this.
    My question really is-what is core's strength exactly?
    Would I want to use it to make a 3-D terrain envelope for instance? Something I've wanted to do for a long time.

    I think the osc's and filters sound good enough already.
    With a little tweaking they sound just as good as these "authentic modelling" oscillators from "x" company.
     
  2. loadammo

    loadammo NI Product Owner

    Messages:
    333
    I'll answer this question probably incorrectly, but -- the difference between audio and event as far as Core is concerned is just the refresh rate.

    Audio events are refreshed at sampling rate (11,025Hz to 176,400Hz), events are polled at control rate (25Hz to 3200Hz).

    Short answer is, yeah, you could create a sample accurate sampler in Core, but the primary modules give you access to features you'd have to spend a lot of time rewriting in Core, and some elements you would be unable to reproduce. "Sample Maps" for instance, or anything that touches the operating system through the filesystem APIs.

    I was able to make a goofy network audio transmission system using OSC that allows you to convert event data into sample data, but it's crude.. However, without Core my macro would be impossible.

    It'd be nice if someone did a write-up on why you should use core and give some examples of things only it can do. Maybe it exists.
     
  3. ehdyn

    ehdyn NI Product Owner

    Messages:
    468
    Thanks for the answer. Clears things up a little for me.

    I'll have to check to see if it's possible to override the refresh rate manually. The control rate you mentioned is not fast enough for what I'm looking to do.
     
  4. ehdyn

    ehdyn NI Product Owner

    Messages:
    468
    Worth mentioning that I have alot of problems using reaktor for sequencing right now. I typically set it anywhere from 350-500 bpm's. The timing seems to degrade pretty badly, and the cpu acts up at these speeds. Wish they would remove the 500bpm cap. There's no reason for that limitation.
    So I end up using a lot of 3rd party apps for triggering, and modulation at the moment.
     
  5. ~Pd~

    ~Pd~ NI Product Owner

    Messages:
    569
    I'm too lazy to do the calculations but at that speed aren't you butting heads with or exceeding the standard 400Hz event rate? Like there'd be more than one 96th tick per event. Maybe that's causing the problem. Try increasing the event frequency. That will also increase CPU, I guess, but it might keep things from getting erratic.
     
  6. ehdyn

    ehdyn NI Product Owner

    Messages:
    468
    Thanks for the suggestion PD, I hadn't realized that.
     
  7. ehdyn

    ehdyn NI Product Owner

    Messages:
    468
    Anyone have any recommendations for clocks?

    Should I be using Mike Daliot's overclock as a starting point? Or is there something better suited for my purposes?

    First priority is jitter-timing accuracy.
     
  8. CList

    CList Moderator

    Messages:
    3,299

    THIS IS NOT CORRECT!
    Events can fire on any tick of the sample clock.
    Existing sequencers built in primary using event logic are "sample accurate".

    Damn, I wish I'd been paying more attention to this thread so I could have nipped this in the bud!

    Cheers,
    CList
     
  9. CList

    CList Moderator

    Messages:
    3,299
    Any problems like this you are having are most likely a problem with the particular ensemble you're using not being designed to run at such high speeds. The inner timing technology that reaktor is built on shouldn't care. OTOH, *some* event modules that generate events without any user input (the LFO for example) base their timing on the control rate clock, so they have create timing issue for you. Again, designing the ens to run at higher rates should help, but since you're doing more work each second the rise in CPU is inevitable.

    Really tho, what's the difference between running at 250 bpm and running at 125 bpm with small note lengths?

    Cheers,
    CList
     
  10. CList

    CList Moderator

    Messages:
    3,299
    I've explained this so many times (in other threads), I don't know anymore how to explain it so that people understand. The Control Rate does NOTHING as far as when events CAN fire. Events don't always fire on the Control Rate. The control rate clock is ONLY used by certain event modules that need to generate events constantly, in a stream. Like the AtoE and the LFO. It does affect the timing of the a couple of modules in quirky ways (like the GateHold module), but in general Events fire on sample-clock ticks not ONLY on the control rate clock.

    You can be happy to know that the "Everything you need to know about Reaktor Event Processing" document I've been thinking of writing up will now get written, because I see how much people need it!

    Side note:
    Since the output of reaktor (or any DSP system) is samples at the sample rate, there is no way of measuring what happens "between" samples. For this reason, the lowest measure timing granularity is the sample rate, and events and audio both cannot happen "between" samples.

    Cheers,
    CList
     
  11. ~Pd~

    ~Pd~ NI Product Owner

    Messages:
    569
    Please and thank you! The relation of midi clock, event rate and sample rate has always been a little hazy to me. Sorry for spreading disinformation and thanks for the thumbnail sketch of the facts in this post.
     
  12. CList

    CList Moderator

    Messages:
    3,299
    Part of the problem, I think, is the term "event rate" or "event control rate" used by NI.
    A more accurate term for "Control Rate" would be something like; "Global Event Clock Rate". There's a global event clock that ticks away at a different rate from the sample rate, and it's very useful, but events (and everything else) have their timing locked only to the Sample Rate. In fact, if you think about it, a control rate of 400 and a sample rate of 44100 would mean that the first tick of the event clock would happen *between* samples, but that's not the case, even events triggered by the "Global Event Clock" must have their timing quantized to the Sample Rate!

    You can make "lab" ensembles to test this, but it's tricky and is best done using a scope to measure timing.

    Cheers,
    CList
     
  13. CList

    CList Moderator

    Messages:
    3,299
    See attached ens.
    I increased the control rate to 2400 to make it easier to see.

    The Global event clock is trying to run at 2400Hz, but since it's locked to the sample rate clock and is not divisible evenly into 44100, it shows jittering.

    The top scope shows the Control Rate clock driving a flip-flop. Each time the line goes up or down the control clock is firing an event from the AtoE

    The middle one show the top event being delayed by a single delay. Note how the events don't fall on timing of the control rate clock!

    The third row is an audio-rate flip-flop. This goes up and down in time with the sample rate. Note that this audio flip flop is something that could be done for less CPU in core.

    Cheers,
    CList
     

    Attached Files:

  14. herw

    herw NI Product Owner

    Messages:
    6,361
    Hi Chris,
    i have thought about it a while and there ARE events "between" two sampleRate ticks.
    I have constructed two polyphone event core oscillators which are clocked by SampleRateClock and iterator. The waveforms are merged and sent simultaniously (two events per sample tick) by ONE wire (bus) to primary. From primary you can pick the channel to get the wave again. Both wave have samplerate release!
    The picture shows four channels:
    channel 1 is a normal audio oscillator
    channel 2 EventAudioOscillator saw
    channel 3 EventAudioOscillator pulse
    channel 4 EventBus which sends both waves

    the wave on channel 4 is choosen by the knob at the left side.
    Channel 2 and 3 shows that the waves are sent simultaniously.
    The event core cell has two original 4-wave-oscillators inside.

    BUT there is a great problem: CPU is VERY high!

    ciao herw
     

    Attached Files:

    Last edited: Mar 14, 2008
  15. loadammo

    loadammo NI Product Owner

    Messages:
    333
    The tried and true method for getting a correct answer on the internet is to answer it incorrectly and eventually someone smarter will come along and set you straight. :D Thanks Clist.
     
  16. herw

    herw NI Product Owner

    Messages:
    6,361
    sorry my english is not good enough to understand your comment.
     
  17. loadammo

    loadammo NI Product Owner

    Messages:
    333
    Heh. Just an old joke. A lot of times you'll see questions on forums/usenet that never get answered. So what you do is answer it incorrectly and eventually someone will correct you. Hubris is a stronger motivator than Samaritanism.

    I meant it jokingly to cover up for how wrong I was.

    I appreciate CList correctly answering the original poster's question. There's a lot of core voodoo and he has a lot more insight into the rituals than I do.
     
  18. ehdyn

    ehdyn NI Product Owner

    Messages:
    468
    "Core voodoo".
    -They really should've named it that. I'm planning to scale Mt. Kailash in order to be intiated into the dark arts.
     
  19. herw

    herw NI Product Owner

    Messages:
    6,361
    ok - but now my answer to CList is hidden and covered. So i will post it to builders section too.

    ciao herw

    new thread : AudioEvent stream
     
    Last edited: Mar 15, 2008
Thread Status:
Not open for further replies.