Let‘s speculate about 6.0

[_leras]

Yep multiples but also output chains. I may of course be missing this is possible already

Could you use layers ? I may be missing the point.

I would also like to see much more flexible sidechain/routing though. I appreciate that feedback loops and other 'bad' (maybe good ?) scenarios can occur.

There's no great solution tbh. Multiple outputs are still somehow grouped together, which would be fine if you could then actual use proper groups inside that.

Id like Bitwig to allow grouping inside multichannel and specifically for drum machine.

I want to group kicks, snares, claps, high hats, percussion etc, so I can treat them as groups use local FX sends for reverb, parallel compression, etc

You can do this with sends to channels inside groups, but there seems no way to then load a new drum kit into that structure, as it wipes out the channel for sampler device and breaks all the sends to audio receivers. So from that point only individual samples can be reloaded.

That's ok when making a track, but makes it impossible to save this track setup out and copy it to a new project to reuse as a template, as if the kit is change all the routing needs to be redone.

I should email them again.

[pdxindy]

How often would you want the exact same automation curve on different parameters?

More often than you'd think. (At least as a starting point).

Why automate one parameter when you try 7 or 8.

Let's see what Bitwig has implemented.

The curve I can imagine duplicating in multiple places is a simple ramp up or ramp down.

[pdxindy]

You can do this with sends to channels inside groups, but there seems no way to then load a new drum kit into that structure, as it wipes out the channel for sampler device and breaks all the sends to audio receivers. So from that point only individual samples can be reloaded.

You can route individual drum pads to different tracks in a group and change the drum machine preset and the routing stays.

[humanoid3000]

I hope that version 6 will finally feature something similar to snapshots in grid and polymer with the ability to modulate or switch between them, and even morph between them — a good example of Reaktor 5/6 implementation.
It would also be nice to have non-volatile memory in the array and the ability to write data to steps, gates, slopes, etc.
Looper is also a long-standing desire
I've been waiting for it for more than a year

[_leras]

You can do this with sends to channels inside groups, but there seems no way to then load a new drum kit into that structure, as it wipes out the channel for sampler device and breaks all the sends to audio receivers. So from that point only individual samples can be reloaded.

You can route individual drum pads to different tracks in a group and change the drum machine preset and the routing stays.

Hmm... Thanks PDX, I'll have to try again. I haven't had much luck, but I might have Already had things added after the sampler, but in the same FX grouping

[pdxindy]

You can do this with sends to channels inside groups, but there seems no way to then load a new drum kit into that structure, as it wipes out the channel for sampler device and breaks all the sends to audio receivers. So from that point only individual samples can be reloaded.

You can route individual drum pads to different tracks in a group and change the drum machine preset and the routing stays.

Hmm... Thanks PDX, I'll have to try again. I haven't had much luck, but I might have Already had things added after the sampler, but in the same FX grouping

Yeah, with the routing, you can set the track input to receive from the pad, or from individual devices on the pad. If you set it to receive from an individual device and you switch presets and the new preset doesn't have that device, then the audio track input will reset.

If you set the audio track to receive from the pad, then the routing stays.

[nielshertz@gmail.com]

BWS represented the breakthrough for a more open-ended approach to the DAW-concept. It unleashed the DAW workflow from the usability-ties of a the old (dying?), console/tape based studio-workflows, utilizing all the power of the digital world. They "invented" a great modular design, stretching through the DAW as a whole, with the tranparant modular design-principles, we love, where everything fits into everything, opening for completely mindblowing creative use. Since then, others have implemented some of the same great ideas, although, mostly as "annexes" to their, still non-modular base, which often make their implementations seem clunky and limited, rather than as a integrated part of the DAW, like in Bitwig.

BUT

Now seems to be the right time to look in the other directions, also: In pursuit of this innovative modularaity, Bitwig seems to have lost itself a little to the somewhat "nerdy" side of things. Maybe they lost a little of the attention for GUI-side of things that actually could underpin the simplicity (really!) and ever-rewarding "goes without saying" of the truely modular concept, routing, and workflow-wise?

I myself need the GUI to be a little bit more freely organisable (moving windows and views around like in some docking-environments, for example) "total resizability" (in a reasonable way!), GUI-presets (skins), a better way to make GUI-objects for your creations in the grid. In short: more focus on the GUI! Maybe a "loving overhaul" of the well-kown orange/black UI-widgets could also be a factor?

And to the routing/workflow-side: why on earth does an otherwise template and user-preset-focusing platform not offer channel-presets?

Saying this, I totally identify the risks in leaving the well-implemented, strict conceptual consequence and great usability tied to named modularity, trying too hard to force it into some ever-shifting taste for "beautification". So everything has to be done in very deep respect for the original concept! Please do not leave it to some UX-teen with great ideas about colours and fonts, but no real understanding of the genious of the origiinal modularr "logic" in Bitwig, which actually - to the contrary of what people may think - is the exact opposite of "nerdy". In its depths lies the basis for real usability. Allthough, maybe a small thing, but still very revealing for this aspect: just look at the help-system with actual active, in-project, living, adjustable controls, not possible without a well implemented modular code-base!

[_leras]

I myself need the GUI to be a little bit more freely organisable (moving windows and views around like in some docking-environments, for example) "total resizability" (in a reasonable way!), GUI-presets (skins), a better way to make GUI-objects for your creations in the grid. In short: more focus on the GUI! Maybe a "loving overhaul" of the well-kown orange/black UI-widgets could also be a factor?

And to the routing/workflow-side: why on earth does an otherwise template and user-preset-focusing platform not offer channel-presets?

