<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 14, 2014 at 12:58 PM, Vincenzo Ciancia <span dir="ltr"><<a href="mailto:vincenzoml@gmail.com" target="_blank">vincenzoml@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br>
<br>
I have been a very strong supporter of open source for 20 years. This<br>
is going to be a desperate rant.<br></blockquote><div><br></div><div>I am very sorry about the losses you've suffered from using Ardour 3 for working with MIDI.<br><br></div><div>I have been aware of some kinds of data losses, and worked very hard to fix them. I also came to understand how they got into the program, which is something I won't bore you with (*). It is notable (for me, as a developer) that these losses all required very specific workflows, which is why many users of the program have not been affected by them at all, but others have suffered from them a lot. We have also had essentially zero users that have found any actual recipes for these losses, which has made them very hard to debug, identify and solve. <br>
<br></div><div>I have been waiting to make another release of 3.5.X with another round of fixes for the losses, but have held back because I became aware of another related matter. This does not involve actual data loss, but rather the appearance of it. While fixing other kinds of losses, I introduced a situation where creating an empty MIDI region, saving the session and then reloading the session later would complain about missing files. No data is lost in this case, but the message needs to vanish. Before I can do that, I need to come up with a decision on what to do about these empty MIDI regions, which I have found difficult, and this has slowed the released of the next hot-fix release.<br>
<br></div><div>I will try to prioritize coming up with an answer for how to handle empty MIDI regions when saving sessions, and will then get the next 3.5X fix out ASAP.<br></div><div> <br></div><div>--p<br><br></div><div>
(*) actually, for those who care, the story is interesting from a software engineering perspective. Ardour used to create "stub" files for audio + MIDI before recording - empty files on disk. If anything was ever recorded, these files would grow in size; if not, we would try to remove them at session close and also at session startup. It was an ugly design, but it did have one key feature: to check if a particular name was already in use (e.g. for the next take of a particular track), you could look at the files on disk to check for names already in use. Later, we decided to avoid cluttering the disk with all the stub files, but didn't realize how we had also used them as a "is this name available" test. The result has been that you could end up (with certain workflows) where Ardour would contain two objects with the same name, but one of them believed it could be removed and the other knew it could not be. Since they both referred to a real physical resource (a file on a disk) this was a problem - during session closing, the one that believed it could not destroy the file would not, but the other one would remove it - BOOM! This didn't happen all the time - in fact, it requires quite a specific set of actions to make it happen, but apparently those actions were common enough to trigger the problem.<br>
</div></div></div></div>