View Issue Details

IDProjectCategoryView StatusLast Update
0007080ardourbugspublic2020-04-19 20:18
Reporterunfa Assigned Toovenwerks  
PrioritynormalSeverityminorReproducibilityrandom
Status closedResolutionfixed 
PlatformGNU/LInux PC AMD64OSLinux MintOS Version18 MATE
Product Version5.4 
Summary0007080: Master bus is shifted one place down after reloading a session
DescriptionSometimes when I open a project I was working of for a longer period of time (2 weeks+) the Master bus is not the first one on the top, but what was previously under the Master bus, has jumped above it. Now Master bus is second in the tracklist.

I shift it back into place and this usually happens again the next or some other time I load this project after saving my changes.
TagsNo tags attached.

Activities

Oliver

2016-10-29 16:40

reporter   ~0018871

I see the same effect, also Ardour 5.4.0. Xubuntu 16.04LTS (32 bit). Occurrence appears random to me.

ovenwerks

2016-10-29 20:24

reporter   ~0018874

Hmm, this happens if the first added track is audio, but not midi? when the first track is a midi track, it's order is 1. if the first track is audio it's order is 0. (looking in the saved session file)

timbyr

2016-10-30 09:46

developer   ~0018875

Last edited: 2016-11-02 05:10

I can reproduce this with a 5.4.226 nightly build.

One way to consistantly cause this is to:

1. Create a new Session
2. Create a new Track
3. Deselect new Track
3. Create another new Track
4. Save and Quit.
5. Restart Ardour and reload Session

The master track will now be below the First track in the Editor. In the Session file the First Track and the Master both have order=0 in PresentationInfo node.

timbyr

2016-10-30 10:06

developer   ~0018877

I don't think this is related to MIDI tracks though as I can reproduce in a Session with just two Audio tracks.

ovenwerks

2016-10-30 13:50

reporter   ~0018880

This should be fixed with commit 997b48baf72c87281ae4dc535c9b3994810d8e72

timbyr

2016-10-31 12:18

developer   ~0018890

I can still reproduce this with nightly build 5.4.252 which is built from commit 77c91067

I'll edit the steps to reproduce as I realize there was a step missing.

ovenwerks

2016-11-04 15:44

reporter   ~0018906

Spent much more time playing with it this time. Commit 1457050d7aa2f5e0bee1957ff3710f58c04a2c62 really should fix this. Please test it to death in case my testing has somehow missed some scenario.

ovenwerks

2016-11-07 16:18

reporter   ~0018918

Found and fixed yet another scenario... commit 932cc4d347f988b1bc712749ff9ba1684d165bc7
Any testing would be great.

system

2020-04-19 20:18

developer   ~0023665

Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.

Issue History

Date Modified Username Field Change
2016-10-28 08:49 unfa New Issue
2016-10-29 16:40 Oliver Note Added: 0018871
2016-10-29 20:24 ovenwerks Note Added: 0018874
2016-10-30 09:46 timbyr Note Added: 0018875
2016-10-30 09:46 timbyr Status new => confirmed
2016-10-30 10:06 timbyr Note Added: 0018877
2016-10-30 13:50 ovenwerks Note Added: 0018880
2016-10-30 13:50 ovenwerks Status confirmed => resolved
2016-10-30 13:50 ovenwerks Resolution open => fixed
2016-10-30 13:50 ovenwerks Assigned To => ovenwerks
2016-10-31 12:18 timbyr Note Added: 0018890
2016-10-31 12:18 timbyr Assigned To ovenwerks =>
2016-10-31 12:18 timbyr Status resolved => new
2016-10-31 12:19 timbyr Note Edited: 0018875
2016-11-02 05:10 timbyr Note Edited: 0018875
2016-11-04 15:44 ovenwerks Note Added: 0018906
2016-11-04 15:45 ovenwerks Status new => resolved
2016-11-04 15:45 ovenwerks Assigned To => ovenwerks
2016-11-07 16:18 ovenwerks Note Added: 0018918
2019-07-11 08:35 tomplatz File Added: 113.pdf
2019-07-18 13:21 x42 File Deleted: 113.pdf
2020-04-19 20:18 system Note Added: 0023665
2020-04-19 20:18 system Status resolved => closed