6/12/2023 0 Comments Ardour 3.3![]() As before, I can and did do this, but it is an unreasonable expectation of users who haven't been software developers at some point in their lives, and a _miserable_ user experience.Among other changes in this release, there’s now better handling of MIDI encoders, proper support for MIDI strips, expanded MIDI rewriting example script, better MIDI support on ARM devices like the Raspberry Pi, and improvements to the dark theme. But either requires knowing (or learning about) the project file and directory structure. The only way to recover from this position without session loss is either to find all your new A3 recordings and re-import them into the A2 version of the project using A2, or create a new A3 project, find all the pieces, reimport all of them, and reimplement all your mixing and effects. ![]() Continuing to try to use an A3 project which will continue to degrade as they record more material (obviously unacceptable). losing all the work they've done since importing the project into A3 (by going back to A2 and using the A2 version of the project file)Ģ. Once in this position, users have a choice of two failure modes:ġ. And the more you create new recordings in it, the worse it gets. So just reopening the project in A2 would've meant throwing out six sessions.Īnd, of course, from the A3 perspective, the project is corrupted. As far as loading the A2 version is concerned, I hadn't done anything. Now, when this happens, here's what you have:Ī2's version of the project master file (the -2000 project) doesn't know about any of the new work done in A3. In my case, I had _six more recording sessions_ across _four projects_ that were affected. So the user _keeps working on the project in A3_ - or, at least, I did - until, some number of sessions later, _then_ it explodes. Everything seems fine, and the user _doesn't know this is going to explode_. Remember, the A3 project corruption (which we should be talking about really in bug 5663 because that's where it's documented) doesn't happen immediately. That's one of the ways in which you lose the data. (See also my comments on bug 5663, which results in a corrupted session (in A3) or lost-to-the-session data if you revert to A2, which doesn't know about the new files - you have to know about the internals of Ardour's project structure to find them and try to bring them back.) (If you want to be REALLY nice you could point to the 2.6.14 download point after they hit Cancel, in case they didn't.) It's the land mines laid down that I'm not fine with. I am _fine_ with that being the decision. I kept 2.6.14 on my machine for that very reason. Had I seen a dialogue like that, I would've hit cancel. ![]() I ended up having to rebuild every project where I did that. I was hesitant about importing A2 projects into A3, but then it said "here y'go! All done!" so I took that as a sign of dev team confidence, which was _highly misleading_. But the point remains: make it really clear: THIS COULD REALLY HURT YOU.Īt least this way, they'd be warned. Some Ardour 2 projects fail to import successfully into Ardour 3. Say, have it bring up a second dialogue, after the user selects an unimported A2 project, but before running the import code. It's the kind of thing that drives people away forever.Īt very, _very_ least, A3 should warn users. Silent data loss and/or delayed session corruption(!) is a brutally horrible user-case scenario. ![]() THAT SAID: given that, 3.x really should not claim to import 2.x sessions, as it currently does, or it should import them read-only but allow export. Not striving for good A2 to A3 import is a perfectly reasonable decision. ![]()
0 Comments
Leave a Reply. |