Let‘s speculate about 6.0

Official support for: bitwig.com
Post Reply New Topic
RELATED
PRODUCTS

Post

MIDI Capture
Proper Arranger Track (like Studio One/Cubase)
Chord Track
Snap To Scale
Groove Pool Quantise For Audio (like Ableton)
Extended script to assign more than 8 knobs per time to a device

Anything else for me is a bonus 8)

Post

pdxindy wrote: Wed Aug 06, 2025 2:52 pm
] Peter:H [ wrote: Wed Aug 06, 2025 1:13 pm 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.
if you are honest to yourself, it's one of those "look mum no plugin" workarounds that does not do the trick (in round robin you have to assume 3-note chords and use 3 layers to reliably route lowest note to layer that is supposed to handle the lowest note, as soon as you hit it with 4 notes that is doomed)... I have tried all these workarounds ... and went to use pizmidi then. And actually I was talking about note grid and that it is not possible in there.

To show that I'm actually kind of a mild "Ned Nerd" and not gave up out of not knowing my way around ... you can look up my older posts like this for example viewtopic.php?t=614560

Post

] Peter:H [ wrote: Thu Aug 07, 2025 11:57 am
pdxindy wrote: Wed Aug 06, 2025 2:52 pm
] Peter:H [ wrote: Wed Aug 06, 2025 1:13 pm 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.
if you are honest to yourself, it's one of those "look mum no plugin" workarounds that does not do the trick (in round robin you have to assume 3-note chords and use 3 layers to reliably route lowest note to layer that is supposed to handle the lowest note, as soon as you hit it with 4 notes that is doomed)... I have tried all these workarounds ... and went to use pizmidi then. And actually I was talking about note grid and that it is not possible in there.
Exactly! The fact is that you need "workarounds" for such basic thing in a so called "modular environment"...

What is needed, is a live performance oriented DAW (snapshots, routing, monitoring, controls, GUIs, ...). I really don't understand the need for advanced editor/composition tools where the market is already full of them.

Post

pdxindy wrote: Thu Jul 31, 2025 11:52 pm
_leras wrote: Thu Jul 31, 2025 7:45 pm
pdxindy wrote: Wed Jul 30, 2025 2:17 pm 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. :hihi:
Let's see what Bitwig has implemented.

The curve I can imagine duplicating in multiple places is a simple ramp up or ramp down.
Sorry I may have missed something here but I can't imagine better implementation than Bitwig for that. Just automate a global macro then link other macros to this macro. You can even use curves as a transfer table if you want to change a bit how slave macros react to the master macro. Pretty great implem to me.

Post

] Peter:H [ wrote: Thu Aug 07, 2025 11:57 am
pdxindy wrote: Wed Aug 06, 2025 2:52 pm
] Peter:H [ wrote: Wed Aug 06, 2025 1:13 pm 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.
if you are honest to yourself, it's one of those "look mum no plugin" workarounds that does not do the trick (in round robin you have to assume 3-note chords and use 3 layers to reliably route lowest note to layer that is supposed to handle the lowest note, as soon as you hit it with 4 notes that is doomed)...
You only said split a chord into individual layers... Note FX Selector does just that.

Now you just added a new criteria, sorting notes from lowest to highest.

The Note FX Selector sorts by order played. But for this purpose, Round Robin is not the correct mode to use. "Free Voice" mode always resets. So I have a preset with 6 layers. Whether I play a chord with 3, 4, 5, or 6 notes, the first note played will always be layer 1.

Post

pdxindy wrote: Thu Aug 07, 2025 9:06 pm
] Peter:H [ wrote: Thu Aug 07, 2025 11:57 am
pdxindy wrote: Wed Aug 06, 2025 2:52 pm
] Peter:H [ wrote: Wed Aug 06, 2025 1:13 pm 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.
if you are honest to yourself, it's one of those "look mum no plugin" workarounds that does not do the trick (in round robin you have to assume 3-note chords and use 3 layers to reliably route lowest note to layer that is supposed to handle the lowest note, as soon as you hit it with 4 notes that is doomed)...
You only said split a chord into individual layers... Note FX Selector does just that.

Now you just added a new criteria, sorting notes from lowest to highest.

The Note FX Selector sorts by order played. But for this purpose, Round Robin is not the correct mode to use. "Free Voice" mode always resets. So I have a preset with 6 layers. Whether I play a chord with 3, 4, 5, or 6 notes, the first note played will always be layer 1.
It has occurred to me that Bitwig is the Reaper of this class of DAW, Bitwig is to Ableton as Reaper is to name your favorite standard tape workflow focused DAW.

Some people see these kinds of solutions as efficient while others see them as difficult to use and understand. I've only recently engaged with Bitwig, and I did so for specific reasons, so none of the complaints in this thread mean much to me, Bitwig did not replace either Ableton or Reaper for me. However, I can see the similarity for those that enjoy abstracting problems into general reusable solutions, vs those who prefer a more procedural take on software interaction.

Post

coroknight wrote: Mon Jul 14, 2025 4:19 pm The problem with languages like JavaScript, python, and lua is they aren’t particularly great at real-time audio processing because they’re interpreted and garbage collected.
Well there is LuaJIT

and it can call C functions and use C data structures
https://luajit.org/ext_ffi.html

but I don't see why they'd do any of this, it kind of defeats the purpose of grid.

I'm still new to it, but I have some little nit picky issues with the current Bitwig, like the hover-over tooltips being displayed at the bottom but not in a popup under the cursor -- except sometimes it does have that for certain buttons (like the computer keyboard note input button).. why the inconsistency? There's a lot of inconsistent language in the UI, like "show plugin window" vs "toggle expanded device view of selected device" in the commander. So if I want to create a shortcut in commander, searching for "show plugin window" yields nothing.
And I expected the right-click context menu on a track to have a "show plugin window" for the main instrument device. Is changing the track color really so important that a color palette is the first thing in the context menu? Who is changing the track colors that often? The inspector is right there anyways with a color palette.

for more major stuff, I want more midi features like step input recording and midi capture. And audio unit support
"I don't do drugs. I am drugs." ~ Salvador Dali

Post

Jac459 wrote: Thu Aug 07, 2025 3:44 pm
Sorry I may have missed something here but I can't imagine better implementation than Bitwig for that. Just automate a global macro then link other macros to this macro. You can even use curves as a transfer table if you want to change a bit how slave macros react to the master macro. Pretty great implem to me.
That's good functionality for sure.

For me, I'd like to be able to e.g. record a volume automation for a tool, and be able to cut and paste that block of automation, into other places. Maybe under other clips in the arranger, but also to complely different tracks and parameters, e.g I might want to use that automation on the filter of a different track, and then maybe in other different places as well.

Post

pdxindy wrote: Fri Aug 01, 2025 2:48 pm 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.
I've had a couple of goes and struggling to get it working consistently.

I was able to route the pad to an audio receiver, and it worked for one drum kit load, but I couldn't work out if I needed pre or post, and it didn't keep the settings.

I since tried, having reread your comment better :hihi:, and was trying to use the tracks audio in, but was struggling a bit with this too.

I think this way could also make it possible to record the audio for multiple channels at the same time as well so I will persevere.

I did think of a new feature I will request... Bounce Group to Group.

If I have a nested drumachine with split out channels and local FX routing, it would be great to say Bounce Group to Group and have Bitwig create an audio channel based group to match the original group and bounce out all channels in one go. And who knows, perhaps even have an option to copy FX over in place as well.

Post

I can see there's something new automation features coming. Is it stereo automation ? Looks like a two lines of automation. Looks busy and confusing.

Post

Jac459 wrote: Thu Aug 07, 2025 3:44 pm
pdxindy wrote: Thu Jul 31, 2025 11:52 pm
_leras wrote: Thu Jul 31, 2025 7:45 pm
pdxindy wrote: Wed Jul 30, 2025 2:17 pm 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. :hihi:
Let's see what Bitwig has implemented.

The curve I can imagine duplicating in multiple places is a simple ramp up or ramp down.
Sorry I may have missed something here but I can't imagine better implementation than Bitwig for that. Just automate a global macro then link other macros to this macro. You can even use curves as a transfer table if you want to change a bit how slave macros react to the master macro. Pretty great implem to me.
What do you mean by You can even use curves as a transfer table?
But my problem with this approach is - it is not easy to change it in a way that the same modulation will start at different time for various tracks and you still have to go track by track to route everything while moving automation clip in arranger is faster.

Post

fwsuperhero wrote: Fri Aug 08, 2025 6:39 am
Jac459 wrote: Thu Aug 07, 2025 3:44 pm
pdxindy wrote: Thu Jul 31, 2025 11:52 pm
_leras wrote: Thu Jul 31, 2025 7:45 pm
pdxindy wrote: Wed Jul 30, 2025 2:17 pm 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. :hihi:
Let's see what Bitwig has implemented.

The curve I can imagine duplicating in multiple places is a simple ramp up or ramp down.
Sorry I may have missed something here but I can't imagine better implementation than Bitwig for that. Just automate a global macro then link other macros to this macro. You can even use curves as a transfer table if you want to change a bit how slave macros react to the master macro. Pretty great implem to me.
What do you mean by You can even use curves as a transfer table?
But my problem with this approach is - it is not easy to change it in a way that the same modulation will start at different time for various tracks and you still have to go track by track to route everything while moving automation clip in arranger is faster.
I agree. One way to do shouldn't invalidate the other way. Because in the method I said, you need to plan ahead so it is slightly different workflow.

What I mean as a transfer table is that if you use a curves modulator and you set the speed to 0. Then you make the input modulation change the phase of the curves. You have a transfer curve.
If your curve is a perfect 45° line, then your output modulation will be like your input modulation. But you can also change the 45° line to a curve, or steps.
For example you can have your output modulation grow faster at the beginning and slower at the end. Or stop at the middle, and so on and so forth.

Post

Jac459 wrote: Fri Aug 08, 2025 8:27 am
fwsuperhero wrote: Fri Aug 08, 2025 6:39 am
Jac459 wrote: Thu Aug 07, 2025 3:44 pm
pdxindy wrote: Thu Jul 31, 2025 11:52 pm
_leras wrote: Thu Jul 31, 2025 7:45 pm
pdxindy wrote: Wed Jul 30, 2025 2:17 pm 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. :hihi:
Let's see what Bitwig has implemented.

The curve I can imagine duplicating in multiple places is a simple ramp up or ramp down.
Sorry I may have missed something here but I can't imagine better implementation than Bitwig for that. Just automate a global macro then link other macros to this macro. You can even use curves as a transfer table if you want to change a bit how slave macros react to the master macro. Pretty great implem to me.
What do you mean by You can even use curves as a transfer table?
But my problem with this approach is - it is not easy to change it in a way that the same modulation will start at different time for various tracks and you still have to go track by track to route everything while moving automation clip in arranger is faster.
I agree. One way to do shouldn't invalidate the other way. Because in the method I said, you need to plan ahead so it is slightly different workflow.

What I mean as a transfer table is that if you use a curves modulator and you set the speed to 0. Then you make the input modulation change the phase of the curves. You have a transfer curve.
If your curve is a perfect 45° line, then your output modulation will be like your input modulation. But you can also change the 45° line to a curve, or steps.
For example you can have your output modulation grow faster at the beginning and slower at the end. Or stop at the middle, and so on and so forth.
This approach to map a single modulator via a transfere curve to a target is built into Vital. It's a tremendously powerful tool.
Example: Source is a random generator R.
R is mapped via a "50% lower Square" to level of Lfo A.
R is mapped via a "50% upper Square" to level of Lfo B.
Both Lfos are set differently but modulate the same target. Now in 50% of time, Lfo A modulates the target, in the other 50% Lfo B.
This example ist just for intuition for how powerfull modulation "mapping" is.

Post

NER wrote: Thu Aug 07, 2025 10:09 pm
coroknight wrote: Mon Jul 14, 2025 4:19 pm The problem with languages like JavaScript, python, and lua is they aren’t particularly great at real-time audio processing because they’re interpreted and garbage collected.
Well there is LuaJIT

and it can call C functions and use C data structures
https://luajit.org/ext_ffi.html

but I don't see why they'd do any of this, it kind of defeats the purpose of grid.
LuaJIT is still garbage collected because garbage collection is a pretty fundamental attribute of a language. So that’s still not ideal.

And yes, calling C via FFI works because… you’re calling code written in a non-garbage collected language. So you see how that’s a cop-out answer?

It doesn’t defeat the purpose of the grid, it compliments it. Don’t worry, nobody is trying to take the grid away from you.

Post

coroknight wrote: Fri Aug 08, 2025 4:46 pm
NER wrote: Thu Aug 07, 2025 10:09 pm
coroknight wrote: Mon Jul 14, 2025 4:19 pm The problem with languages like JavaScript, python, and lua is they aren’t particularly great at real-time audio processing because they’re interpreted and garbage collected.
Well there is LuaJIT

and it can call C functions and use C data structures
https://luajit.org/ext_ffi.html

but I don't see why they'd do any of this, it kind of defeats the purpose of grid.
LuaJIT is still garbage collected because garbage collection is a pretty fundamental attribute of a language. So that’s still not ideal.

And yes, calling C via FFI works because… you’re calling code written in a non-garbage collected language. So you see how that’s a cop-out answer?

It doesn’t defeat the purpose of the grid, it compliments it. Don’t worry, nobody is trying to take the grid away from you.
If you want falling speed. Go RUST.

Post Reply

Return to “Bitwig”