User Forum

CC4 · #1 06-09-2005, 00:44

As I'm learning my way around this beast, are there any real differences to using an ADSR envelope built with core cells versus using an ADSR envelope from the primary level?

sowari · #2 06-09-2005, 11:11

maybe CPU levels are down? also the sound might be better?

sowari

CC4 · #3 06-09-2005, 14:53

don't know if it would affect the sound any as it's an event signal.

i've been looking at the included macros and many of them use the core...

sowari · #4 06-09-2005, 16:15

CC4 wrote:

don't know if it would affect the sound any as it's an event signal.

i've been looking at the included macros and many of them use the core...

as an event signal it will use a lot less cpu than the primary level one, which is audio.

btw, as sound shapers different ADSRs will have subtle differences in the resulting sound.

sowari

CC4 · #5 07-09-2005, 06:23

actually, now that i've been messing around in Reaktor more, I think the output is audio. ...not 100% sure now that I'm flipping through the printed manual to confirm (as it's b&w).

as a new user, i guess i'm just curious as to when and why i should use a core module over a primary, other than you can get in there and tweak... unless designing something from core scratch (which i don't see myself doing much of for a while).

i've been taking apart macros and past user ensembles to learn more, and there's just a lot less to learn from in regards to the core as it's pretty much new to even the seasoned veterans.

kid_sputnik · #6 07-09-2005, 09:16

a few things:

first, the corecell ADSR in the factory library is audio. the problem with making an event one is that corecells dont have a clock source in event mode. you would have to clock it externally (maybe system-info module CR output) but thats not self contaned then.

also, i like using the corecell ADSR over the primary, when i actually need an ADSR, because it contains control inputs for setting velocity sensitivity and 4 differant retrigger/legato modes. implimenting that with a primary ADSR involves ALOT more work, rather than just 2 knobs!

CList · #7 07-09-2005, 15:38

The "getting in there to tweak" may seem trivial, but one of the most common things to change in an ADSR is the shape of the curve - linear vs. log vs exponential. You can do that in the non-core layer, but doing it at the core layer is a little more classy.

Another thing to consider is the fact that the core ADSR has no visible mode to display the envelope.

I think the real reason it was included, however, is that it's a common function, and everyone understands what it's supposed to do, so it makes a good tutorial for how to build using core.

- CList

jopy · #8 07-09-2005, 16:19

just to follow up on this, has anyone gone back to tweak old ensembles from the user library with core cells? does it have an appreciable effect on cpu if you're replacing multiple oscillators and signal paths? what about for players--does it make a difference for these as well? as a global question: should one abandon using the old modules altogether when building instruments? please discuss, i've been thinking about this a fair amount and would like the input of more seasoned builders.

toto le robot · #9 07-09-2005, 16:42

all I can say is that I did the corification of easy reverse grooving line, all is in core now, no primary module, it save 33% of cpu. audio tables use a lot of cpu.in core if you just program the functions you need you save cpu. but I don t know if you save cpu if you implement all the functions of the audio tables.that said I would now use core cells whenever i can.

jopy · #10 07-09-2005, 17:55

good lord, a 33% drop in cpu? just to clarify, do you mean a drop of 66% (for example) down to 44%, or from 66% to 33%? i do a lot of standalones lately and this would be an enormous improvement.

is it worth posting corified ensembles to the ul?

CList · #11 07-09-2005, 18:10

Wait a second, I think there's two things being discussed here;

1. Replacing complex math / signal flow being done on audio with a core structure that does the same thing - for example the classic "integer audio counter" made before in R4 with unit delays. I think this is what Toto is talking about - rebuilding complex structures made from simple modules (unti delay, +, -, etc) in R4 with new core structures. This will improve CPU usage - usually by quite a lot.

2. Replacing large R4 *modules* with thier core counter-parts. E.g. replacing all R4 ADSR's with core ADSRs, replacing all R4 oscillators with core-built oscillators. I have found that this will *increase* the CPU uasge. This what Jopy is talking about.

- CList

CList · #12 07-09-2005, 18:20

CList wrote:

2. Replacing large R4 *modules* with thier core counter-parts. E.g. replacing all R4 ADSR's with core ADSRs, replacing all R4 oscillators with core-built oscillators. I have found that this will *increase* the CPU uasge. This what Jopy is talking about.

I should mention that some of the big core-cells, like the oscillators, can be made much better CPU-wise than they are now. Right now they are totally "correct", i.e. they have extra latches and things to insure that they follow "best practices" for building in core. Many times, however, these latches are not needed. Additionally, they tend to have all audio inputs which makes them much worse for CPU. Doing a Pitch -> Frequency calculation at audio rate on every tick of the sample clock is a huge waste when the "P" input rarely change, and that's why the R4 oscillators have event-style "P" inputs. Converting the Core-Cell versions of the oscillators to have event-based "P" inputs will bring their CPU usage down.

It's very easy to compare the core vs. non-core for a given module. Wire them both up, set the Sample rate as high as it will go, increases the voices to 10, and do "Show CPU Usage" in the menu to see how each one performs.

- CList

jopy · #13 07-09-2005, 18:22

thanks for the clarification chris. this might also explain why some of the new macros have such ridiculously high cpu rates. it's kind of a bummer if they're going to phase out the old modules completely, unless someone (me way too primitive to do by self) is going to eventually make and post more efficient core modules.

toto le robot · #14 07-09-2005, 18:24

@ jopy:66% to 44%

@ clist:do you have an explanation why R4 large modules are better than the core counter part. as I'm thinking of corifying all my big synths what are the clues to know if it worth it or not, I wouldn't want to spend time to discover at the end that the gain is not a gain.

I also would like to point to everybody that there is one case where it is better to use core osc than R4 oscilators. it is when you want to do FM feedback oscilators. indeed there is a clipper in the R4 osc cliping the FM freq to sample rate. that is very annoying because when the FM freq is above sample rate due to niquyst theorem you get noise wich is very important to produce fm percussion. the clipper in R4 osc won't allowed you that but core osc can be done so that it will work.

CList · #15 07-09-2005, 21:29

jopy wrote:

it's kind of a bummer if they're going to phase out the old modules completely

I don;t think they have any plans to phase out any existing modules, they just won't be adding as many new ones if they can do them with core (e.g. the new shapers, filters, tube simulator, etc.)

- CList