Looks neat! It would be interesting to hear how this works out. What kind of performance do you expect from this - i.e. how many oscillators, filters etc you can put it in before the processor maxes out (I guess this is totally up to how Reaktor work - I haven't tried it out)? At least you have the long macro names sorted out.

I was never able to reach reaktor maximum limits, but currently my AMD 2200 single core CPU can handle a maximum of 400 sinewave oscillators mixed simultaneously using 44100 sample rate.

The G2 demo running the equivalent model on the same CPU, reaches the limit with 50 sinewaves.

Also note that reaktor uses floating point calculations which are heavier (but much better) than 24 bit integer calculations done in G2.

but my main objective is:

"To get around G2 limitations, still using compatible/equivalent modules."

The G2 interface is imensely more productive, but it has several limitations, that reaktor can solve.

To name a few...
-It is not a VSTi
-It does not have a sampling module
-It has only 4 Ins and 4 Outs
-It does not have the ability to open each module and make changes in graphic design and dsp algorithms.
-It does not have an oscilloscope module
-The VU meters are too small
-It has no numerical value metering display
-The filters have a maximum slope of 36 dB and the majority of them is limited to 24 dB
-The sequencer modules don´t have backward stepping
-The memory amount in the delay modules is too small
-The clock generator has no blinking led
-The logic 8-counter does not have backward stepping
-There is no macro capability (modules containing modules)
etc...

Yeah, those are all valid points. I've been toying with the idea to make a Java/ChucK clone (Java for the GUI, ChucK for the sound). ChucK doesn't have all the tools to mimic everything that the G2 does, but it might still result on something usable. Not sure I'm going to invest in Reaktor for this, but it sure will be interest to see what you end up with.

A huge effort is necessary in this part, because a wrong decision at the atomic level can cost a fortune later, re-working the interface, if some atomic change is needed, after dozens of modules and hundreds of buttons were already done.
(The infamous "butterfly effect")

xav wrote:

sure that depends on everyone computer and soundcard.

Chances are that...
In the next 2 years, it is going to depend on your *video* card also...
The recent nvidia CUDA library came to stay, and it allows +- 4000% floating point calculation performance increase for audio over a top quad core CPU, and i hope that NI product development manager don´t underestimate that fact.

xav wrote:

Do you think it would also be possible with Pure Data?

Good question...

Not in a million years.

They made fatal mistakes at the atomic level, and to make such a high level, top layer interface, like that of G2 (which i consider brilliant), would require rebuilding PD entirely again, from scratch, using a totally different set of paradigms.

It´s like trying to build a pyramid, using bottom base blocks made of styrofoam, and upper blocks of concrete, no matter how much effort you put in trying to build it... the final result is catastrophic.

Several unpleasant problems:
-The buttons are bugged. (see image)
-The grid snap is limited to 4x4 and doesn´t turn off
-Once the "No frame" macro attribute is activated, the macro cannot be dragged or selected anymore, neither it´s title can be changed or displayed.
-Clicking on the background of a macro doesn´t select all the objects in that macro
-Using macros with frames steal a lot of useful space
-Objects inside a macro cannot be grouped or locked
-Dragging an object outside the bounds of a macro destroys the macro size and changes layout
etc, etc etc...

-Full migration from buttons to pictures. (zero frame width, zero bugs)
(it´s unbelievable how NI let that bug pass in such an often used control like button...[they forgot to add a frame attribute in the button])

-16 Grouped button array and 16 grouped led array in development for
the sequencer modules

It requires imense work in reaktor to overcome that annoying 4x4 limit.

To achieve precise single pixel design is "almost" impossible.

(I recomend very strong persuasion to the NI guys, so they can simplify precise single pixel design some other way than using this crappy 4x4 grid, in the next version, after all, users should spend more time making sound, than wasting days to make a decent graphical interface.)

For example...
Today i have to do a revision on the big cyan OnOff button.

It has already propagated in several modules (seen above)

This means that when the new revision is done, i have to go back in every place that has this button and replace it for the new macro, and reposition the graphical object with the mouse again.

This implies that if you don´t make a rock solid development in the lowest level atomic elements, later, when some it´s used in hundreds of places, the re-working process multiplies enormously.

It shoudn´t be this way, a feature for having macro clones is needed, to allow the changes in those elements to be done a single time, the same way that is done in programming languages. (if you change a procedure, all the calls for it will reflect the changes)

This is not as serious as missing patch cables, because at least there is a solution, going inside every module and pasting/repositioning the revised macro.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum

Please support our site. If you click through and buy from our affiliate partners, we earn a small commission.