What drives you crazy in Bitwig?

[machinesworking]

This has got to be a Windows thing. Here in Mac OS Alt/Option drag copies whether you select it before or after you start dragging. The only difference is it shows a plus sign if you do it after. In both cases you can let go of the Alt key before you settle and it will not copy it.

Oh, I thought the complaint was coming from macOS user actually, because on Windows adding Alt when dragging a clip bounces it in place on the fly* and when you put it somewhere it's already an audio clip. You add Ctrl while dragging to duplicate, I believe.

* BTW that was the excuse I heard from Support when asked about why Alt + click on clip's header won't let me rename it like everywhere else does. I thought no one would be confused about difference betwee adding Alt before or after clicking, but apparently I'm wrong

OK so yeah it's different on a mac. Mac OS uses Control as a right click, so on a Mac it's Option and Control plus drag together to bounce in place. Also renaming is like Ableton, Command R, not my favorite thing, but I guess it makes sense on cross platform applications that Control will have a different shortcut etc. since on Mac OS you would need more than just Control to use it since it's hardwired to right click.

[Dionysos]

I thought no one would be confused about difference betwee adding Alt before or after clicking, but apparently I'm wrong

I think subtle differences in behaviour like those should be avoided as much as possible in general. A UI should be "forgiving" and not require too much precision for its operation. It's a similar issue to the one I described above, where you have to press Shift to override snapping after the click, otherwise you'll also do the "add to multi-selection" action at the same time. Sure, the way it works now is "logical" in a way, but IMO unexpected, and the UI would be better if "add to multi-selection" was an explicit, distinct command (Shift + click, or Shift + drag from an empty space). It shouldn't be added into the mix if the user is performing a separate action that can also be modified using Shift.

EDIT: Just realised it's not "Add to selection", but "Select range" that's causing the conflict.

[antic604]

I think subtle differences in behaviour like those should be avoided...

Right. But this way we're loosing half of potentially available workflow features in the name of the UI being "forgiving". My understanding is that DAWs by definition have certain level of complexity to them, have a non-insignificant learning curve and it's not rocket science to learn and muscle-memorize the right order of actions, same like I don't put the shoes before wearing pants / trousers

Ideally, modifier keys & mouse / touchpad gestures should be freely customisable, which would address both needs.

[ReleaseCandidate]

The whole idea of modifier keys is they MODIFY the action you're doing:
- if you hit the modifier while already dragging something, it changes the end result of dragging
- if you hit the modifier before clicking something, it should change the result of clicking, for example temporarily swap the pointer tool to a razor, or mute, or scrub, etc. whatever's available in given software and specified by the user

You're confusing stuff now.
You are right, modifiers modify actions.
Clicking and dragging are two different actions with a problem: you must click something to start dragging. And a click is very short, so you have to press the modifier before clicking.
So your idea of how modifiers work are the result of the problems of the recognition of clicking and dragging the mouse, not a general rule. Or, rephrased, these are not intentional and very hard to get right (the timing when a click starts to be a drag and similar).

[antic604]

You're confusing stuff now.
You are right, modifiers modify actions.
Clicking and dragging are two different actions with a problem: you must click something to start dragging. And a click is very short, so you have to press the modifier before clicking.
So your idea of how modifiers work are the result of the problems of the recognition of clicking and dragging the mouse, not a general rule. Or, rephrased, these are not intentional and very hard to get right (the timing when a click starts to be a drag and similar).

