Bitwig audio routing know-how limitations are ... severe.

[minortom]

So... I'd love to know if a simpler solution to my problem exists before bothering the dev team with another feature request.

Yes, Bitwig's audio routing is very powerful, with enough cleverness you can really do almost anything, it's just not always easy or convenient. Case in point: I want to crossfade between dry and wet FX signal without losing the tail. In other words, an insert effect with blendable sends rather than returns. Sounds simple, but not trivial to achieve. There are two obvious choices for varying the effect amount:

* The Mix knob on the effect works with returns so it cuts the tail
* Sending to FX tracks is great at keeping tails, but the proportional cutting of the dry signal must be implemented separately, and now the routing has blown up into multiple tracks and is no longer easily modulatable.

It seems Bitwig has a general design principle that tries to lean heavily on encapsulation and strictly unidirectional flow: you can take from anywhere but your downstream, you cannot push anywhere but your downstream, and your downstream has to narrow. Like, modulation only affects things downstream and enclosed in the current context but never across a context boundary, or mix/blend controls exist strictly after signal processors and able to combine outputs but never fork inputs. The principle makes sense overall and explains why there is an Audio Receiver but not an Audio Sender. The convention of mix knobs only on return paths seems arbitrary and underdeveloped, however.

I can get the behavior I want in a number of ways, they all involve the actual FX unit hidden somewhere mid-chain between Receivers and/or Tools that together manage input gains across two signal paths, wrapped in a container. Of those the most straightforward is an FX Layer with one empty layer for bypass, another containing a Tool followed by effect, and a modulation macro turning empty layer's volume and Tool volume in opposite directions. It works but with none of the convenience or visibility of a top-level device, especially when using a controller that works with device remote controls.

What's clearly missing is a mix/blend control that is "pre-FX", in addition to the existing "post-FX" Mix knob, that would be ideal. An FX Layer container with controllable input gains as well as output would be the next best thing. Delay-4 could be that if there was a way to turn off the delay tap return.

Did I miss a better workaround?

[antic604]

...There are two obvious choices for varying the effect amount:
* The Mix knob on the effect works with returns so it cuts the tail
* Sending to FX tracks is great at keeping tails, but the proportional cutting of the dry signal must be implemented separately, and now the routing has blown up into multiple tracks and is no longer easily modulatable...

1) put the 100% wet FX into FX Layer,
2) add another empty layer below, so that the dry signal goes through
3) put Tool in front of the FX chain and automate / modulate its Volume knob to pass the dry signal through the FX
4) [optionally] put Tool in the empty layer, with reversed automation / modulation, to cut the dry signal out

[minortom]

...There are two obvious choices for varying the effect amount:
* The Mix knob on the effect works with returns so it cuts the tail
* Sending to FX tracks is great at keeping tails, but the proportional cutting of the dry signal must be implemented separately, and now the routing has blown up into multiple tracks and is no longer easily modulatable...

1) put the 100% wet FX into FX Layer,
2) add another empty layer below, so that the dry signal goes through
3) put Tool in front of the FX chain and automate / modulate its Volume knob to pass the dry signal through the FX
4) [optionally] put Tool in the empty layer, with reversed automation / modulation, to cut the dry signal out

Yes, and now I regret putting it that far down the TL;DR

I can get the behavior I want in a number of ways ... Of those the most straightforward is an FX Layer with one empty layer for bypass, another containing a Tool followed by effect, and a modulation macro turning empty layer's volume and Tool volume in opposite directions. It works but with none of the convenience or visibility of a top-level device, especially when using a controller that works with device remote controls.

[antic604]

Yes, and now I regret putting it that far down the TL;DR

Heh, sorry. I was on MS Teams call and missed that

[perpetual3]

But once you create your device, you can also create top level macros or am I missing something?

So... I'd love to know if a simpler solution to my problem exists before bothering the dev team with another feature request.

Yes, Bitwig's audio routing is very powerful, with enough cleverness you can really do almost anything, it's just not always easy or convenient. Case in point: I want to crossfade between dry and wet FX signal without losing the tail. In other words, an insert effect with blendable sends rather than returns. Sounds simple, but not trivial to achieve. There are two obvious choices for varying the effect amount:

