On Saturday 14 May 2005 05:52 am, Chris Cannam wrote: I've been thinking, and, I want to take a step back for a moment. My thinking up to this point has centered on trying to find a way to make the existing mechanisms easier to manage. When I use this, I wind up with a mess, and I'm looking for tools to make it easier to manage the mess after the fact. Ultimately, however, I am coming to think that the key here is to avoid the situation that results in a mess in the first place.
As a user, I forget about the relationship between audio segments and files on disk. I don't think to look in the file manager. I forget it's there. The whole thing is just not natural or intuitive to me. I see the file manager as something I should use to add extra files to the project from external sources, but I don't really think of it as a place where the stuff I've done within Rosegarden itself should show up. (I realize that it does, mind you, but even realizing this I tend to forget day to day. I have to keep reminding myself.) What I feel should be the ideal state of affairs is for all segments to behave the same way. If I record a MIDI segment, I don't like it, I hit undo, and it's gone. I can redo to get it back. If I delete a MIDI segment, then it's gone. I can undo to get it back. I understand that if I undo to three commands back, then do something unrelated, I have now cut myself off from being able to redo actions that are no longer on the stack. All of this is perfectly intuitive and understandable, and that's the way everything works. If I back arrow my web browser to three URLs ago, then click a different link, I've cut myself off from forward arrowing back to where I was a few moments ago. Same thing in a word processor, image editor, or any other modern application I can think of. So I think audio segments that are associated with audio files that Rosegarden itself created should be treated just the same way as MIDI. Audio data is not inherently any more or any less precious to me than MIDI. It should not stick around forever in case I might want some last ditch way to undo a grievous screw-up. If I were to perform a similarly grievous screw-up with MIDI data, it would be gone forever. Undo/redo are there so you can take a step back from a goof, but it only works if you catch it in time. That's life, and that's the way everything else works. Why should audio be different? So let's start the discussion from that question. Why should audio be different? What is wrong with the following scenarios? What am I not thinking of? a) I record an audio segment. A file X gets created on disk. I don't like the recording. I hit undo. The file gets flagged for deletion. I hit redo, the segment comes back, and the file is no longer flagged for deletion. b) I record another audio segment. A file Y gets created on disk. I hit undo twice. Now both files X and Y are flagged for deletion. I hit redo, get back file X. File Y is still flagged for deletion. Now I record a third audio segment. File Y is overwritten with the new recording. Its original contents are permanently gone. I don't have time to sit here and think the rest of this out right now. It gets complicated when you copy segments or cut them up. I think there is more to sort out, but I think the overall idea is workable, and could be implemented. At the end of the session, anything that is still flagged for deletion would be erased, just like any undone/deleted MIDI segments on the stack would be erased from RAM at that point. I'd love to bounce this line of thought back and forth and see if we can come up with something agreeable. The other ideas I've had for putting a bandaid on the whole situation are less preferable in my mind than simply making audio behave in the same fashion everything else does in the first place. Solve the problem at its root. If these files were little .mid files full of MIDI data instead, the whole situation as it stands today would be pretty questionable, I think. Thoughts? Good idea, bad idea, I'm completely full of shit? > Incidentally, the project packager has a similar capability already -- > if a file is listed in the audio file list but unused in any segment, [...] > not in the project directory yet. It still has bugs (especially in > unpackage), some work & help needed. It's worth thinking about as a bandaid, but I don't see the packager as a primary solution for the fundamental problem. Not unless we utterly fail to come up with any better ideas. It 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. -- 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
