I don't understand Bitwigs modulation routing strategy

[angstrom]

When I say "I don't understand the strategy" what I mean is - I think I understand how it works, I may be wrong, but I don't understand the choices made. It seems to me that if I want a modulator such as an LFO to modulate a device parameter then I must place the device inside the LFO ?

So the LFO becomes a container to the device with the parameter I wish to modulate?
Is this correct?

So how does a user then use 3 LFOs within a serial device chain? LFO 1 modulates Device cutoff, LFO2 modulates pitch , etc. they all nest each other? That seems a bit odd.

Now in parallel chains, such as an FX layer container - If LFO1 in chain one has it's speed parameter mapped to a macro - how could that modulate a device in parallel chains 1,2,3 ?

I'd prefer being able to route a modulator anywhere within the application rather than to a few specific nested locations, as this implementation seems limited and limiting. I'd prefer the fully modular mod-routing approach (anything to anywhere). I was hoping bitwig would deliver something a bit closer to that.
I understand the latency calculation issues, but I'm not a fan of this nested device solution.

Have I misunderstood how it works?

[Ogopogo]

It seems to me that if I want a modulator such as an LFO to modulate a device parameter then I must place the device inside the LFO ?

Yep

So the LFO becomes a container to the device with the parameter I wish to modulate?
Is this correct?

Pretty much.

So how does a user then use 3 LFOs within a serial device chain? LFO 1 modulates Device cutoff, LFO2 modulates pitch , etc. they all nest each other?

Yep

That seems a bit odd.

Yep, I agree.

Now in parallel chains, such as an FX layer container - If LFO1 in chain one has it's speed parameter mapped to a macro - how could that modulate a device in parallel chains 1,2,3 ?

I don't think it can, since an lfo can only control a device nested within it.

I'd prefer being able to route a modulator anywhere within the application rather than to a few specific nested locations, as this implementation seems limited and limiting. I'd prefer the fully modular mod-routing approach (anything to anywhere). I was hoping bitwig would deliver something a bit closer to that.
I understand the latency calculation issues, but I'm not a fan of this nested device solution.

Have I misunderstood how it works?

I think you've got how it works. Personally I'm not that interested in using an lfo in one track to modulate something in another, but I'm not a fan of the way it is organized now with the lfo becoming the "main" device and the thing you're actually getting sound from nested within it. Besides just being sort of unintuitive, this causes some annoying stuff, like your track being renamed "LFO MOD" when you use an lfo on your instrument, and I think if you're using a controller you have to navigate through the lfo to get to the instrument, but I'm not sure about that.

I think maybe the lfo should be nested in the instrument rather than the other way around, or maybe no nesting should be required and you should just be able to connect it to whatever. I don't know how feasible that is coding wise but from a ui perspective it makes sense to me. Again I personally would be happy if it just worked for anything on a track, but concerning routing around the whole project, Bitwig have recently added note and audio router devices that allow you to route this stuff between tracks, so maybe the answer here is a mod router device to get lfos working between tracks ? Dunno.

[kehoutek]

I think it would be awesome to be able to put all your lfo modulators on one track that were routed to devices in other tracks. That way when you opened the track with the rack of lfo's you'd have all the modulatable lfo's in one place.

[angstrom]

Thanks for the answers guys, @Ogopogo I strongly agree that a modulation routing device, or an expansion to existing devices, is the way for them to proceed. It would keep the interface clean and limit repercussions.

I'll give an example of why someone might want an LFO on chain 1 to modulate devices on both chain 1 and chain 2.
If I were building a multi-layered instrument with a layer of Polysynth and one layer of NI's FM8 . Now I want both of these to behave as one instrument, so my vibrato should be the same in both layers. I add an LFO device and route it to both Layer's instrument pitch modulation. Currently to do this I'd have to encapsulate the Instrument Layer within the LFO device, but now things become limited if I want to add another LFO which modulates Filter cut-off in both instruments. Do I encapsulate the entire rack again?
It's not logical.

I suggest that a Mod-receive device would be more logical, or perhaps extend the existing Note-receive device to have options to receive modulation.

I understand what the Bitwig guys were trying to do with this encapsulation, but it's not a good solution from a usage point of view. It's not enticing me into any sort of "modular environment" it's more like a weird limiting compromise.

[svervs]

As much as I like Bitwig, this decision I also never really understood.
I'm sure they've looked at other applications, but e.g. in After Effects you can link parameters across the whole project much more intuitive, almost patchcablelike.