* The Mix knob on the effect works with returns so it cuts the tail
* Sending to FX tracks is great at keeping tails, but the proportional cutting of the dry signal must be implemented separately, and now the routing has blown up into multiple tracks and is no longer easily modulatable.

It seems Bitwig has a general design principle that tries to lean heavily on encapsulation and strictly unidirectional flow: you can take from anywhere but your downstream, you cannot push anywhere but your downstream, and your downstream has to narrow. Like, modulation only affects things downstream and enclosed in the current context but never across a context boundary, or mix/blend controls exist strictly after signal processors and able to combine outputs but never fork inputs. The principle makes sense overall and explains why there is an Audio Receiver but not an Audio Sender. The convention of mix knobs only on return paths seems arbitrary and underdeveloped, however.

I can get the behavior I want in a number of ways, they all involve the actual FX unit hidden somewhere mid-chain between Receivers and/or Tools that together manage input gains across two signal paths, wrapped in a container. Of those the most straightforward is an FX Layer with one empty layer for bypass, another containing a Tool followed by effect, and a modulation macro turning empty layer's volume and Tool volume in opposite directions. It works but with none of the convenience or visibility of a top-level device, especially when using a controller that works with device remote controls.

What's clearly missing is a mix/blend control that is "pre-FX", in addition to the existing "post-FX" Mix knob, that would be ideal. An FX Layer container with controllable input gains as well as output would be the next best thing. Delay-4 could be that if there was a way to turn off the delay tap return.

Did I miss a better workaround?

[minortom]

But once you create your device, you can also create top level macros or am I missing something?

Yes, once the device is created all the controls can be mapped to controls in the outer container and the whole thing can be encapsulated. This only works until you want a different device or preset and have to redo the mapping, that's the main inconvenience.

[perpetual3]

But once you create your device, you can also create top level macros or am I missing something?

Yes, once the device is created all the controls can be mapped to controls in the outer container and the whole thing can be encapsulated. This only works until you want a different device or preset and have to redo the mapping, that's the main inconvenience.

I think it’s hard for me to envision what your talking about just from the concept, but doesn’t Bitwig offer device preset pages?

[pdxindy]

But once you create your device, you can also create top level macros or am I missing something?

Yes, once the device is created all the controls can be mapped to controls in the outer container and the whole thing can be encapsulated. This only works until you want a different device or preset and have to redo the mapping, that's the main inconvenience.

Maybe I am not quite understanding what you are doing, but it seems to me you only need to map the tool(s) devices which wont change regardless of whether you swap a delay with a reverb etc.

[minortom]

Right, mapping the Tool is easy, I'm talking about something else: controlling the effect device from the outer FX Layer device.

image_2021-02-06_010811.png

This is the idea antic604 and myself described. The first "bypass" layer is empty, the second layer has a random preset I picked from the library, the macro knob poorly called "Volume" does the blending. The preset is a chain that comes with some performance controls, but to get to them one has to get to the FX Layer device first, select the layer, and then get to the effect device. This gets trickier when using controllers like Machine JAM.

Now, one could create a Perform page with modulation controls in the FX layer and map them to specific controls in the nested effect — that would make life easier as the effect is now controlled without diving inside the layers. However, if that effect were switched to a different preset/device, modulation mappings will disappear if the new device does not have that specific control. E.g. I can create a Macro modulation knob in FX layer mapped to "Verb Amt", but if the next preset I load does not have "Verb Amt" the modulation knob will become unmapped.

In other words, controlling an effect wired in this way from the outside of the necessary container is possible but can be laborious.

As an aside, Bitwig is probably enjoyed best with a dash of a punk attitude.

[foosnark]

As an aside, Bitwig is probably enjoyed best with a dash of a punk attitude.

[kurt008]

...and what's wrong with Audio-Receiver plugin (just because the setup above can be recreated with it...) ?

Nothing, except that I didn't talk of it. I mentioned it, because it is used for "grabbing audio" from anywhere, but it isn't useful for my issue. Please read my post correctly - sorry

[kurt008]

