Even merge as dummy , for timing correctons ?

gentleclockdivider

I was rereading parts of the manual and the following struck me as weird.

See screenshot

Quote

Connect the Out port of the Ratio Calc Macro to the second W input of the Snap ValueArray, using a second Merge Module as a dummy to keep the event timings correct.

Unquote

Using an event merge as a dummy for event timings ?

colB

Seems odd to me :)

This from two pages before look dodgy to me:

In Primary, ordering of events needs to be tightly controlled. Here, is is left up to Reaktor. That's never a good idea IMO. Maybe this ambiguity created a bug (maybe not*), and the edit involving adding that 'dummy' merge caused the order to be reversed, removing the bug.

Just looks bad to me. It's really just a symptom of Primary, where 'correct' code becomes quickly unreadable due to all the order modules needed to explicitly specify correct event orders.

*It may be that the order of the output ports 'fixes' the ordering issue in this case, but that's a really terrible way to define something as important in a programming environment. I just steer clear of Primary as much as possible.

The one Rule to rule them all in Primary is that each event in turn is propagated to it's ultimate conclusion before other pending events, or any child branches. If that rule is being followed correctly, the merge should make no difference at all.

gentleclockdivider

dunno, it looks that this part of the building in primary is written by an incompetent person .

Core , primary , certain tasks are just a complete pita compared to max -pure data

The absence of lists and list handling in general , once you know it becomes second nature and it's incredibly powerfull .

Absolutely no such thing in reaktor and I miss it dearly , core does not solve that

colB

https://community.native-instruments.com/discussion/comment/229996#Comment_229996

And there are things Reaktor does better, or are just not possible in Max or Pure Data, or else you would be using those exclusively.

Reality is that every environment has it's strengths and weaknesses. There are always design compromises when developing a complex application… particularly something as complex as a programming language.

Max doesn't do immediate optimised compilation. Reaktor does. That's the killer app for me. I don't know about pure data, does that do instant compilation? The only reason I came to Reaktor was when that was added (core). I crossgraded from sinc modular. AFAIK there still hasn't been another dataflow audio platform that has that feature?

dreason85

Max doesn't do immediate optimised compilation. Reaktor does. That's the killer app for me. I don't know about pure data, does that do instant compilation? The only reason I came to Reaktor was when that was added (core). I crossgraded from sinc modular. AFAIK there still hasn't been another dataflow audio platform that has that feature?

What is immediate optimised compilation and instant compilation?

colB

https://community.native-instruments.com/discussion/comment/230037#Comment_230037

Each time you make an edit in core, it is automatically compiled to binary. Means you can build low level DSP and have it run with reasonable efficiency. As far as I am aware, other dataflow languages are either interpreted like Primary layer, or require extra steps to use a compiler based process.

dreason85

colB， I have a question for you, that is, since the float and integer data types in Reaktor Core produce different results, why do things like MaxMsp or Puredata not include the processing of integer data types, but instead unify them into float floating-point data types? In this way, don't they lose the advantage of integer data types?

I also agree with the list processing provided by software such as MaxMsp and Puredata, as they can greatly reduce a lot of trouble.I'm actually quite conflicted about using Reaktor. Of course, the digit8 you created showed me the charm of integer types, but it's not realistic to forget the trouble of building Reaktor modules based on this charm.Another point is that I have found that many people who are interested in graphics are easily discouraged when they come into contact with Reaktor, because its operation of graphics is not that convenient, especially after seeing the sound sequence editors or building a text input box that have been done with Reaktor. In the eyes of many Reaktor users, it is relatively difficult. Therefore, for Reaktor, you may need to focus more on sound design. But when you design the sound, you realize that the sound operation interface you want to design becomes very difficult to implement in Reaktor.

gentleclockdivider

https://community.native-instruments.com/discussion/comment/230002#Comment_230002

Behind the scenes , real time edits in gen~ are jit compiling efficient cpu code

I understand you deeply love reaktor ( so do I ) , but it wouldn't hurt to learn another language which future is much brighter .
Gui wise and list processing it is TOP NOTCH
Here's a good video of gen~ and it's developer Graham wakefield
https://www.youtube.com/watch?v=jsOx4VwO_0w&t=3293s