Reaktor Online Documentation
StoreTags: Reaktor
Author: packetst0rm on June 20 2008
Viewed 1329 times. 4 people liked this blog. You can rate it below if you haven't already.
People who enjoyed reading this: daswesen, Zanf, implexgrace, eyesnine
--> I've been playing around with reaktor recently in a hope that I will find a DSP/modular environment that I can get on with enough to start making the music I want ( as you will notice by my blog list I've been trying quite a few ).

Reaktor I have to say has been the easiest of the lot to get good sounds quickly. The workflow is a bit annoying compared to max 5 and SC ( all that right clicking ) but it's sound is very good quality and I can make shortcuts where I need to with things I don't know how to do or don't care to do like limiters, compressors etc...

It's well and good noodling around but I'd like to really get into this and build some interesting stuff but without quality docs like Max/msp how the hell am I going to do this.

I don't have the hardcopy manual as I'm using a "demo" is there anywhere I can pick up a PDF?
Read packetst0rm's other blogs.packetst0rm's Recent Blogs
Comments

1 | 2
the best way to go about it is i think to dissect other ensembles. The native instruments ensembles are quite complicated, but the older ones from the legacy library are a bit easier. The manuals are not very helpful, except describing the modules.


the right clicking is a little weird, but its fairly fast once you get used to it. also, you can reorganize the directories to make macros you use often more accessible.

read the core documentation that came with reaktor. It is the way to go.

i disagree about core, you should start with just regular reaktor. forget about core until you have a good handle on:

-polyphony (core can't do this yet)
-iteration (core can't do this yet)
-recursion aka event looping aka feedback (core can't do this yet)
-snapshots (reaktor's non-destructive memory, especially learn about snapshot array - after iteration of course)(core can't do this yet)
-also pay attention to event ordering!

the thing about core is that it is good for minimizing cpu usage in certain circumstances, but it just appeared in 5 and it is no where near as fully realized as regular reaktor. honestly, there's nothing you can do in core that can't be done in regular reaktor, and the converse isn't true. core is great for developers looking to save cpu in their projects, regular users should forget about it.

edit: you can access read only text files in core... i think thats the only thing you can do in core that can't be done in non-core reaktor.

yeah, forget about core at first, except if you are a programmer and know programming already. You can do feedback in core btw, with z^-1 elements.

I'd say, take a look about the legacy ensembles and reaktor 3 ensembles, and have fun modifying those. You don't need to do scomplicated stuff at first. If you're interested, I have some write ups about ensembles I dissected a few years ago, but it's a bit harder stuff:

link

I'd say, pay for reaktor, get access to the User Library, and have fun finding pearls in there, modifying them, then everything will fall together.

damn wesen, didn't know you were such a reaktor expert. I should have guessed though, haha
i'm pretty sure z^-1 is actually a single sample delay, not true recursion. so, yeah, it'll feedback, but you can't use it as a recursive process when you're event processing.

No, not for event processing, but you can build oscilaltors that way (through audio feedback) for example. Tim Exil uses that stuff to build his ramps for his granular processing, while would have built a clocked memory incrementor, instead of having the "explicit" memory of a z^-1. Whatever, wondermagicdspland

sorry to nitpick, but since i started taking computer science courses again the event looping feature in regular reaktor gives me a serious hardon. i experimented with z^-1, but it just isn't the same thing! some of the limitations of core are really frustrating when you start working with it, because you can see that the core philosophy is capable of so much more...

yeah, i think reaktor 6 could be incredible if these limitations are erased/resolved. event looping, or at least iteration for god's sakes, not to mention polyphony management! i find it hard to believe that these limitations won't be resolved. it seems to me that the core implementation in reaktor 5 is really just a little window into the future of reaktor. if you read about the guy that designed it, how he was lured away from his own sync modular software and given creative license to do what he wanted with reaktor, you have to believe that in the 8+ years (i think) he's been working with native instruments, he's got bigger plans that what core has to offer in reaktor 5. which is why i do a google search for "reaktor 6" every time i go on the internet! i think learning core will be good preparation for working with reaktor 6 (if its even called reaktor anymore!). thats the main reason to learn it, unless you're really short up on cpu.

eyesnine said: "i disagree about core, you should start with just regular reaktor. forget about core until you have a good handle on:

-polyphony (core can't do this yet)
-iteration (core can't do this yet)
-recursion aka event looping aka feedback (core can't do this yet)"

I'm confused about what you are say above....

Ok core audio can do polyphony.. I'm sure what you are basing this one but one only needs to open up osc-2 ensemble to see this.

iteration yes it can iterate through both audio and event data structures.. event structures need any outside clock since, they don't have access to the sample clock.
I'm not really sure why you are taking about recursion because, this would imply that you would want to have an old object that is keep around for each recursive call.. being pushing on to the runtime stack. This would be against the whole visaul metaphor that reaktor, pd, etc.

one can iterate through core, but one cannot start an iteration within core itself. also, when iterating through core, because event looping is not allowed, you can't break the iteration.

similarly, core can be executed polyphonically, but there is no polyphony management within core, like the to voice and from voice modules. the only way to do this is to handle the voices discretely, i.e. to have separate event paths for both a voice number and data. this also implies then that some form of iteration has to be utilized in order to handle voices in this manner, since one discrete event has to be passed through the core module for each voice. there is actually a way to do this without using the iterator module. the } event combiner (poly to mono) will create multiple events if multiple voices are triggered.

as for recursion... event looping is very powerful and anything that can be done iteratively can be done using event loops (except implementing a core cell). this is part of the nature of recursion. you can even build your own iterator macro using event looping. the way to visualize the event looping is to imagine that the modules within the loop are being executed multiple times. so, in fact, the modules within the event loop ARE being pushed onto the runtime stack multiple times in a single sample period. also, the output of one call of a module may be dependent on the value of the previous call of the module (and other modules within the event loop). this is definitely a recursive process. many classic recursive algorithms can be coded for reaktor.

you are correct in saying that the memory allocation is not dynamic (within the modules this is a different matter), but this does not mean the processes involved are not recursive. it just means that the reaktor environment is static. at a very basic level every computer is actually a static system. memory cannot really be "created", it can only be installed, physically, then allocated. memory "creation" is simply an object oriented metaphor. dynamic environments have a static foundation. dynamic memory allocation is not the hallmark of recursion.

the point is, even if you are implementing core cells in your project, the polyphony management and iteration must be done outside of core. this must be learned first. core is really just icing on the cake, so to speak.

also SNAPSHOTS. it took me a long time to realize how useful the snapshot modules are. core has no facility to remember values from previous reaktor sessions. this is all done using snapshots, and if you can master them you're well on your way to making some very powerful instruments. how complex can you really make an instrument if you have to reprogram it every time you boot up reaktor?

the question is more about why don't you just code in a "real" programming language if you want to do any of these things?
I understand recursion but, the things you are talking can be done in reaktor one way or the other.
When I think of recursion I usually think of tree data structures and ai design which, are general the only cases that recussion is used a lot.
I mean look at Scheme ,...

reaktor is a fantastic environment to work in because of its sound quality. i can't duplicate this, and wouldn't want to learn how.

"anything that can be done recursively can be done iteratively. the reason we use recursion is because it is more efficient." - my computer science professor

if you think that tree structures and ai are the only places recursion is used, you should do some research into the topic. recursion is VERY broadly used. your mind will be blown wide open.

now, we are completely off topic!

if you have any questions on how to build a specific instrument in reaktor, post a question in the forums and you'll get help from one of a number of people on this site that use reaktor. warez talk is strictly prohibited, which is why you received a lackluster response as to where to find a pdf of the manual. because it is warez! which should also tell you where to look! ;)

1 | 2

Register / login
You must be a member to reply or post. signup or login