[FR] Arrangement timeline background colours.

[mikoatkvr]

(* copied from my request sent to Tech Support *)

Hi Guys, I am a very happy Bitwig user on Linux.

There are a few feature requests I have in mind ( which will no doubt be requested in due time ), but one I personally find useful from using Renoise in particular is having the tracks timeline highlighted with colour.

I see this as working in 2 methods for Bitwig:-

(1) Arrangement Timeline tracks always have a background colour ( which is of 50% or less opacity of the original track colour.

(2) Only a selected track will be highlighted during a drag and drop operation.

I think that (2) will be useful when we want to drag a track segment further into the song where there are no other segments to compare and make sure we have not drifted into another track by accident.

I have made a mockup which will be attached to the same request on Bitwig forums ...

thanks Mikobuntu.

[TristanMendoza]

I like this idea

[llze]

yep, would be nice addition imo. Also would be cool if one could define the amount of opacity for every track individually.

[TristanMendoza]

Yes that would make it so much better, an option to turn it on and off and then the opacity

[codec17]

Every good visual enhancement i like!
This one i didnt think about... But yeah, when you drag a clip from one monitor to the other you have to watch carefully that you drop it on the right track. Specially with so little color options.

This is NOT (for me at least ) a request for more colors , because i personally like the little color scheme, keep it nice and clear.

+1 for me here!

[takaii]

Nice idea, one problem. i think this will add a bit more slow speed when workinng, i have trouble selecting clips on a big project without some loading time. Doing things worse might add more delay times. I have no idea why projects gets soo slow when they get big -.- my computer handles bitwig

[mikoatkvr]

@ronnyrydgren I think this would not effect speed so much ( if any ) at all as the GUI runs in a separate process as the audio engine, but I hear you on larger projects can naturally be more CPU intensive, but remember bouncing out to audio from instruments or even bouncing an audio clip to unload the effects can be a great life saver

[Jolaff]

+1

[takaii]

@ronnyrydgren I think this would not effect speed so much ( if any ) at all as the GUI runs in a separate process as the audio engine, but I hear you on larger projects can naturally be more CPU intensive, but remember bouncing out to audio from instruments or even bouncing an audio clip to unload the effects can be a great life saver

So you say that bouncing is solution for everything? Ive noticed that clips and tracks take cpu and slow also things down, even if its seperate. I tried creating 800 tracks, that made the daw soo slow. Nothing on just audiotracks. I have a couple big projects that goes slow copying midi clips and stuff without much processor use. Bouncing doesnt help with that. Its a great idea. But i rather see the daw run a little smoother than having more feature slowing things down more when project gets big.

[mikoatkvr]

No not really, you could say tho bouncing is a workaround in any daw to save CPU. i'm no expert in any of this ( that is down to the devs )... certainly it is true that eye candy will slow Bitwig down to a certain extent, but if it is a small footprint in CPU in exchange for better functionality and workflow , then I'm all for it.
In my limited experience working with the devs on LMMS I believe just adding tracks even tho they are not being used, will still increase DSP load.
I should try some kind of test like you mentioned and see if i can debug whether loading empty tracks has much effect on the GUI thread or the DSP. I kind of see that no matter how many tracks are loaded there will only still be same amount of screen real estate used at any one given time, tho I could be wrong.
My main objective with this feature request is to just have one ( or multiple if chosen ) track lane highlighted only during a drag and drop operation, so this should be fine for CPU.

thanks Mikobuntu

[takaii]

No not really, you could say tho bouncing is a workaround in any daw to save CPU. i'm no expert in any of this ( that is down to the devs )... certainly it is true that eye candy will slow Bitwig down to a certain extent, but if it is a small footprint in CPU in exchange for better functionality and workflow , then I'm all for it.
In my limited experience working with the devs on LMMS I believe just adding tracks even tho they are not being used, will still increase DSP load.
I should try some kind of test like you mentioned and see if i can debug whether loading empty tracks has much effect on the GUI thread or the DSP. I kind of see that no matter how many tracks are loaded there will only still be same amount of screen real estate used at any one given time, tho I could be wrong.
My main objective with this feature request is to just have one ( or multiple if chosen ) track lane highlighted only during a drag and drop operation, so this should be fine for CPU.

thanks Mikobuntu

Well i am talking that it goes slow to select many clips in a big project.
I have not even the bitwig engine active still lags like shit.
Check video below and you see yourself how slow it goes.

https://www.youtube.com/watch?v=6AJ3d4Plf6Q

Its one of those things that i am not really happy at all with bitwig.

[llze]

Its one of those things that i am not really happy at all with bitwig.

also getting that issue, did you write to tech support already about this?

[takaii]

Its one of those things that i am not really happy at all with bitwig.

also getting that issue, did you write to tech support already about this?

Just feels like bitwig is slow. Should not be like that. I dont think its a bug, i think its just slow, might be due to the gui is in java...

[llze]

well yes, i also think so. Dis you ask support about that?

[takaii]

No have you? I know people have complained about bitwig beeing slow before. Its a bit to annoying, still i choose this daw before any other. i just whish it wasnt like this.