Quality of the new manuals

This has been discussed soooo many times, Artur. What actually defines a good manual can be found in this [thread=17026]thread[/thread]. So we don't even need to write a new list. Again.

 

You are right, that's a good thread. Maybe I'll pick up something and make a small tutorial, as a starter...

 

p.292 (german manual) oscillator
... this is only one example...

 

Absolutely. I don't get it - the lack of communication between NI and this forum concerning the actual state of affairs is baffling. Why can't they just tell some knowledgeable people to tackle this project, and then it takes how long it takes to get it ready (why is Rick put on hold???). I mean, did anybody from NI say sth like "Thanks for the input, guys, we'll take it from there" somewhere along this "manual rewrite" thread? I feel they do owe us something, as the UL (the USER Library) with nearly 2000 free additional items is one of Reaktor's strong marketing points. And we supplied it. I never heard a "thanks!" about that too - as if we weren't there. How'd you label that?

 

i agree with the other points you made, however, i think they have thanked us for the UL in the past (although when, i can't remember).

the UL with 2000 uploads was mentioned in the NI press conference that launched R5.

at one time it did look as though we were going to get a proper manual, but then the may/june deadline put an end to that.

sowari

 

And *that's* what I don't get particularly: why not let Rick (and maybe others) continue, post a message here that clears the situation - all 'd calm down. Unless they're going to charge 79€ for it ;o)

 

as cheap as that ;-)

sowari

 

reality

a rewrite of the reaktor manual (not including the core) would be a large and expensive project. i would say 1000+ hours work to do it right (rewriting, copy editing, technical editing, layout, etc.) ... 2-3 people working full time for 2-3 months. then the new manual would have to be translated, which is also time-consuming and expensive. printing, binding, and so on.

this is not to say it shouldn't be done (as you know, i think it should be done), but it goes a long way to explaining why ni have postponed doing it. if the existing manual suffices (even if it is not very good), then there is not that much motivation for ni to spend a substantial amount of money for a rewrite.

this is my opinion and has nothing to do with ni policy.

rick

 

Re: reality

Yeah. If. I think it's clear by now (after those extensive discussions about this subject) it is *not* sufficient. Even NI has come to that conclusion by announcing they're planning a rewrite. So, as a matter of fact the money has to be spent, one day or another. Inevitably, as it doesn't make sense to carry on with the old manual pasting in new stuff from version to version. I saw Marius Wilhelmi viewing this thread today. Curious to see whether there is going to be a response to it.

 

I went throught 10 pages of this thread and actually it confirms my point: 90% of it was battles between users about god-knows-what. 10% was about real content of the manual. Here are the major points:

1 how the ensembles work. For example, Sum Synth does something tricky to create all those oscillators.
2 how/why you might use some of the more esoteric modules. Or point to which stock ensembles use some of the stranger modules
3 Every module should have one or more example structures. It would be helpful if some "watch out for this" notes could be included one some of the "tougher" modules (the sample players and tables really need this)
4 desription of every input and output for every module should be more detailed - people should be able to find out in the description of the Modulo module that the event from the Div output will be sent before the event from the Mod output when it's running in event mode.
5 Event processing orders should be explained with pictures. Many people do not know what depth-first traversal algorithms are!
6 For each module a description of what makes it useful, when you might need it, and a few examples of its use would help a lot.
7 a detailed instruction on how to optimise instruments considering performance.
8 Explanations concerning mono/polyphony in regards to building (where and when it'd be advised to use either of them).
9 Now take something like the mentioned "all pass filter" - hell, if you don't know why you'd use it, then you don't use it. Allpass filters are used in the world outside of Reaktor, you can go out on the web and read about allpass filters and how they are used, THEN come back and try to apply that knowledge to Reaktor
10 Examples of each module in action / Module Behaviors
11 The documentation for OSC needs to be improved
12 The documentation for internal connections has got to be improved

 

Good summary, good points. Thanks for taking the time, Artur (I actually quit on that thread after page 4 or sth then had the occasional glance). What are you/we gonna do with it?

 

I don't know yet I thought it would be good to collect this stuff in case NI would finally do something.

I was also looking at the Max/MSP manual, every module described has a few examples how they are used. Great stuff. This could be used as example for the Wikibook. I still want to describe some modules I know...

 

So, any particular advantage to my porting some or all of my FX tutorial to the Reaktor wiki? If so...any guidelines?
Thanks!
dc

 

Re: Legacy mode

Here's a reply by CList to Herw:

Re: BTW what is „R4 legacy mode”
------------------------------------------------------------------------
R4 Legacy Mode is set on the Ensemble properties page.

R4 vs. R5 mode only has to do with the way event fire during a Global Event Reset (panel switch presses, audio on/off, instrument start-up, etc).

If you are running a R4 ensemble, and it is having event problems on global initialization in R5 that were NOT happening in R4, then it is having trouble with the new event initialization algorithm. You should turn on R4 Legacy Mode to make it work correctly under R5.

Since the R5 Event Initialization is faster and makes more sense you should leave R4 Legacy Mode off for all new instruments you build and build them so that they don't have any problems.

If you look in the Documentaion folder there's a folder called "Technical Detail Information", there's a document in there that details the new R5 Initialization Algorithm. Of special interest (to me anyway) is the fact that the self-iteration events from the SnapValueArray modules will always fire LAST - this means you can use that as a trigger for anything that has to happen after everything else on Global Inits, snapshot changes, etc.

Unfortunately they *STILL* have not put constants first in the event init order, and I have no idea why. It really makes no sense to me why a constant should ever fire it's value after a knob.

- CList

 

It might be more convenient to just post a link, as your excellent tutorials in pdf format have a nice structure, and I'm not sure there's an easy way to integrate the pictures into WIKI's layout?!

 

Since only registered users can see it in the UL, I might just include it on my own website as well, whenever THAT appears. In any event, a link in the wiki makes sense...
Thanks!
dpc