On Sunday 15 May 2005 05:46 am, you wrote: > Well, my gut feeling is that it's not a good idea to disregard the fact > that audio really _is_ different, because it involves separate and > potentially very large files on disc. Also, they're more often (than > MIDI segments) the results of a specific take made in real-time that > might not be so easily repeatable.
I'm not sure I agree. Losing a 10 minute MIDI improv is no less tragic than losing a really nice jam session. You can argue questions of scale, of one performance lost vs. several being lost simultaneously, but both ideas still come down to the same idea of losing something ephemeral forever. I wouldn't lose the MIDI improv because I wouldn't delete it. Why would I lose the audio? > This means, for example, that we > don't want to risk doing anything that will simply remove a file if > there's the slightest chance we may be mistaken. Similarly, we want > the user to have enough personal control to feel like they can make > decisions about which files to keep and which to remove, from the > perspective of e.g. avoiding running out of disc space. I would feel I had all the control in the world in the scenario I started to outline. Don't delete it, and it isn't deleted. If we assume users can be trusted to make their own decisions as to what should and should not be deleted, where's the problem WRT their personal control? The only problem I can see is if we get it wrong and delete things that they didn't intend to delete. There is room to err down that road, but it could be sorted out so that they are no more and no less likely to cause a mishap with audio than any other kind of data. > I would feel more comfortable about having the sequencer manage audio > files silently in this way if there was a stronger connection between > the audio files and the composition file -- for example, if the I agree. It's probably an inescapable aspect of getting this whole scenerio to go. It has to be some piece of territory that RG controls exclusively. The composition "owns" the files somehow, perhaps in a hidden directory that RG creates, and if you want to get them out to something else, you'd have to export them out of RG's domain using some internal mechanism for that purpose. If you tried to circumvent this and do it by hand, we couldn't be held responsible for the consequences. Maybe one mechanism to export a particular file or files on demand from the file manager, and another useful tool for the purpose could of course be the project packager itself. It's already necessary (well, very convenient anyway) to use it if you want to share your composition with someone else, so this need to "export" or "publish" the project via the packager to get all the secret files into one place does not strike me as such a horror. > OK, problem 1: you can't keep deleting and re-recording takes because > you'll run out of disc space because the files aren't actually being > deleted. You need the manual control to be able to say you definitely > want to get rid of something. > > You can say "well, when you record something new it can safely reuse > file X because you've undone the original recording and when you do > something new you lose the capability of invoking a redo". But that's > relying on a particular usage of yours -- i.e. you evidently seem > inclined to hit Undo to discard a new recording, whereas someone else > (e.g. me) would naturally select it and hit Delete. Thus, Rosegarden > would not be able to reuse the deleted segment in case the delete was > later undone. That's a very good point, and a big hole in my thinking. RG couldn't record over file Y immediately because of the need to be able to undo the deletion, and so the space would add up. At the end of the session, however, that need goes away. The space could be recovered by closing and re-opening the document, which would flush out the undo stack, and go purge anything left over that was still flagged for deletion. It's a permanent act from which there is no going back, but so is the equivalent act in MIDI terms. Using the current mechanisms, if I ran out of disk space, I'd have to go figure out what the files actually are and go delete them by hand, which sucks. I might quit RG, go package the file, unpack it somewhere sans cruft, and re-start RG. Being able to just cycle RG and flush the cruft without all the intervening steps strikes me as much more convenient. More convenient than the "unload and delete unused" idea that I started this line of thought with too. Maybe even a "You're running out of space, do you want to flush the cruft?" with suitable screaming disclaimers about destroying any data associated with deleted audio segments permanently. These problems could all be solved, I think. It's a workable idea, if a complicated one. Is it worth it? Is it better? I think so, clearly, but it would be good to hear other opinions. Perhaps I'm the only user who detests the current audio file management scheme so thoroughly. I haven't heard anyone else complain about it. I love this idea, but I also see what a royal PITA it would be to get it all working and sort out the many ways it could do bad things. > > [The project packager] does need testing though, and it is a very > > useful thing. I intend to have a good play with it, and send you that > > small test project I promised umpty weeks ago. > > You'll notice it's now integrated into the Rosegarden tree (File -> > Export -> Export Rosegarden Project file...). > > The main bug at the moment that I'm aware of is that it screws up when > you ask it to unpack to a .rg file with a different basename from that > of the .rgp file. Not overwhelmingly hard to fix, just needs a few > spare minutes here and there... I'll have a play as soon as I figure out how to get CVS to build and install again. -- Michael McIntyre ---- Silvan <[EMAIL PROTECTED]> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
