better way for get track to track midi-in, than with the note-reciever?

[pdxindy]

The current modulators needs to have
a special field for naming tag as constant.
So we can see each modulator name.

You can already name the modulators...

[pdxindy]

Like for example you can use “Steps”
modulator & create several ones & tweak
steps on each the same modulator to create different patterns jumping from “Steps”
modulator 1 Pattern to “Steps” modulator 2 via automation, midi or CC.

Another example is to switch from
“Classic LFO” to “Beat LFO” & so on, this will create interesting variety of modulation dynamics & shapes on the fly.

The way I do this with modulators is using ParSeq-8... each step has its own mod source. So you can set up 2 Steps modulators and put the depth to 0 for both. Then in ParSeq-8, modulate 1 step to set Steps 1 depth to 100, then the nest step set Steps 2 depth to 100 and so on...

[horizon7]

Like for example you can use “Steps”
modulator & create several ones & tweak
steps on each the same modulator to create different patterns jumping from “Steps”
modulator 1 Pattern to “Steps” modulator 2 via automation, midi or CC.

Another example is to switch from
“Classic LFO” to “Beat LFO” & so on, this will create interesting variety of modulation dynamics & shapes on the fly.

The way I do this with modulators is using ParSeq-8... each step has its own mod source. So you can set up 2 Steps modulators and put the depth to 0 for both. Then in ParSeq-8, modulate 1 step to set Steps 1 depth to 100, then the nest step set Steps 2 depth to 100 and so on...

This is a good idea. I’ll try what you mention
I hope it works as an arpeggiator & sequence.

[horizon7]

I’m thinking about the technical disadvantage
of this that each modulator might consumes
more CPU hence more weight to BW.

currently I think modulators having an
excellent performance with very tiny
CPU loading. they could really live inside
each others with no issues.

So I really like how light they are this
considered as regarded.

It will be a big problem if those modulators
start to consume more CPU since they are
at the heart of BWS & we are utilizing it
heavily.

[antic604]

I’m thinking about the technical disadvantage
of this that each modulator might consumes
more CPU hence more weight to BW.

currently I think modulators having an
excellent performance with very tiny
CPU loading. they could really live inside
each others with no issues.

So I really like how light they are this
considered as regarded.

It will be a big problem if those modulators
start to consume more CPU since they are
at the heart of BWS & we are utilizing it
heavily.

I wouldn't worry about this. Bitwig seems to be 10x better than Live in terms of CPU utilisation when using modulators, because it was built around it and optimised for it. Also, you'll only need those super complex, multi layer modulations every so often, I image? Lastly, you can always bounce stuff out to audio & keep the original track disabled, thus removed from CPU & RAM, yet still available for tweaking.

[] Peter:H []

I’m thinking about the technical disadvantage
of this that each modulator might consumes
more CPU hence more weight to BW.

currently I think modulators having an
excellent performance with very tiny
CPU loading. they could really live inside
each others with no issues.

So I really like how light they are this
considered as regarded.

It will be a big problem if those modulators
start to consume more CPU since they are
at the heart of BWS & we are utilizing it
heavily.

I think these smart Bitwig guys do some pretty clever stuff at the heart of Bitwig. They have this "scripting" language called Nitro. Afaik their plugins are build with that. And I think they compile Nitro on the fly into machine code. I think they can just recompile behinde the scene every assembly of modules you can imagine into the most efficient form.
Link describing a Nitro Hack: https://github.com/zezic/bitwig-device-hacks
On Windows and for BW 3.3.3. here's some Nitro Scripts: \Bitwig Studio\3.3.3\resources\nitro\std

[] Peter:H []

I haven't read through the whole thread, but what if they don't build a "Send to" Device, but just make it a Menu Entry?
Like you right click in one track and it says "setup send-to/note-receiver" with a drop down of all instrument tracks which are eligible to puting a note-receiver in it.
Then this would simply insert and preconfigure a note receiver at the target track with the "current track" as source.
And maybe ... the most sophisticated variant would be a "ghost"/"virtual view"/"remote control" module which just visually represents the note receiver that has been inserted at the other channel in order to let me control it from both ends.