On Fri, Mar 4, 2011 at 1:03 PM, Gale Andrews <gale@...> wrote:
> | From James Crook <crookj@...>
> | Wed, 02 Mar 2011 22:09:06 +0000
> | Subject: [Audacity-devel] [Bug 26] Missing audio files play as silence,
> | without informing user it is missing, using On-Demand.
>> Besides lock being "difficult or impossible", which are quite serious
> My main experience is on Windows, but certainly you can't OS-delete
> a file imported into Goldwave or Cool Edit Pro at any time - Windows
> says the file is open in the application. Complainants who have lost
> files sometimes ruefully refer to "other editors" which prevent you
> deleting the file while it is in the editor.
> I've much less experience on Linux but I suspect it's more normal to
> delete the file if you want to. Ardour it seems copies in WAVs, as it
> still has the audio after deleting the file.
>> it also is a poor and still incomplete solution.
> I never presented it as a complete solution, but it potentially addresses
> a large part of the problem.
>> - It does not solve the problem of a USB key being pulled.
> Or the drive could fail or its cable become loose. I suggested in that case
> an immediate warning that the file isn't accessible. It's common on
> Windows, but I guess that could be easier to make happen if the app.
> has the file open.
> If we can't lock or sensibly keep the file open, then we can consider
> warnings. We already have the warning on playing, but we don't have a
> warning on editing. I regard that as an equal omission, because the audio
> is silenced without explanation after running an effect on the selection.
> A "warning on editing" would alert the user to Steve's scenario where the
> edit is just a cut and you then export.
> Neither warning is much help if your deletion bypassed the Recycle Bin, or
> your disk is full, thus limiting the chances of disk recovery tools salvaging the
> file. But we still have the option of a dependency warning on import, which
> you can switch off if you wish. It doesn't need to be elaborate. This solution
> could cover more bases than locking. We've done the right thing and
> informed the user. If they have a drive failure, then we have one warning
> in place now and could consider others. Steve has an alternative idea which
> is also valid, though I don't like the permanent extra menu item it creates:
I totally agree that it would be a shame to not fully reveal the
benefits of OD, but IMO having it as the default (without file
locking) is just too dangerous for many users. Having it as a specific
menu item (as per the wiki proposal) makes OD a visible option for all
users and distinguishes it from ordinary copy import.
Although altering the File menu is probably a minor change from a
programming point of view, it is a highly significant change from a
"user experience" perspective, and as such I think that it should be
addressed with some urgency before the release of Audacity 2.0 (which
is why I've been pushing the idea for over a year).
>> - It does not solve the problem of a required file being deleted when
>> Audacity is not open.
> Dependency warning on import addresses that.
>> - Locked files in windows sometimes seem to stay locked, even when the
>> program that was using them has finished. This is extremely annoying /
>> frustrating if you don't know how to fix it.
> Agreed it happens, but it can happen after you have played a file in
> Windows Media Player.
>> I think catastrophic loss of data, when users delete their source
>> thinking it is now in Audacity, from the reports we are getting, and
>> from Steve's recent Bugzilla issue 26 comment is a P2.
> Thanks for agreeing on that.
>> I have absolutely no problem with copy-data being the default.
>> Advanced users can discover referencing of data and
>> load-on-demand - and the risks.
> I'm partly repeating my -quality post, but:
> * Default copy-in means the majority who don't RTFM and are
> reluctant to explore will never find it.
> * The announcement/news item for 2.0 (if it mentions OD) will
> have to mention that you must turn it on in Preferences.
> I don't think that gives the right impression.
> * Novice users often tell me "how fast the new WAV download is".
> On a long file on Windows, it's minutes saved. OD is not just for
> power users.
> I accept that locking may have too many technical difficulties, but I
> think it had to be raised. There are I think fairly cheap (if piecemeal)
> interface solutions as above that cover all reasonable eventualities
> and demonstrate we take user's data seriously, while letting us keep
> OD on by default.
> I also accept turning OD off by default is even cheaper, but I don't
> think it's the best solution, nor is it "complete". OD can get turned
> on in error. I had a case last week of this. The significance of the
> faster, stripey import was not understood, we don't warn on import
> or prevent OS deletion, and user deleted the aliased file as they
> normally do.
>> The former problem where Audacity played silence for missing audio
>> without reporting any problem was also a P2 and in my estimation
>> would have remained a P2 even with copy-data being the default.
> If so, allowing users to edit and export missing audio without warning
> must be P2 also. I think they are worse, if anything.
>> On 02/03/2011 01:14, Vaughan Johnson wrote:
>> > On 3/1/2011 4:40 PM, bugzilla-daemon@... wrote:
>> >> http://bugzilla.audacityteam.org/show_bug.cgi?id=26
>> >> --- Comment #8 from Gale Andrews<gale@...> 2011-03-02 00:40:54 GMT ---
>> >> <snip>
>> >> I'm disappointed comment 6 has received no response. If a lock on aliased files
>> >> is not possible e.g. we have to lock all imported files, please advise. A lock
>> >> would leave only a residual P4 enhancement that if the file becomes unavailable
>> >> in fringe cases such as a drive failure, we warn of that at once.
>> > I think I commented that doing it in a consistent way cross-platform
>> > might be difficult, or impossible. There's no method on wxFile for doing
>> > that, so we'd have to write our own. I think it would have to be
>> > changing the privileges for the file, and I think that's dangerous,
>> > especially behind the user's back.
>> > The other possibility is to keep the file open, and let the OS do the
>> > standard thing -- which on Windows anyway is to disallow deletion. But I
>> > think that means we'd have to open it for writing, which we don't do on
>> > aliased files. In fact I think it would have to be wxFile::write_excl
>> > mode. Not sure that's a good idea.
>> > So, I'm bringing this part of the conversation to -devel for comments
>> > from developers who aren't following the Bugzilla comments thread.
>> > - Vaughan
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> audacity-devel mailing list