What is actually being fed out of SR.C in core

rezaktor · December 8

NOTE: I've tried reading about this in the core manual but sometimes the wording in the core manual specifically makes me feel really stupid. Hoping to have someone explain SR.C to me in a less abstract way.

I tried to make a core cell that would run through a buffer at 1/2 1/4 /18 etc. of the sample clock rate so tried making a clock divider which meant I needed to read this SR.C and then do some stuff with a counter etc. to decide if the clock should be passed on to whatever consumes the divider. The thing that was consuming this was the read from array memory module that usually takes its clock from SR.C in my experience.

But it wasn't as straightforward as I thought it would be. There's more stuff coming through SR.C than a 1 or a 0 right?

Side note I saw a core macro that looked like it would do divisions for me but seemed to be for control rate clocks only. I may have missed one that fit my needs… But still it would be nice to create my own clock divider thing to learn core better.

TLDR main question is what's in SR.C, does it makes sense to pull it apart in a new core macro and do stuff with the pieces and then put it back together then spew it out? If so what's the part that you divide?

Thanks!

colB · December 8

SR.C is part of the audio sample clock bundle 'SR'.

There are three parts: SR.C, SR.R and SR.Reset

So SR is a bundle containing three components.

SR.R is the sample rate so has a value of 44100 if that is your sample rate. It sends an event and initialisation.

SR.Reset is for resets. Very useful as you work on mare advanced structures, particularly to avoid clicks and glitches in some circumstances.

SR.C is the audio clock. It sends an event per audio sample tick. So if the sample rate is 44100, you get 44100 ticks every second on SR.C. That's all it is. There is nothing else, just a stream of naked events that you can use to drive processes. You can give them values etc. Whatever.

The SR and CR bundles are 'special' in that they are part of the system, by default they come from outside of core. Everything else from outside of core must come via an input port.

You can override any or all of these SR components. This allows for a small amount of abstraction to enable better code reuse - something Reaktor is not good at generally.

It is important to understand that all events with their origin in some specific audio clock tick, are treated as 'logically simultaneous'. Even if one comes from SR.C and another comes via an audio input port, if they were created on the same tick they behave as though they are simultaneous.

This 'logical simultenaety' of core events is important to understand. It is the biggest difference between core and Primary. It's what gives core its power. Initially some folk find it hard to 'get', but when you do, it makes core much easier to work with than Primary.

Read The section of the manual that explains the 'event model', then read it again, and again, and keep asking questions.

rezaktor · December 8

For clarity, by 'pulling it apart' I'm assuming that its a bundle data type. But I'm not sure if that's right or not and I've not hit a situation where I got a chance to work with bundles yet so I could be mis-understanding how they work…

By the way what are bundles do you think? Is it serial data or is it actually data sent in parallel?

colB · December 8