From: Al T. <big...@sb...> - 2009-11-28 17:08:47
|
Is there an option, or a hack, that will name audio files to something perhaps related to the track name (i.e. - rhy guitar 1), rather than names like rg-20091125-132837-92.wav? It would sure make life easier for when you have to work with the files, such as exporting to another program, or mixing sections, etc. -- Check out the website I've been cobbling together. It will never be done, but it's a start: http://lateralforce.no-ip.org My blog, with commentary on a variety of things, including audio, mixing, equipment, etc, is at: http://audioandmore.wordpress.com Staat heißt das kälteste aller kalten Ungeheuer. Kalt lügt es auch; und diese Lüge kriecht aus seinem Munde: 'Ich, der Staat, bin das Volk.' - [Friedrich Nietzsche] |
From: D. M. M. <mic...@ro...> - 2009-11-29 02:04:07
|
On Saturday 28 November 2009, Al Thompson wrote: > Is there an option, or a hack, that will name audio files to something > perhaps related to the track name (i.e. - rhy guitar 1), rather than > names like rg-20091125-132837-92.wav? There is now. I started to explain why there was nothing reasonable we could do here, and my explanation sounded a lot like another explanation I made just recently. We don't show you the track associated with a particular instrument in any of the mixers, because multiple tracks can refer to the same instrument. To address that complaint in the only reasonable way I could think of, I invented a new instrument alias feature. There's a very nondescript button in the instrument parameters box and on the audio mixer that lets you create an alias for the instrument if you want. Instead of something like "Audio #2" you can change it to something like "SM-57 back right corner" to make it easier to keep track of what is coming in from what source. This alias gets added to the filename on disk now (as of trunk/ revision 11342) and I've made some other tweaks to the naming which I hope will make it more clear that the random looking numbers are actually a date and time. The old filenames were something like: rg-20051112-231138-6.wav That actually means 2005-11-12 at 23:11:36 recording 6, but that isn't at all clear, and it just looks like a random number to me except for the 2005 bit. The new filenames look like this if there was no instrument alias: rg_-2009-11-28_20.04.28-2.wav And if you had an alias, it passes through: rg_SM57 back right corner-2009-11-28_20.06.29-3.wav I knocked this together on the spur of the moment and didn't put a lot of deep contemplation into the most ideal way to represent any of this. Let me know what you think, and if this strikes you as not quite right, let's refine the concept. Maybe I should remove the - when there's no alias, yielding: rg_2009-11-28_20.04.28-2.wav Maybe I should stick an h in after the hours to make it more clear the last three groups of two digits are time-related, like: rg_2009-11-28_20h04.28-2.wav (That wouldn't necessarily make immediate sense to my American eyes, but time notation like 20h30 is pretty common worldwide. 20:04:28 would look better to me, but colons don't seem to be safe to use in filenames without going to lengths to escape them.) I need some kind of sanity checking on this too. You could put anything in the alias string, and it could surely create brokenness in this raw state. > It would sure make life easier for when you have to work with the files, such as exporting to another program, or mixing sections, etc. Another thing you can do, especially important to use retroactively, you can use the audio file manager to save the files it references to a different location with a name of your choosing. That's what I've done traditionally when I wanted to go fish out particular recordings I had done with Rosegarden. It's probably still going to be a useful technique after this change too. There really is only so much we can do with this, because the code at the level where this is happening has no knowledge at all of concepts like tracks and segments from which to get more meaningful and specific labels. I guess adding a "rename in place" kind of function to the audio file manager could be workable too, but to be honest that code is already fragile and crash prone, and I'm not keen on poking it with a stick. -- D. Michael McIntyre |
From: D. M. M. <mic...@ro...> - 2009-11-29 04:20:42
|
On Saturday 28 November 2009, D. Michael McIntyre wrote: > The new filenames look like this if there was no instrument alias: > > rg_-2009-11-28_20.04.28-2.wav rg-[none]-2009-11-28_22.48.07-2.wav (I figure "Audio #2" vs. "Audio #6" doesn't tell you anything interesting anyway, so I only use the string if you've set an alias with the little "Click to rename this instrument" button. A button which has no label. Hrm.) > And if you had an alias, it passes through: > > rg_SM57 back right corner-2009-11-28_20.06.29-3.wav rg-[SM-57_in_lower_back_corner]-2009-11-28_22.49.59-4.wav It turns illegal characters and characters best avoided into _. You can also use it as a hack file namer by changing the instrument alias for the track right before you record. You can change it a dozen times in a session and it's no problem. I think it's a sound idea overall, but I need to think of a way to offer better user interface exposure without breaking the string freeze. The translators are going to kill me if I keep breaking the string freeze! :) I guess what that means, Al, is this is about as good as it will get for the coming release, but at least *you* know it's there, and I'll try to get better exposure when I can. At the least, I can mention it as I update the manual, but a nugget like this is just hard to expose in a way that guarantees discovery. I guess I could make the little nondescript edit button into a full-blown "Edit" button, but even then it would need a big tooltip to explain why it's useful, and it would do inconvenient things to this layout, which is already too tricky as it is. Hrm. Well, anyway... -- D. Michael McIntyre |
From: Emanuel R. <xb...@we...> - 2009-11-29 07:38:29
|
2009/11/29 D. Michael McIntyre <mic...@ro...>: > > rg-[SM-57_in_lower_back_corner]-2009-11-28_22.49.59-4.wav > That is helpful. Maybe, appending the alias as here: rg-2009-11-28_22.49.59-4-[SM-57_in_lower_back_corner].wav would be preferable, since it allowed to easily sort by time in a filebrowser. -- E.R. |
From: Al T. <big...@sb...> - 2009-11-29 14:10:49
|
Emanuel Rumpf wrote: > 2009/11/29 D. Michael McIntyre <mic...@ro...>: > >> rg-[SM-57_in_lower_back_corner]-2009-11-28_22.49.59-4.wav >> > That is helpful. > Maybe, appending the alias as here: > > rg-2009-11-28_22.49.59-4-[SM-57_in_lower_back_corner].wav > > would be preferable, since it allowed to easily sort > by time in a filebrowser. > Except, some windows, such as the audio file manager, only show the first several characters of the filename, and you'd be back to wondering which "rg-2009-11-28_22" was the one you were looking for. You could always use "ls -t". -- Check out the website I've been cobbling together. It will never be done, but it's a start: http://lateralforce.no-ip.org My blog, with commentary on a variety of things, including audio, mixing, equipment, etc, is at: http://audioandmore.wordpress.com Staat heißt das kälteste aller kalten Ungeheuer. Kalt lügt es auch; und diese Lüge kriecht aus seinem Munde: 'Ich, der Staat, bin das Volk.' - [Friedrich Nietzsche] |
From: Chris C. <ca...@al...> - 2009-11-29 11:21:29
|
On Sun, Nov 29, 2009 at 1:36 AM, D. Michael McIntyre <mic...@ro...> wrote: > 20:04:28 would look better to me, but colons don't seem to be safe to use in filenames Just a side note, colons are not legal at all in filenames on Windows and, while we have no special interest in Windows at the moment, it's probably unwise to use Windows-incompatible filenames without good reason. The filename arrangement you ended up with looks fine to me. (If you want to sort by date, can't you just get the browser to sort by the file's last modification date?) Chris |
From: Al T. <big...@sb...> - 2009-11-29 04:44:05
|
D. Michael McIntyre wrote: > On Saturday 28 November 2009, Al Thompson wrote: > > >> Is there an option, or a hack, that will name audio files to something >> perhaps related to the track name (i.e. - rhy guitar 1), rather than >> names like rg-20091125-132837-92.wav? >> > > There is now. Thanks!! That will help a LOT. Can't wait to give it a try. -- Check out the website I've been cobbling together. It will never be done, but it's a start: http://lateralforce.no-ip.org My blog, with commentary on a variety of things, including audio, mixing, equipment, etc, is at: http://audioandmore.wordpress.com Staat heißt das kälteste aller kalten Ungeheuer. Kalt lügt es auch; und diese Lüge kriecht aus seinem Munde: 'Ich, der Staat, bin das Volk.' - [Friedrich Nietzsche] |
From: D. M. M. <mic...@ro...> - 2009-11-29 07:23:35
|
On Saturday 28 November 2009, Al Thompson wrote: > Thanks!! That will help a LOT. Can't wait to give it a try. OK, Al, you opened Pandora's box. Good thing you did, because this is something I kind of had in the back of my mind, and had decided we couldn't get it done for the release due to the string freeze. The translators will just have to shoot me. (I'm a translator too, and dreading the thing I just wrote, which is going to be a bitch, but it needed to be done.) I added two more pieces to this today. First, I took the last idea one step further by putting the document title into the audio filename, as well as the instrument name. Then, in order to maximize the benefit of that, I fixed it so that if your document is still called "Untitled" when you start to record audio, you get a dialog box explaining the new file naming conventions and informing you that you have to save your document as something before you can continue. Then you get a Save File dialog. (A ~/rosegarden full of rg-[Untitled]-blah just doesn't gain you any benefit.) That's bordering on obnoxious, and I've actually REMOVED most of the in your face blah blah blah dialogs we used to have (and put them on the new warning widget in the lower right corner of the screen, to read at your convenience) but I've got 4 GB of almost totally random, meaningless crap in my ~/rosegarden directory after seven years here, and I'm proof that users left to their own devices will hit record first and think about housekeeping afterwards. The dialog links to a wiki page I haven't written yet, where I'm going to explain all this new stuff, and tips and tricks for getting the most out of it. That's how I'll get exposure for things that really are just difficult to make easy to grasp at a glance. -- D. Michael McIntyre |
From: D. M. M. <mic...@ro...> - 2009-11-29 08:11:33
|
On Sunday 29 November 2009, Emanuel Rumpf wrote: > That is helpful. > Maybe, appending the alias as here: > > rg-2009-11-28_22.49.59-4-[SM-57_in_lower_back_corner].wav > > would be preferable, since it allowed to easily sort > by time in a filebrowser. I've been looking at and debating that myself. Which is more helpful? Sorting by time from 2005 to present (as in my case, because that was the last time our audio filenames changed naming conventions) or sorting by the title of the original composition associated with the file? Right now, the tail end of my ~/rosegarden looks like this: rg-20090827-001316-6.wav rg-20090918-115632-1.wav RG-AUDIO-0080.wav RG-AUDIO-0081.wav rg-[Testing]-[flute]-2009-11-29_00.47.24-2.wav rg-[Testing]-[not_specified]-2009-11-29_02.00.58-2.wav The top two are from 2009, the middle two from before 2005, and the bottom two are new. That in of itself is kind of helpful, sorting wise. At least the newest ones are at the bottom of the list. That's guaranteed by the punctuation, so what comes after could be anything, and it doesn't matter much. Would it be better to put the date next, and sort by title-date-time-number- instrument, or leave it as it is, and sort by title-instrument-date-time- number? Or sort by date-time-number-title-instrument? My own feeling is that I'm probably going to look for a title and an instrument before I look for a date. Who can remember dates a few months after the fact anyway? I'm open to discussion to be sure, but let's decide this matter promptly for the sake of the translators, so I don't have to jerk them around playing ping pong with the string that describes the file naming convention. (Or maybe I should just pull that out to the wiki page, but I'd kind of prefer to leave it in the dialog, because it stands a greater chance of being read.) -- D. Michael McIntyre |
From: Emanuel R. <xb...@we...> - 2009-11-29 10:05:46
|
2009/11/29 D. Michael McIntyre <mic...@ro...>: > > Would it be better to put the date next, and sort by title-date-time-number- > instrument, or leave it as it is, and sort by title-instrument-date-time- > number? Or sort by date-time-number-title-instrument? > > My own feeling is that I'm probably going to look for a title and an > instrument before I look for a date. Who can remember dates a few months > after the fact anyway? > I think, it is simple to search for "flute", no matter if it is at the end or beginning of the filename, but sorting for date-time, is not easy without having a supporting filename. So my suggestion is rg---2009-11-29---00-47-24-2---[ flute - My nice Alias ].wav (make the alias eye catching :) I think you could use the instruments name as default-alias, with the user option to change/adjust it. Any more opinions ? I leave it to you to decide. -- E.R. |
From: Julie S <msj...@ya...> - 2009-11-29 11:05:28
|
Hello All, Concerning audio file names: I'm pretty content with Michael's current setup. rg-[title]-[alias]-date.wav I have to admit the ER's version: > rg---2009-11-29---00-47-24-2---[ flute - My nice Alias > ].wav handles the name alias nicely, it add spaces to the file name that I think Michael was trying to avoid. I'm also personally a fan of the '-' as opposed to the '_' and Michaels mixes them in ways my eyes find irritating such as: rg-[Testing]-[not_specified]-2009-11-29_02.00.58-2.wav but I see several reasons why this is better than naming them all '-' symbols that I prefer...so leave it. My eyes will adjust. But I think compactness wins every time in this situation. ER's date method though more easily decoded takes up many more characters. Remember that many times long names get truncated depending on how they are displayed and which program displayed it. I take it the rg- prefix is there for sorting and legacy reasons as well. So leave it I guess there is some value to having it at the head and it doesn't take up to many characters. I think the most compact and useful name is as Michael wrote it. I thought of: rg-[My_title-Violin_II]-2009-11-29_02.00.58-2.wav This only saves two characters and may be possibly harder to regrex than Michaels which uses the rarely used by humans '[' and ']' in the file name. ... So, I just vote to keep it the way Michael has it. Sincerely, Julie S. |
From: Henry W. P. <hwp...@ja...> - 2009-11-29 14:18:23
|
I have been (not very successfully) trying to store my various musics by date... that is to say, in a folder (with the name of program used to so produce) with the date of the month & year... so it gives me some historical record... of my work flow. Some things I simply date, with perhaps an instrument, or suggestion of instrumentation, orchestration, etc., some have a definite title... This then, is sometimes a clue to its' possible importance, either to do more work on (or come back to), or a certain (amount of) finality (no pun intended). Personally speaking (yikes, is there any other way?), if there were a generic work title, I would prefer it to go *first* by date... because, if I decide to title... this usually (but not always) comes later, for me. It would not be the end of the world, were it otherwise. One vote, I know. Thanks for discussion. Regards, Henry Julie S wrote: > Hello All, > > Concerning audio file names: > > I'm pretty content with Michael's current setup. > > rg-[title]-[alias]-date.wav > > I have to admit the ER's version: > >> rg---2009-11-29---00-47-24-2---[ flute - My nice Alias >> ].wav >> > > handles the name alias nicely, it add spaces to the file name that I think Michael was trying to avoid. > > I'm also personally a fan of the '-' as opposed to the '_' and Michaels mixes them in ways my eyes find irritating such as: > > rg-[Testing]-[not_specified]-2009-11-29_02.00.58-2.wav > > but I see several reasons why this is better than naming them all '-' symbols that I prefer...so leave it. My eyes will adjust. > > But I think compactness wins every time in this situation. ER's date method though more easily decoded takes up many more characters. Remember that many times long names get truncated depending on how they are displayed and which program displayed it. > > I take it the rg- prefix is there for sorting and legacy reasons as well. So leave it I guess there is some value to having it at the head and it doesn't take up to many characters. > > I think the most compact and useful name is as Michael wrote it. I thought of: > > rg-[My_title-Violin_II]-2009-11-29_02.00.58-2.wav > > This only saves two characters and may be possibly harder to regrex than Michaels which uses the rarely used by humans '[' and ']' in the file name. > > ... > > So, I just vote to keep it the way Michael has it. > > Sincerely, > Julie S. > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Rosegarden-user mailing list > Ros...@li... - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-user > > |
From: Julie S <msj...@ya...> - 2009-11-29 15:00:12
|
Hello Henry, You wrote: > Personally speaking (yikes, is there any other way?), if > there were a > generic work title, I would prefer it to go *first* by > date... because, > if I decide to title... this usually (but not always) comes > later, for > me. It would not be the end of the world, were it > otherwise. Well, if you have been using RG to do recording they historically, you have been receiving things like this: RG-AUDIO-0080.wav RG-AUDIO-0081.wav ...which has no date and no alias to reference the audio. So first off, the current solution is a vast improvement, and second any of the competing variations we have mentioned are big improvements as well. So, let's stick to what is at hand. I appreciate wanting to order things by date. That is fine. You can name your RG file with a date to do that. How have you been accomplishing the date ordered file keeping using RG in the past? I'm not shooting you down, I'm just trying to get at how you were doing this before in RG and how this change will affect your workflow. So if there is a issue that we are unaware of that this changes in some meaningful way that you believe outweighs the old (see above) versus the new ([title]-[alias]-date.wav), then please let us know. The warning dialog the Michael put in--though annoying--is probably justified--but still annoying. It does not force you to change the the title, just suggests that you should. BTW---Michael-- Is the title the file name for the composition of the title that shows when you view the properties of the composition? I was a bit confused by the use of title vs. composition file name. Sincerely, Julie S. |
From: Henry W. P. <hwp...@ja...> - 2009-11-29 16:32:28
|
Hi Julie, & All, Well, I might make a folder called "RG.Nov.09" (if RG will make a default save folder, I would set it at that), I would try to make a new folder for every month I did activities in that program, & kept in a folder called (say) "Music.09" , then I usually call a file; "pn.11.29.09." The "pn" is cause I would be working from my keyboard. & by the way, I some times work on different compositions with in one project window, if I am just doing a midi project. If I am doing an audio production (as to differentiate between midi, & or midi/audio, & so far, I have done no audio in Rosegarden), I usually am more intentional about this... in terms of nomenclature, so the project is more the prime focus (i.e., not necessarily A single title, & then versions might become more important (next)... But this is rough generalization... version can become very important too (& possibly, other factors). Point is, anticipating & thinking like a musician is essential to the constructive potential of a computer tool for making music/s. Who the heck else is it for, anyway (sincere question here)?? A tall order... but my focus is on music possibilities. Which is why we need to learn more, widen our scope of appreciation/s of differing music/sound productions... not to compromise a production tool to death, but to maximize keeping the tool in the background... of these possible possibilities. Plus, folks will come along (hopefully) & dream up & realize things not yet fully present, then maybe use Rosegarden in heretofore unexpected ways... would that be wrong? (I think I digress) Thanks for your comments... & considerate consideration/s. Henry Julie S wrote: > Hello Henry, > > You wrote: > >> Personally speaking (yikes, is there any other way?), if >> there were a >> generic work title, I would prefer it to go *first* by >> date... because, >> if I decide to title... this usually (but not always) comes >> later, for >> me. It would not be the end of the world, were it >> otherwise. >> > > Well, if you have been using RG to do recording they historically, you have been receiving things like this: > RG-AUDIO-0080.wav > RG-AUDIO-0081.wav > > ...which has no date and no alias to reference the audio. > > So first off, the current solution is a vast improvement, and second any of the competing variations we have mentioned are big improvements as well. > > So, let's stick to what is at hand. I appreciate wanting to order things by date. That is fine. You can name your RG file with a date to do that. > > How have you been accomplishing the date ordered file keeping using RG in the past? > > I'm not shooting you down, I'm just trying to get at how you were doing this before in RG and how this change will affect your workflow. > > So if there is a issue that we are unaware of that this changes in some meaningful way that you believe outweighs the old (see above) versus the new ([title]-[alias]-date.wav), then please let us know. > > The warning dialog the Michael put in--though annoying--is probably justified--but still annoying. It does not force you to change the the title, just suggests that you should. > > BTW---Michael-- Is the title the file name for the composition of the title that shows when you view the properties of the composition? > > I was a bit confused by the use of title vs. composition file name. > > Sincerely, > Julie S. > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Rosegarden-user mailing list > Ros...@li... - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-user > > |
From: Julie S <msj...@ya...> - 2009-11-29 18:24:00
|
Dear Henry, Considering your last message and our previous dialog. I don't see any reason why the new naming convention will get in your way. Your compositions--the .rg file--- can be whatever you like it to be. So just name it that and you are set. Michael will have to explain where the actual audio files are stored. I don't recall at the moment the current state of this--Michael has done much in Thorn to make all of this more sane. He would know. So do as you like create your monthly folder. Then a daily folder if you like, then save your .rg file with whatever file name you like. The files we are talking about are Audio segments that are recorded during an RG session. These are related but distinct from the actual .rg file. The .rg file just points to the files on the hard drive and does not actually have them embedded in them...though we have options for doing just that as well. I hope this helps. Sincerely, Julie S. |
From: D. M. M. <mic...@ro...> - 2009-11-29 19:32:22
|
On Sunday 29 November 2009, Julie S wrote: > Michael will have to explain where the actual audio files are stored. I > don't recall at the moment the current state of this--Michael has done > much in Thorn to make all of this more sane. He would know. Well, that's an interesting line of thought. Now that we're strongly encouraging you to save your file as something before you record, we could create a new audio path automatically, and not save everything to ~/rosegarden by default. I hadn't planned to take this that far, to be honest. I think having the contents of ~/rosegarden be readily identifiable is probably enough of an improvement that it isn't necessary to take it any further than that. I could talk about all of this at great length. Trying to enforce audio path discipline is not as simple as it looks on the surface. I'm trying to come up with a workable compromise, juggling the factors of legacy compatibility, user inconvenience, and code complexity that could lead to stupid bugs manifesting at the worst time. -- D. Michael McIntyre |
From: Julie S <msj...@ya...> - 2009-11-29 20:00:26
|
Dear Michael, Thanks for answering that. ~/rosegarden it is. No, I'm not advocating a change. Keep what we have and move on. I hate it when an application forces me before I even start to pick a project directory and a project name. Though I agree this is probably for my own benefit and helps the app know what to do. I've had some pretty horrible experiences with having to think of all of this stuff as a newbie for many software packages---not just audio. Then kicking myself after I got proficient for having chosen such a dumb method the first time I opened the application. An old AutoDesk copy of Civil Survey that I used comes to mind. Trying to move a project from one directory structure to another was a nightmare, and the software forced you to decide upon first opening how to set things up. Then you were stuck with it for every project. So the chances of doing it right when someone first opens RG is about zero. Besides if people want them al together they can roll it up with that thing you and ilan have worked so hard on...the packager. People can just open up all of their existing projects, roll them up as package files, do what they want to the ~/rosegarden audio files, then unroll the packages after the dust settles. Yeah, its some work, but that way they can have everything in one place and then clean out ~/rosegarden's audio files. We definitely could put them in a project folder along with the .rg file if we knew ahead of time where the files was going to be saved, but we don't. And the solution we have works and it works better now than it did before. I vote you keep it like it is and move on. It's too late in my book for Thorn to decide to force project / file name creation. We can hash this out another time. I can think of several different, yet elegant ways to do this. But I certainly don't think now is the time to hammer this out. You did a fine job of juggling all the parts and adding to what we have with minimal disturbance them. Sincerely, Julie S. |
From: Henry W. P. <hwp...@ja...> - 2009-11-29 23:15:25
|
Apologies, did not quite get an accurate drift of the discussion earlier. Most digital audio recording/editing programs I have used, as I recall, basically put the audio files with numbers for id's (even if saved with a title) in a folder called "Audio." & how the hell do you tell one "Audio" folder from another? :) Even if the directory could have some kind of preliminary, or generic title... might be helpful... & I think this is more or less the heart of the question (?), feel free to correct if this is not correct. I do agree with Micheal, naming to start out with might be the best discipline... (but not always an opportune situation), but especially resuming a previous project in some way, & cleaning house or moving files (Julie), can indeed make this apparent lack of association, an unholy mess! & just for my better understanding, does not such unsaved recording get sent to a temporary location? & if so, as I think it has been the case with other programs, I have always felt this to be some important incentive to save... as electricity is needed, but not always available, etc... I think, how ever the specifics of *this problem* get resolved (i.e., the order of "untitled," date, etc.), keeping associated files together is paramount (for any sustainable sanity, at any rate) to my way of looking at it. Regards, Henry Julie S wrote: > Dear Michael, > > Thanks for answering that. > > ~/rosegarden it is. > > No, I'm not advocating a change. > > Keep what we have and move on. > > I hate it when an application forces me before I even start to pick a project directory and a project name. > > Though I agree this is probably for my own benefit and helps the app know what to do. > > I've had some pretty horrible experiences with having to think of all of this stuff as a newbie for many software packages---not just audio. Then kicking myself after I got proficient for having chosen such a dumb method the first time I opened the application. > > An old AutoDesk copy of Civil Survey that I used comes to mind. Trying to move a project from one directory structure to another was a nightmare, and the software forced you to decide upon first opening how to set things up. Then you were stuck with it for every project. > > So the chances of doing it right when someone first opens RG is about zero. > > Besides if people want them al together they can roll it up with that thing you and ilan have worked so hard on...the packager. People can just open up all of their existing projects, roll them up as package files, do what they want to the ~/rosegarden audio files, then unroll the packages after the dust settles. > > Yeah, its some work, but that way they can have everything in one place and then clean out ~/rosegarden's audio files. > > We definitely could put them in a project folder along with the .rg file if we knew ahead of time where the files was going to be saved, but we don't. And the solution we have works and it works better now than it did before. > > I vote you keep it like it is and move on. It's too late in my book for Thorn to decide to force project / file name creation. > > We can hash this out another time. I can think of several different, yet elegant ways to do this. But I certainly don't think now is the time to hammer this out. > > You did a fine job of juggling all the parts and adding to what we have with minimal disturbance them. > > Sincerely, > Julie S. > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Rosegarden-user mailing list > Ros...@li... - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-user > > |
From: Henry W. P. <hwp...@ja...> - 2009-11-30 20:50:20
|
Not sure how I did it, but I got the RG v.1.7.3 installed in Ubuntu 9.04 (?), now, trying my hand at Debian Lenny... reinstalling RG (perhaps there were all the dependencies there because of previous versions of RG?) & here's what I get from doing a 'cmake' (not sure, but maybe missing some kde dependencies? In any case, advice as to why the cmake stops here would be appeciated) : > :~/Documents/Soundz/rosegarden-1.7.3$ cmake > cmake version 2.6-patch 4 > Usage > > cmake [options] <path-to-source> > cmake [options] <path-to-existing-build> > > Options > -C <initial-cache> = Pre-load a script to populate the cache. > -D <var>:<type>=<value> = Create a cmake cache entry. > -U <globbing_expr> = Remove matching entries from CMake cache. > -G <generator-name> = Specify a makefile generator. > -Wno-dev = Suppress developer warnings. > -Wdev = Enable developer warnings. > -E = CMake command mode. > -i = Run in wizard mode. > -L[A][H] = List non-advanced cached variables. > -N = View mode only. > -P <file> = Process script mode. > --graphviz=[file] = Generate graphviz of dependencies. > --system-information [file] = Dump information about this system. > --debug-trycompile = Do not delete the try compile > directories.. > --debug-output = Put cmake in a debug mode. > --trace = Put cmake in trace mode. > --help-command cmd [file] = Print help for a single command and exit. > --help-command-list [file] = List available listfile commands and exit. > --help-commands [file] = Print help for all commands and exit. > --help-compatcommands [file]= Print help for compatibility commands. > --help-module module [file] = Print help for a single module and exit. > --help-module-list [file] = List available modules and exit. > --help-modules [file] = Print help for all modules and exit. > --help-custom-modules [file]= Print help for all custom modules and > exit. > --help-policy cmp [file] = Print help for a single policy and exit. > --help-policies [file] = Print help for all policies and exit. > --help-property prop [file] = Print help for a single property and exit. > --help-property-list [file] = List available properties and exit. > --help-properties [file] = Print help for all properties and exit. > --help-variable var [file] = Print help for a single variable and exit. > --help-variable-list [file] = List documented variables and exit. > --help-variables [file] = Print help for all variables and exit. > --copyright [file] = Print the CMake copyright and exit. > --help = Print usage information and exit. > --help-full [file] = Print full help and exit. > --help-html [file] = Print full help in HTML format. > --help-man [file] = Print full help as a UNIX man page and > exit. > --version [file] = Show program name/version banner and exit. > > Generators > > The following generators are available on this platform: > Unix Makefiles = Generates standard UNIX makefiles. > CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. > Eclipse CDT4 - Unix Makefiles > = Generates Eclipse CDT 4.0 project files. > KDevelop3 = Generates KDevelop 3 project files. > KDevelop3 - Unix Makefiles = Generates KDevelop 3 project files. > ? Henry |
From: Julie S <msj...@ya...> - 2009-11-30 21:15:27
|
Dear Henry, You wrote: > missing some kde dependencies? In any case, advice as to > why the cmake > stops here would be appeciated) : > > > :~/Documents/Soundz/rosegarden-1.7.3$ cmake > > cmake version 2.6-patch 4 > > Usage from this snippet you just typed "cmake" try "cmake ." a friendlier version is "ccmake" Good luck. Sincerely, Julie S. PS -- since you are compiling from source, might be easier to pull the Thorn-Alpha or trunk and try that. It compiles much easier than 1.7.3 |
From: Henry W. P. <hwp...@ja...> - 2009-11-30 21:46:33
|
Hi Again Julie, Glad to give alpha a try... hopefully the debug option works ok (for me), & it apparently builds with "./configure." I am not sure of two things as referenced in the below snippet from the accompanying read-me... 1.) What is the proper (correct) "[PREFIX]," I would assume it is a path name such as "/usr/local" (?)? 2.) How do I find the path name for my "[QTDIR]"? It appears there is a configure script, but if not, there are directions below, & it seems clear what to do. Thanks again for the help. Henry If the directory where you found this README file does not already contain a configure script, you must generate one by running: sh ./bootstrap.sh Once you have a configure script, ensure that all of your build dependencies have been installed, and then run: ./configure [ --prefix=[PREFIX] QTDIR=[QTDIR] [--enable-debug] ] make make install New starting with 09.10, most of the application data files are bundled in the rosegarden binary. The install process will copy rosegarden rosegarden-lilypondview rosegarden-audiofile-importer rosegarden-project-package to [PREFIX]/bin and will copy a limited number of data files to [PREFIX]/share/rosegarden You may need to specify [QTDIR] on the configure line, so that the build can find the Qt4 libraries. The optional [--enable-debug] will build Rosegarden so that it is useful for debugging, which can greatly improve our ability to find and correct bugs by allowing Rosegarden to produce useful stack traces when it crashes. WARNING! Enabling this option results in an approximately 300 MB rosegarden binary! Julie S wrote: > Dear Henry, > > You wrote: > >> missing some kde dependencies? In any case, advice as to >> why the cmake >> stops here would be appeciated) : >> >> >>> :~/Documents/Soundz/rosegarden-1.7.3$ cmake >>> cmake version 2.6-patch 4 >>> Usage >>> > > from this snippet you just typed "cmake" > > try "cmake ." > > a friendlier version is "ccmake" > > Good luck. > > Sincerely, > Julie S. > > PS -- since you are compiling from source, might be easier to pull the Thorn-Alpha or trunk and try that. It compiles much easier than 1.7.3 > > > > |
From: Al T. <big...@sb...> - 2009-11-30 03:53:30
|
D. Michael McIntyre wrote: > I could talk about all of this at great length. Trying to enforce audio path > discipline is not as simple as it looks on the surface. I'm trying to come up > with a workable compromise, juggling the factors of legacy compatibility, user > inconvenience, and code complexity that could lead to stupid bugs manifesting > at the worst time. > Just FYI - Sonar forces you to name a project before doing anything with it. On top of that, there is an option in 'Preferences" called something like "use per-project folders," which, if selected, causes Sonar to create a folder (directory in real terms) with the name you give the project. Under THAT folder is one called "Audio," where all audio files associated with that project are stored. I'm not saying that is the best way to do it, but it does work well, and keeps all of your audio files from being jumbled together in one directory. This may have the added benefit of speeding seek times in audio directories, since the number of files would be limited to only those for each project, and not include everything you've ever done in RG. (grin) As an aside - have you been following the CCRMA mail list? It seems that there is an alternate version of jack (jack2) which may be replacing the current jack (jack1) in future releases of Fedora. -- Check out the website I've been cobbling together. It will never be done, but it's a start: http://lateralforce.no-ip.org My blog, with commentary on a variety of things, including audio, mixing, equipment, etc, is at: http://audioandmore.wordpress.com Staat heißt das kälteste aller kalten Ungeheuer. Kalt lügt es auch; und diese Lüge kriecht aus seinem Munde: 'Ich, der Staat, bin das Volk.' - [Friedrich Nietzsche] |
From: Chris C. <ca...@al...> - 2009-11-30 09:44:25
|
On Mon, Nov 30, 2009 at 3:53 AM, Al Thompson <big...@sb...> wrote: > As an aside - have you been following the CCRMA mail list? It seems > that there is an alternate version of jack (jack2) which may be > replacing the current jack (jack1) in future releases of Fedora. I don't read the CCRMA list, but jack2 is what used to be known as jackdmp and I have used that in the past with generally good results. (In fact jackdmp was used by default in v2 of our Studio to Go distro a few years ago.) It's directly compatible with jack1 and I'd imagine most users would see no particular difference, except for details like not causing audio dropouts when a new client is added or removed, and more efficient processing in some multi-core scenarios. Chris |
From: D. M. M. <mic...@ro...> - 2009-11-29 23:54:50
|
On Sunday 29 November 2009, Julie S wrote: > BTW---Michael-- Is the title the file name for the composition of the title > that shows when you view the properties of the composition? > > I was a bit confused by the use of title vs. composition file name. It isn't, actually, although for some reason I was thinking it was. The name "title" came from the code. It's getTitle() or something to that effect, not getFileName() or similar. Hrm. A look, a think, a beard scratch. About the only thing to do is change "name" and "title" in that dialog to "filename" and leave it at that. I've had five votes from various corners for just leaving well enough alone on the naming conventions as last committed, so I'm going with that. (It's actually a very large response to something like this, and this is a question that needs to get settled promptly and decisively, without hand wringing.) BTW, I used the _ between date and time to show a separation between them, since the date elements were offset by -, and because even though they're perfectly legal and all our code is supposed to cope with them, I really hate spaces in Unix filenames. I like having the []-[] in two separate brackets because both fields are of variable width, and it makes it easier on my eyes to parse a list of these things for the field I'm looking for. -- D. Michael McIntyre |