Saying this, I totally identify the risks in leaving the well-implemented, strict conceptual consequence and great usability tied to named modularity, trying too hard to force it into some ever-shifting taste for "beautification". So everything has to be done in very deep respect for the original concept!

The two screen layout is pretty good for me, but being able to make a couple of slightly different views on my second screen would be pretty good.

Channel/group presets would be great. I put strips of FX into containers to save them, but sometimes I'd like to just save my whole drum group which could have drum machine, other drum VSTs, sampler channels, routing, FX chains etc.

I'm not sure people after work flow changes want beautification. For me I see there is just a gap between 'possibilities' and 'doing things'.

Examples where I think Bitwig can do better: side chain, multi band compression, OTT. Things than can be very simple with third party plug ins but that are quite fiddly with Bitwig. A beginner is going to struggle to get a basic volume ducker going, where really it should be very simple.

[nielshertz@gmail.com]

Yep, it is sometimes a bit up to you to “construct” the devices, sometimes, elsewhere offered as built-in.

However, on that issue I totally support the Bitwig -approach: firstly because the implementation possibilities of named “constructs” are much more open-ended and flexible, when modular, and secondly because of the rich “separatability” “chainability” and “layerability” offered - not to speak of the possibility to save every such “construct” (except CHANNEL SETTINGS!!!) as a preset.

And, after all: Bitwig offers out-of-the box, ready-to-use instruments and effect-devices, which both qualitatively and quantitatively far exeeds most other DAWs, making the “constructed” ones an addition for those who want to go further.

So this is - in my view - all good and well. So good, actually, and so far ahead of the “others”, that the dev.-team could easily focus on other issues (like the GUI) for a while. This would mean gaining terrain, not loosing it (the latter, I fear, could be the consequence of persuing the modularity-concept into further, enigmatic realms )

[] Peter:H []

Yep, it is sometimes a bit up to you to “construct” the devices, sometimes, elsewhere offered as built-in.

However, on that issue I totally support the Bitwig -approach: firstly because the implementation possibilities of named “constructs” are much more open-ended and flexible, when modular, and secondly because of the rich “separatability” “chainability” and “layerability” offered - not to speak of the possibility to save every such “construct” (except CHANNEL SETTINGS!!!) as a preset.

And, after all: Bitwig offers out-of-the box, ready-to-use instruments and effect-devices, which both qualitatively and quantitatively far exeeds most other DAWs, making the “constructed” ones an addition for those who want to go further.

So this is - in my view - all good and well. So good, actually, and so far ahead of the “others”, that the dev.-team could easily focus on other issues (like the GUI) for a while. This would mean gaining terrain, not loosing it (the latter, I fear, could be the consequence of persuing the modularity-concept into further, enigmatic realms )

I have a love/hate relation with BW ... to start with.
I really dig the modularity mindset. but I think the abstraction level is the key to different "music making personas".
If you are persona "Ned Nerd" you hate the modules in the grid and would want it a level deeper like in reactor's core or cycling 74 ~gen module ... here's abstraction level mostly good, but a "bit" to high.
If you are "bob beginner" you start to wonder how "note grid" could be used to split a chord into it's notes ... abstraction level not fitting at all, you want to deal with notes not with modular signals.
And it has become a sport to do this "look mum, no plugin" videos, which mostly only either get you 75% of the claimed result, while the actual icing on the top is exactly in this 25% (see for instance video about bdr "resynthesize" of polarity ... compared to resynth capabilities of kick3), or it get's so complex quickly that "Mike Musicmaker" does not want to spend hours to get it going, Mike just wants/has to make music.
That personas in mind, it's unteresting how Bitwig staff actually thinks and what there target group is. If I watch their videos, I'd say it's mostly Nerds ...
I personally - though IT guy with some nerd eruptions - stopped to use the grid. Nevertheless I use the modulation stuff ... anyway ... it's complicated.

[pdxindy]

If you are "bob beginner" you start to wonder how "note grid" could be used to split a chord into it's notes ...

Bob the beginner can simply use the Note FX Selector to split a chord into individual layers.

[coroknight]

I don’t think every audio tool needs to cater to Mike Musicmaker and Bob Beginner.

I’m not saying tools should be actively hostile to those users but not every tool needs to cater to the same groups. That’s why Bitwig has devices like Polymer, to provide simplified devices for non-advanced users.

[ere2learn]

Isn't this what the tiers are for, people not interested in certain aspects

[monolithx]

I don’t think every audio tool needs to cater to Mike Musicmaker...

If it's not for making music, why not just use Matlab

Note: the only usable (not random and overkill) chord splitter, I have found is this Grid preset:

Triple Layer Note Split
Splits incoming notes into three layers - the lowest note, the highest note and everything else in-between. Change out the instruments in each layer to whatever you want.

While I can do it easily in Max, I gave up for any advanced MIDI manipulation in Grid.

[xbitz]

I don’t think every audio tool needs to cater to Mike Musicmaker...

If it's not for making music, why not just use Matlab

Note: the only usable (not random and overkill) chord splitter, I have found is this Grid preset:

Triple Layer Note Split
Splits incoming notes into three layers - the lowest note, the highest note and everything else in-between. Change out the instruments in each layer to whatever you want.

While I can do it easily in Max, I gave up for any advanced MIDI manipulation in Grid.

incoming note gate signal with Sel-In can select a voice — from there, it's easy
https://www.reddit.com/r/Bitwig/comment ... pwise_row/
the under-the-hood voice management works in a very interesting way — but the main thing is, it works