+1 for Audio Receiver. It can do ridiculous audio routing tricks. Never tried it for feedback loops, though. Is it possible?

Feedback isn't possible, because these signal's are not present in the selector of Audio Receiver.
Yes, the Audio Receiver gives a lot of possibilities, but... doesn't change anything in track audio routing (routing from track to track).

[pdxindy]

...and what's wrong with Audio-Receiver plugin (just because the setup above can be recreated with it...) ?

Nothing, except that I didn't talk of it. I mentioned it, because it is used for "grabbing audio" from anywhere, but it isn't useful for my issue. Please read my post correctly - sorry

It is easy to mixdown say 3 tracks to one and no Audio Receiver device needed.

[kurt008]

...and what's wrong with Audio-Receiver plugin (just because the setup above can be recreated with it...) ?

Nothing, except that I didn't talk of it. I mentioned it, because it is used for "grabbing audio" from anywhere, but it isn't useful for my issue. Please read my post correctly - sorry

It is easy to mixdown say 3 tracks to one and no Audio Receiver device needed.

If I make a group out of these 3 tracks - right. Other solution...?

[kurt008]

Have you looked at the Track-level Input/Output dropdowns? I frequently output Tracks to other Tracks/Groups without the Audio Receiver Device. It will limit feedback-loops, but there's a post on here somewhere about a workaround to make them.

I know about track-to-track routing, but my claim is and was: For such a meanwhile mature DAW like Bitwig Studio it is a very poor workflow to need workarounds when I simply want to, let's assume, create a sub-mix track containing an individually levelled sum of a few tracks out of the whole project.
I already said: REAPER (Cockos.com) makes it very simple: You enter a new "Receive" or "Send", can define a mix level, pan,... (which can in any way be "automated", BTW) and... if you made a "Send", the receiving Track lists the sending track automatically (!) - and vice versa. So it is possible (in Reaper at least, but according to my info this is possible in several other known DAW's, too, like in FL-Studio, Ableton, ...) at any point in your project to make a sub mix (like a "bus") consisting of ... as an example OHH, CHH, Clap, Crash, level them individually and change these levels in an automation clip.
Bitwig Studio allows only one "Send" and one "Receive" per track. And one doesn't recognize the other. If you make (as a concrete example) track 3 send audio to track 5, then track 5 doesn't recognize it, means: It simply doesn't show it (as "Receive from track 3") and as long as I don't make a separate "Receive" on track 5 (referring to track 3) it simply ignore the received audio signal.

Did you understand my "complain"? Such a workflow (and that's only o n e example) is not what I expect from a meanwhile well developed (and not even cheap!) DAW.
Right, every DAW has it's flaws, even the most expensive ones. But... we should forget all the freakish comments and "likes" when it comes to simple basics... a DAW is a Digital Audio Workstation and no X-BOX or some toy or PC game. As a workstation for Audio I expect a solid selection of working tools for Audio (as the term DAW says) and a reasonable and comprehensive concept. I do not accept the neglect of such developments at the expense of dazzling effects (and in this way, new teething troubles to be created as well). The Grid... yes, it has enhanced Bitwig Studio's possibilities enormously. But... it has brought countless new flaws while there still are old flaws present as well... which seem to be forgotten meanwhile and ... freakish users seem to forget them as well, as it looks like.
Some people here might have heard about the originally Linux program LMMS, the "Linux MultiMedia Studio"... over many years it had a very small community of "fans", who even ignored the missing sample-true automation, causing clicks, pops and simply noise in almost every kind of automation. But: As long as not one singular user asked for such a development, the developer didn't become motivated to change it.... After some years though the "collection of user voices" grew asking for a reasonable solution for this - meanwhile for many users disturbing - flaw... Result: LMMS changed it's developers and meanwhile... this and some other problems were solved quite well (there's still some left and... the user group has shrunk once more - after some growth).

Want to say: It never is a good solution to smooth-talk flaws and weaknesses, because this shows a completely wrong sign to the development, making them believe "everything is in order right now".
I don't want to talk something bad - as it doesn't help anybody. But... as long as something needs development, it is a simple nonsense to name it a "great tool" without to mention any flaw!