[Ardour-Users] So many lost midi files

[Paul Davis]

On Mon, Jul 14, 2014 at 12:58 PM, Vincenzo Ciancia <vincenzoml at gmail.com>
wrote:

> Dear all,
>
> I have been a very strong supporter of open source for 20 years. This
> is going to be a desperate rant.
>

I am very sorry about the losses you've suffered from using Ardour 3 for
working with MIDI.

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.

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.

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.

--p

(*) 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-users-ardour.org/attachments/20140714/54ceea40/attachment.htm>