Multiplexing Help Needed for compiling/initialization crashes

Moonbot7000

Hi, Im building a mixer that needs a lot of controls going in and I used the very simple multiplexing macros from the block template kit, however, whenever the core cell recompiles it causes tons of issues (that little orange bar takes forever to finish and on my laptop which was lower power it would crash at a certain point). I know there are macros in the partials framework that may help with more efficient multiplexing, there are also macros "smart value" and threadsafe but I don't know how to use the documents don't cover this issue. Does anyone know, or can point me to a resource that helps me solve this compiling/initialization problem im having? I have some screenshots belowof the mux setup and a .ens that has the mixer in it for anyone willing go give it a look over. Love you all.

Mixer Work rebuild multiplex.ens

colB

Instead of linking each router to the one below, just send val directly to the input of each of them. Long chains of conditionally routed events is one of the things that can slow down compilation, and AFAICT, it's not necessary in this case anyway.

Moonbot7000

https://community.native-instruments.com/discussion/comment/12517#Comment_12517

Yep, that made the difference, thank you!

Studiowaves

I've done away with routers and use the linear crossfade instead. You can still address each crossfade with a lookup table preceeding the x input. The table will output a 1 at a specific input value and 0 at all others. Each table has a 1 that is one step higher in the table. If you want to crossfade using tables all you do is use a range in the table like 100 steps that climb from 0 to 1. The climb can be linear or exponential too. Pretty simple to make the tables with excel or any spreadsheet. Very simple once you get the idea.

Studiowaves

https://community.native-instruments.com/discussion/2222/multiplexing-help-needed-for-compiling-initialization-crashes

ColB has the answer but this is alternative versatile method of doing things.

The number 1 is just a constant I tossed in the picture and as shown it will pull up a 0 or 1 from the table. So any number you put there will call up whatever is in the memory. This allows an easy way to switch between inputs 0 or 1 on the crossfade module. The advantages of this is being able to crossfade between inputs if you use floating point numbers in the memory array for a crossfade. It's great for mixers and mux's compared to using comparators and routing things because you can't crossfade and everything ends up choppy. This method allows smooth transitions between one input and the other. Try it, you'll like it, your mixer will be smooth as butter. lol Have fun

colB

https://community.native-instruments.com/discussion/comment/14190#Comment_14190

Its not an 'alternative' though, it's a different thing, with a different use case. Using that in the context of the original post here would be... lets say sub-optimal

Studiowaves

https://community.native-instruments.com/discussion/comment/14290#Comment_14290

na, just passing on techniques, you did a great jog solving his problem, that's why your the boss. Speaking of sub-optimal, check this out. Two different ways to make a linear crossfade with 0 to1 on the x input. Which one is optimized? Just for fun.

colB

https://community.native-instruments.com/discussion/comment/14290#Comment_14290

The top one is the approach used in the Factory Library, I have some version of that in my own macro collection, but using the appropriate mod macros. Can't remember where I learned it from.

The bottom one is pretty bad because of that naked constant that will throw an unwanted init event down the rest of the chain.

This example is optimisation of implementation, which in many cases doesn't matter a whole lot - it rarely makes a huge difference. The problem with the 'alternative' of using a table and crossfade instead of a router is that it's more about optimisation of algorithm. That can be much more significant - choosing the wrong algorithm, or architectural approach is much more likely to have a significant impact on performance. It's a tiny example, and maybe doesn't make a big difference depending on context, but it's still worth getting right IMO

Sync

Partials Framework 2.25

https://www.native-instruments.com/en/reaktor-community/reaktor-user-library/entry/show/6571/

Sync

Multiplexing.pdf

Partials Framework Documentation

Sync

Core Demux Simple

Core Demux.ens