[angstrom]

Yes, I've long advocated that DAW manufacturers take a good look at how After Effects handles pickwhips, and scripting of parameters. I also like the nesting methodology.

I once suggested to the CEO of a different DAW company that they could take a leaf out of After Effects book in this regard and he said it would be too complex for their users to understand, "I actually wish we never allowed racks to be deeper than one level", said the CEO of the nameless company. I was aghast.

[pdxindy]

Thanks for the answers guys, @Ogopogo I strongly agree that a modulation routing device, or an expansion to existing devices, is the way for them to proceed. It would keep the interface clean and limit repercussions.

I'll give an example of why someone might want an LFO on chain 1 to modulate devices on both chain 1 and chain 2.
If I were building a multi-layered instrument with a layer of Polysynth and one layer of NI's FM8 . Now I want both of these to behave as one instrument, so my vibrato should be the same in both layers. I add an LFO device and route it to both Layer's instrument pitch modulation. Currently to do this I'd have to encapsulate the Instrument Layer within the LFO device, but now things become limited if I want to add another LFO which modulates Filter cut-off in both instruments. Do I encapsulate the entire rack again?
It's not logical.

I suggest that a Mod-receive device would be more logical, or perhaps extend the existing Note-receive device to have options to receive modulation.

I understand what the Bitwig guys were trying to do with this encapsulation, but it's not a good solution from a usage point of view. It's not enticing me into any sort of "modular environment" it's more like a weird limiting compromise.

Last time I tried Bitwig, it was also frustrating that you had to nest your synth inside an LFO, because if you then want to save it, it is saved as an LFO preset, not a synth preset.

[xbitz]

yepp the MODs should extend the capability of a device, using them as containers seems epic fail to me



without opening the device bar we can reach/interact only with the LFO as black box, a definitely: "meh" , hopefully 1.2 gonna solve this problem with its vertical device control panel / new groupping

[takaii]

Okey i read alot of doubts with this. I feel like its pretty simple and
effective to see the workflow how its routed.
By putting something in an lfo mod you know what it is LFO:ing.
Also this is not a video editing software like after effects.

Also the complains about saving LFO for a synth might sound off.
However with the new extra browser coming up in 1.2 we can select what type of instrument we are looking
for and pinpoint down to what we are searching will actually help us find what is an synth and not.

i love the simplicity in bitwig, it might feel wierd at first with all routings bitwig does, but once you get used to it
then it will be very easy to nail down to what is what and where things are and how its connected.
Its kind of organised in some way.

To be able to use LFO in another track might be something we see in 2.0 in bitwig, but i actually like that its not possible.
It gives a bad overview and it will easy start looking cluttering like in fl studio. I like having overview of my project so it does not look like a mess. Its nice however we all share diffrent thoughts and view on things If everybody would have same point of view then it would only exist one daw

[takaii]

Also container system allow us to save the device nested as a preset. Even if LFO is not a synth like i wrote earlier it can be saved using meta data and then with the new browser coming you can pinpoint to only locate synths if you save it like that

[Ogopogo]

If the system is there, I mean if we are going to have folders for different categories of stuff at all in the browser, then it should work in a way that makes sense. Saying it doesn't matter that it's not intuitive because you can get around it is no way to approach ui design.

[angstrom]

For me it's worse than a UI oversight.

I understood Bitwig was going to be a modular DAW, a modular environment where we might route (almost) anything to anywhere, a matrix of sources and destinations.

But it seems that the strategy which has been chosen is far more limited and limiting. It will only be a daw where containers contain containers. That is a hierarchical routing system, rather than a matrix.

If we can't route A to B to C back to A, then I'm really not excited by this DAW at all.

I hoped it was going to be a flexible modular DAW. What a shame!

[llze]

well, you can break out with audio modulators / note & audio receivers at any place in the chain.

[The Mantra]

I hoped it was going to be a flexible modular DAW. What a shame!

I guess you didn't see the part on the Bitwig website that states that the modular system is a 2.0 feature.
You can criticize Bitwigs modularity all you want, but at least wait until its released to do so.

That is unless you've already seen it. Perhaps you have one of those flux capacitors I keep hearing about around the forums.... maybe you keep one sitting next to this?

[Phorous]

Yes, it could be better but Bitwig also makes it easy to sync many modulations together instead of everything being independent with its approach.

Sometimes Bitwigs approach saves me time, other times it makes what I am trying to do much harder.