Tracks should explicitly remember last colour used.

[mikobuntu]

In older versions of LMMS e.g 0.4.15 if i changed the colour on a track in the song_Editor they would be remembered when building blocks on various tracks, but now whichever colour is last assigned will be applied to all other tracks worked in.

[musikBear]

confirm win32xp 092

[mikobuntu]

• note it is good to be able to change maybe 1 block's colour within a track for perhaps a reference point in our song , this behaviour would be ok as long as whenever we switch to a new track it's original colour is remembered.

[Enhancement] I think the logic here would be to have our track ALWAYS remember the colour closest to the start of our song so then if we change 1 block of colour anywhere it wont affect our tracks main colour.

[Sti2nd]

I like it better as it is now, the colour is remembered within each B+B track, but you can still change individual segments (or selections). I can understand that if you use the colour of B+B segments for dividing the song into parts, it would be good to remember the last used colour. Personally I don't do this, so therefore I like it better as it is now, and do remember that you can select and paint multiple segments!

[mikobuntu]

@Sti2nd which version/branch of LMMS are you currently using? You are describing the old preferred behaviour .

whenever i say " I think the logic here would be to have our track ALWAYS remember the colour closest to the start of our song so then if we change 1 block of colour anywhere it wont affect our tracks main colour." I mean this as a feature request, but the original bug still stands.

[Sti2nd]

I am using 1.0.3

[musikBear]

I like it better as it is now, the colour is remembered within each B+B track, but you can still change individual segments (or selections)

👍 for that - is most flexible, i think. ( One speculation around this, could be a behavior similar to 'last note', so kind of let corsor be a color-picker - but thats enhancements :)
Its also important that a lmms features does not flip-flop in all directions at every release. Users like stability and expects behaior as in previous releases -except where obvious better solutions are implented, ofcause. Later all great idears on marking selecting and editing, should be a release-focus (imo)

[Spekular]

@tresf to be consolidated into #1665 as this has to do with user definable colors.

[tresf]

This bug report has been consolidated (at least for now) into a placeholder #1665 for better color handling in general. Feel free to update this bug report or the parent bug as needed.

[tresf]

@tresf to be consolidated into #1665 as this has to do with user definable colors.

A bit torn on this one as it's a regression. Since it's been open so long, I'm going to consolidate it but I feel that it did deserve the label bug when it was written.

As part of a pruning effort, this enhancement request is archived into a dedicated "Better Workflow" checklist here #4877.