Previewing instrument

First of all sorry for my bad bad english.
Here you can find a link to an output of granite, the instrument I'm building:
www.manipurarecords.com/dump/reaktor/01.mp3

It is based on a grain cloud sampler, a filter, a stereo delay and a resonator. Each parameter is linked to an input such as a sequencer or an lfo and the routing between input an output is chosen using cellular automata.
Granite is a patchwork of my own studies and other people's macros and ideas... el-destructo and black rectangles comes to mind.
Before posting it in the library I want to cut down some cpu usage (20% idle and some 60% peaks with xp2000+), starting with the resonator and the compressor (I've just cutted the spatial audio feature... :/).
Actually I'm using the resonator found in el-destructo and the 4band limiter found in the program's library, but they eat too much cpu. Any suggestion for lighter resonator and limiter?

If you are curious, here is the link to granite... work in progress: www.manipurarecords.com/dump/reaktor/studies/granite.zip

You have to load some wave file, assign L and R in the sample map to 0-0 ,1-1, 2-2, etc, and then set the number of 'max' of the first parameter in view B.

In view A press the first and the second button on the right for setting the seeds... default logic is "generations" (logic 5 in view B).

Let me know

b.

 

The cat is out of the bag now!

 

Sorry?

 

great work, hirnlego!

i loaded a simple slow sax solo with just a few notes into it and got back a full-blown complex melody that bore little resemblance to the original.

a request: please label all your controls in A view and add info popups to them. there are quite a few buttons that are unlabelled.

excited to see the final version.

rachMiel

 

Nice programing

Wow......

Very interesting ensamble.....should have come with a manual

Im realy impressed with the programing! Way above my skills......

 

Ehehe, yes... it's still open for some debugging and optimization.
The B view is a mess, some of the controls are there temporary and for debug purposes.

I'll surely post it to the library as soon as it's complete and comprehensible

Thank you.


b.

 

Re: Nice programing

Thank you but, look, much of it is just copy&paste of someone else's work, put together, modified and refined... a lot of study and "reverse engineering".
In fact, I think it's way far from being optimized and performing... sometimes too much workaround, patches and redundancies.
Anyway, I'm proud of the CA implementation and the routing concept... and the table's morphing

b.

 

Thats what all programing is about isent it?
Copy and paste...refining and some ideas of your own

I`m still impressed.

Looking forward to the 1.0 version
I hope you will give us a (small) manual.

 

Thank you... I'll let you know when it is ready and commented


b.

 

Knowledge picked up while writing Sparky, don't know if this applies to your work in particular...

If you want to make your ensembles efficient.

1) If your instrument does the same thing lots of times think about using multiple simple voices to do this. ie the polyphony trick. If you can work out how to apply this technique to your code it is massively more efficient.

2) Make as much of your instrument as possible monophonic. (Obviously there are limits).

3) Use event signals whereever possible. (Obviouslu there are limits).

4) Pay particular attention to event chains. Where an event path splits and then recombines, a single input event can generate multiple output events. Usually only the last output event is necessary. The other events represent intermediate values in the calculation and are usually both wrong and unnecessary. If you have a sequence of splits and recombinations the effects multiply and the overhead gets worse and worse. The way to fix this is to use order modules at the splits, and value modules after recombinations.

It took me a while to get to grips with how Reaktor processes events, but now finally I feel that I know what I'm doing.

 

Could you please explain this polyphony trick? How does this apply to monophonic signals for achieving such efficiency?
I'm not used to polyphony.

This is interesting, because I'm just beginning to understand events in Reaktor. I'm used to topdown programming, and this surely causes some confusion about the events flow.
BTW I'm learning to use EventOrder and EventValue to make the flow much more "topdown", hoping this doesn't slow it down too much.

Thank you

b.

 

So say you're making a drum sample player. You want say 10 channels each with its own sample, filter and envelope. You basically have two choices - a monophonic instrument with 1 voice containing 10 sample players, 10 filters, and 10 envelopes. Or a polyphonic instrument which 10 voices each containing 1 sample player, 1 filter and 1 envelope. Both approaches theorectically do the same amount of work, but because of the way Reaktor is built, the polyphonic implementation will be much more efficient. However you have to get into a different mindset. I don't know what your ensemble looks like (I don't have the means to look at it now) but if it has a bunch of grain cloud modules, consider using multiple voices with one grain cloud each then combine these with a voice combiner.

If you think top down, then you should think in terms of black boxes (not black rectangles). If you make a macro you should make sure that a single input event results in a single output event. However if you make macros with multiple outputs which are recombined in other modules you can still get event explosions. I don't know of a single cure for this problem but the approach I used in Sparky was to have a single clock signal which is propigated through all your event logic. You use value modules along the way to make sure that for each macro you define, each output only produces a single output event on each clock tick. There are probably more efficient techniques but this approach gives you a defined worse case behaviour.

 

It's just one grain cloud module with a bunch of samples loaded. The instrument is monophonic and plays just a sample at time... sometimes they play very fast and with some delay it looks like they're overlapped. Actually I'm trying to convert it to polyphonic but cannot find the solution.

In your experience, there are contraindications or side effects to this?

b.

 

The only thing wrong with this approach is that it produces an event on every single clock tick. There may be cases where a value hasn't changed and therefore no event would be needed. So the best possible way to program events is to work out exactly what's going an and optimise accordingly. I tried doing this with Sparky and got my brain in a tangle, thats when I decided to simplify things by using a global clock.

 

Interesting approach... maybe I'll try it in the next ensemble

Thank you for sharing.

b.

 

Granite is online

Well, the ensemble is uploaded here: http://www.nativeinstruments.de/index.php?id=userlibrary_us&type=1&ulbr=1&plview=detail&patchid=2344

Let me know


b.