No, I'm not. I understand a difference between clicking and dragging, it's just that you first need to click (and don't let go) before you even start dragging. Perhaps I should've made that clearer.

I really like the workflow available in many other DAWs, where holding a modifier BEFORE doing anything it will temporarily swap current tool to something else, therefore I prefer to have a distinction between holding a modifier key before and after clicking (& dragging).

[ReleaseCandidate]

You're confusing stuff now.
You are right, modifiers modify actions.
Clicking and dragging are two different actions with a problem: you must click something to start dragging. And a click is very short, so you have to press the modifier before clicking.
So your idea of how modifiers work are the result of the problems of the recognition of clicking and dragging the mouse, not a general rule. Or, rephrased, these are not intentional and very hard to get right (the timing when a click starts to be a drag and similar).

No, I'm not. I understand a difference between clicking and dragging, it's just that you first need to click (and don't let go) before you even start dragging. Perhaps I should've made that clearer.

I really like the workflow available in many other DAWs, where holding a modifier BEFORE doing anything it will temporarily swap current tool to something else, therefore I prefer to have a distinction between holding a modifier key before and after clicking (& dragging).

You didn't understand (or read) what I wanted to tell you: having to press a modifier before a keypress or a mouse click isn't a design decision, but a technical necessity (because click is so short and a keypress can be very short too). And if I'm not mistaken, I wrote about clicking and dragging .

[Dionysos]

Right. But this way we're loosing half of potentially available workflow features in the name of the UI being "forgiving". My understanding is that DAWs by definition have certain level of complexity to them, have a non-insignificant learning curve and it's not rocket science to learn and muscle-memorize the right order of actions, same like I don't put the shoes before wearing pants / trousers

Disagree. There are always trade-offs to be made, but making things "feel right" (or rather, non-fiddly) doesn't necessitate sacrificing functionality, unless you'd want to go as far as e.g. FL Studio, where the left and right Shift and Cmd keys do different things. I love how in Bitwig you can use the number keys as modifiers if you keep them pressed, proving that there are more elegant ways to enable powerful workflow features without relying on obscure shortcuts.

Ideally, modifier keys & mouse / touchpad gestures should be freely customisable, which would address both needs.

IMO that's a bit of a lazy request, and looking at the Bitwig settings I don't think it's aligned with their philosophy around customisability. Making mouse & modifier key actions customisable is VERY complex. And the basics need to be rock solid before it would even help, e.g. to address the issue I reported above a degree of customisability would be needed that I wouldn't even expect from a config monster like Reaper. (Unless you consider changing one of the "conflicting" shortcuts to some other key a solution, which I don't.)

[antic604]

...having to press a modifier before a keypress or a mouse click isn't a design decision, but a technical necessity (because click is so short and a keypress can be very short too). And if I'm not mistaken, I wrote about clicking and dragging .

How is it a "technical necessity" when it's already implemented in a way, where ADDING a modifier WHILE ALREADY clicking & dragging changes the behaviour? I was never talking about "just" clicking, because it's obvious you can't add modifier after that. As I said, I should've made that clearer but I didn't because I thought it doesn't need explaining.

[antic604]

...unless you'd want to go as far as e.g. FL Studio, where the left and right Shift and Cmd keys do different things...

Obviously I don't! Striking the right balance between ease of use and flexibility is key. Apparently for me Bitwig could move a bit to the right on that scale, for you a bit to the left. That's why we have this discussion. And hopefuly devs are reading & considering both stances

...Making mouse & modifier key actions customisable is VERY complex. And the basics need to be rock solid before it would even help...

But that is exactly my point - providing customisation for clicks, drags, swipes, modifiers pre/post, etc. would allow to implement solid & consistent base standard, but for those that'd want it to customise them to their liking. That could be even hidden behind some "advanced" options menu, that would require a phone call to Berlin to unlock

For example, I'm moving daily between Bitwig on Windows & Linux and it always takes me 5-10 minutes to adapt to the fact that on Windows Ctrl + mouse wheel to zooms in/out horizontally and Ctrl + Alt + mouse wheel zooms in/out vertically; whereas on Linux it's in reverse! Customisation would solve that one & for all in 10 seconds.

BTW, it's not a priority for me - I can adapt to anything, almost - so calling it a "lazy request" isn't really necessary or constructive...

[codec17]

I just stumbled on it..
-But missing VST,s. And when i miss one or two (I had the habbit to try many free crap. )
That when i open the mixer those boxes are red or something. Now when damage controlling i need to search and search. And maybe even better? An indication WHERE i just used them, With all those pre/post and nested devices it can take a while. (yeah yeah i had to know better )

-Select wave in browser.....No matter what. arranger/clip/drummaschine.... ( i knew it was somewhere, its been a while i fired up bitwig but is it there? )

-And when for example you got 30+ tracks with mixer view underneath arranger, and you working on track 1 and when selecting track 30 my mixer doesnt "scroll" to that track. Now i need to scroll by mouse to the desired track. ( Another one, all the empty space in the mixer, but not clickable for selecting, only the top header. )

These are just 3 i stumbled on this morning.. I know there are many to come. Dont get me wrong. I love BWS! So i hope they will improve workflow thingies in next update instead of devices etc.
Those little things in life...

[Dionysos]

BTW, it's not a priority for me - I can adapt to anything, almost - so calling it a "lazy request" isn't really necessary or constructive...

Sorry, that came out the wrong way. It's not so much your request that's lazy (it's valid), but the design approach. Sometimes, in software, things are designed sloppily, but instead of fixing the issue at the root, developers provide customisation options and basically leave it up to the users to work around it, ignoring the fact that the vast majority of users of any software will make do with (& keep suffering under) whatever the defaults are.

So, yeah, customisability is great, but the defaults should be very solid to begin with.

[antic604]

So, yeah, customisability is great, but the defaults should be very solid to begin with.

Amen! ( or whatever floats your boat )

[billcarroll]

1. You have to be almost too precise when selecting a handle on the edge of a clip.
2. Also, the pen tool looks a little too blunt. A little more precision for all pointer tools would be nice.
3. When creating new automation, the line showing current value of the parameter before creating an automation point is almost invisible.
4. You can't tell on the arrange which track header is selected. No visual indicator.
5. Automation on group tracks is a not consistent with regular tracks. It's hard to get the automation edit panel to show for group tracks.

Looks like they fixed #5 with 3.3.4. Reporting bugs does help

"Automation editor did not show automation for group tracks [23913]"

[tshear23]

Having to rename clips and tracks in the inspector and not just by double clicking and typing in the new name has bummed me out since the beginning.

[antic604]

Having to rename clips and tracks in the inspector and not just by double clicking and typing in the new name has bummed me out since the beginning.

Ctrl+R on Windows