View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006893 | ardour | bugs | public | 2016-06-08 17:11 | 2020-04-19 20:18 |
| Reporter | dsreyes1014 | Assigned To | x42 | ||
| Priority | normal | Severity | major | Reproducibility | random |
| Status | closed | Resolution | fixed | ||
| Platform | Linux | OS | Gentoo | ||
| Product Version | 4.7 | ||||
| Summary | 0006893: Pans Get Centered After Reopening | ||||
| Description | As it says in the Summary all pans on every track get recentered with no error logs to show. I am using some OvertoneDSP and EQ10Q plugins. | ||||
| Steps To Reproduce | Reopen track with plugins. | ||||
| Tags | No tags attached. | ||||
|
|
There were two bugs in 4.7 (and earlier) which have meanwhile been fixed: A) Ardour using a non-english locale where decimal separators are comma (1,0 vs 1.0) -> possibility to loose panner state B) Create a track with linked send-panners. for (B) a workaround is to first save/re-open the session after creating the track or disable the preference to link send panners by default. |
|
|
Platform: Gentoo 64 bit current, Ardour versions 4.7 and 5.4. Intel i7 4 cores, 16 GB Ram, jack version 0.121.3-r1 from Gentoo repository. I apologize that this bugreport is be so long, but I prefer to give too much information than too little :) I had pans on all my audio tracks centered today. It seems I now have a session that will shed some light on this problem. If I search the session file for words "pan-azimuth" I can see that pan information is there, but when I load that session in Ardour 4.7 or 5.4 all pans will get centered. Steps to reproduce: - Download my session, it is 33 MB although I have deleted all audio (deleting further files (peaks) won't get it under the 5 MB limit of Mantis): https://dl.dropboxusercontent.com/u/2071830/Hold_On_Tight_Girl-pans_centered_bug.zip - Go to the session directory and search the latest session file for keyword "pan-azimuth": grep "pan-azimuth" "Hold_On_Tight_Girl Versio 080 Versio 8 valmis.ardour" - You can see that audio channels have pan information there. - Open the latest sessionfile into Ardour 4.7 or 5.4 and check the pan pot positions, they are all centered. - Save the session with: Session / Snapshot (& Change To New Version), give the save a new name. - Go to the session directory and search the new session you saved for keyword pan-azimuth. - Now you can see that in the session you saved all pan information got lost and pans are centered. This suggests to me that the session file is either corrupt or the parser freaks out for some reason losing information or both. Anyway if I understand this correctly it seems you can rescue the session by saving it as a new snapshot and manually searching for the pan values from the old file and inserting them to the new snapshot. I have not tested this though. Additional background information: Plugins used in the session: - EQ6Q Mono by Pere Rafols Soler - Invada Compressor - Invada Early Reflections Reverb (sum L + R in) I worked on this song for 12 hours yesterday with Ardour 4.7. Creating new snapshots when I wanted to have a backup of the current state of it. I name the snapshot session files by adding a number at the end of the name and increasing it with each save. Yesterday I created snapshot session versions 54 - 80. I also hit ctrl + s every 1 - 5 minutes to save the session. While working on the session I recorded new instruments to it and every time I failed to play the instrument correctly (many many times :) I quickly hit stop, ctrl + z, ctrl + s, and started recording the part again. Ardour worked without problems all through the 12 hour day. During this time I never closed Ardour and it never crashed. There is crash data in the session folder, but if Ardour really crashed it must have done it silently while I shut it down at the end of the day. Late in the evening I noticed a slight slowdown when doing things like splitting a region. At the start of the day the operation was instantaneous at the end it took about 1 second to perform. This might be irrelevant though and Ardour worked correctly and fast enough for me to work quickly with the session. When I got the work finished I used stem export to export each instrument to its own file. I use bussing and it makes exporting stems very easy. In the morning I opened the last session (version 080) played it back and realized the stereo image had collapsed to mono. I also opened session version 079 and it also had pans centered. I did not touch any other snapshot files and I did not save 079 or 080 on top of the originals from yesterday. I never had pans centered before and there were some new things I did yesterday that I haven't done before. These might have nothing to do with the problem though: - I used bussing which I usually don't do. - I used track groups which I usually don't do - I used stem export to export range "Hold On Tight Girl Versio 8" and exported all bussed to their own files. I usually don't use the stem export function. |
|
|
Just one more note about my report above, since I did not manage to say it clearly enough. It seems to me that there is correct pan information in my session file I talk about in the report, but Ardour loses this information when it loads the file. This makes me suspect that the format of the session file is somehow corrupt. |
|
|
Today I dug deeper into my session snapshot files and found out the following: Thanks to the way I work saving snapshots as I go there is now evidence in the adjacent session snapshots of how the pan information disappeared as some kind of session data corruption progressed. The last correctly saved session snapshot is versio 57 (time stamp 14:55) and there is my correct pan info on these tracks: Track 2 Laulu 2 Track 3 Laulu 3 Track 4 Komppikitara 1 Track 5 Komppikitara 2 Track 6 Solokitara 1 Track 7 Solokitara 2 Track 8 Solokitara 3 In session snapshot 58 (time stamp 15:34) pan info starts to dissapear from top tracks: Track 2 Laulu 2 = Pan info has been reset Track 3 Laulu 3 = Pan info has been reset Track 4 Komppikitara 1 = Pan info is still there Track 5 Komppikitara 2 = Pan info is still there Track 6 Solokitara 1 = Pan info is still there Track 7 Solokitara 2 = Pan info is still there Track 8 Solokitara 3 = Pan info is still there In session snapshot 59 (time stamp 16:28) more tracks lose pan info: Track 2 Laulu 2 = Pan info has been reset Track 3 Laulu 3 = Pan info has been reset Track 4 Komppikitara 1 = Pan info has been reset Track 5 Komppikitara 2 = Pan info has been reset Track 6 Solokitara 1 = Pan info is still there Track 7 Solokitara 2 = Pan info is still there Track 8 Solokitara 3 = Pan info is still there There are no snapshots numbered 60 - 69, I have jumped over this number range while saving snapshots. In session snapshot 70 (time stamp 17:12) last tracks lose pan info: Track 2 Laulu 2 = Pan info has been reset Track 3 Laulu 3 = Pan info has been reset Track 4 Komppikitara 1 = Pan info has been reset Track 5 Komppikitara 2 = Pan info has been reset Track 6 Solokitara 1 = Pan info has been reset Track 7 Solokitara 2 = Pan info has been reset Track 8 Solokitara 3 = Pan info has been reset All this time Ardour was open and I played the session and pan info was playing correctly. Only the state saved on the disk seems to be broken somehow. And it is very interesting that pan info did not disappear all at once, but gradually during a 2 hour 17 min period probably one track at a time. |
|
|
I now know how the pan information disappeared and what caused it. The pan info got reset on mono audio tracks where I added a send to a stereo bus. I added sends to tracks one by one in session snapshots 58 - 70. This behaviour can be reproduced with Ardour 4.7.0 like this: - Start Ardour 4.7.0 and create a session - Create 1 mono audio track - Set the pan on the audio track to hard left - Save session - Create 1 stereo bus - Add a send to the audio track that sends to the stereo bus. Note that the pan pot on the audio track stays on hard left. - Save the session as new snapshot - Close Ardour, start it up again and load each snapshot. Pan info on the first one is correct but reset on the second snapshot. I tested this procedure with Ardour 5.4.0 and when I add the send to the audio track Ardour immediately centers the audio track pan pot. This is correct behaviour in a way, but would it be more correct if the current audio track pan value got copied to the newly created send and not the other way around. One could argue that the pan value of the newly created send can be changed without any user data being lost. But when resetting the user set pan value on the audio track you lose some data. x42 probably tried to point out this behaviour I just found out, but I didn't understand his message. I thought that I have not deliberately created any tracks with linked send-panners, but it seems Ardour does this linking automatically for you when you create sends. I can relatively easily repair my messed up session by looking up the pan values "pan-azimuth" in the session file, converting the value to percents and then dragging each pan fader back to it's original value in the session. On my behalf this bug report can be closed. Hopefully we will get comments from the original poster also. |
|
|
There's Preferences > Solo & Mute > Send Routing > Link panners ... by default. it was off here. There is indeed a remaining oddity: Ardour 5.4: enable link panner by default. 1) create session 2) add mono track + stereo bus 3) pan mono track hard left 4) add an aux-send -> panner of track is reset (copied from send's default) 5) remove send 5a) go back to (4) -- behaves the same. 6) save, close session 7) re-open session 8) add aux-send -> panner of track stays and is copied to send. I'll look into it. |
|
|
Should be fixed for good in Ardour 5.4-122-g228556a Please confirm |
|
|
Yes it is fixed (tested with 5.4.252), thanks x42 :) |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-06-08 17:11 | dsreyes1014 | New Issue | |
| 2016-06-08 21:58 | x42 | Note Added: 0018243 | |
| 2016-10-05 17:06 | mhartzel | Note Added: 0018774 | |
| 2016-10-05 18:58 | mhartzel | Note Added: 0018775 | |
| 2016-10-06 15:32 | mhartzel | Note Added: 0018777 | |
| 2016-10-06 22:26 | mhartzel | Note Added: 0018778 | |
| 2016-10-13 16:58 | x42 | Note Added: 0018803 | |
| 2016-10-13 18:02 | x42 | Note Added: 0018805 | |
| 2016-10-13 18:02 | x42 | Status | new => resolved |
| 2016-10-13 18:02 | x42 | Resolution | open => fixed |
| 2016-10-13 18:02 | x42 | Assigned To | => x42 |
| 2016-10-31 21:18 | mhartzel | Note Added: 0018894 | |
| 2020-04-19 20:18 | system | Note Added: 0023620 | |
| 2020-04-19 20:18 | system | Status | resolved => closed |
