I've approached this subject before with mixed results. The conversation was useful in that I learned about the archive functionality. However, we never really got to the root of the problem which is how insanely strange the whole work flow is around how to save projects, how to save a project from a working session spawned from a template, and more importantly, how to relocate a project.
Here's what we know.
Nobody knows they're going to sit down and write a song named "Panda" (or whatever, I just like to use my cat's name at random). Instead, what people (hopefully) do is load up a session from a pre-configured template and start writing music. At some point, if they like what is happening, it becomes a good idea to save it. Of course, it's not reasonable to expect they actually know what the thing is yet.... it's more reasonable to expect they'll treat it like the thing it is; a scratch track or an idea of sorts. Given the odds on that, they want to save it to /data/music/ideas/idea1/idea1.qtr
We all know how weird the above is to accomplish.. It's so strange... it's like you have to navigate to /data/music/ideas and then specify a "Project" directory (I think?) and then... I don't even know as I can't exactly remember. All I know is that there's some kind of forced logic applied that makes very little sense from a end user perspective. Of course, I completely believe this portion of the work flow was created to try and make things easier on the end user. It just doesn't feel that way at all and instead has a very "Microsoftish" kind of feel to it. I just want to know specifically where I'm saving my .qtr file. The only way for me to clearly know is to allow me to specify that exactly and remove all the abstraction. Of course, there's also this need to save what I'll call the "session data". This is where I'm assuming the need to hide all the specificity comes into play but why is that so necessary? Just allow me, as the end user to specify *exactly* where to store it? I don't want black magic to decide. I don't want to "have to know how this particular software thinks and behaves" when it comes to something as basic as knowing where my data is stored.
So let's say you made it through that and now you've got your little idea stored in a proper location on disk. At some point, it's reasonable to believe that idea is going to grow into an actual song. It's not going to be referred to as "idea1" forever. At that point you're going to want to relocate the data to a more appropriate location on your disk. Please, let's just all admit... this is a nightmare. I could certainly take the time to sit here and document all the tedious steps involved, making use of .qtz functionality, verifying, etc... but we should all know at this point how much of a challenge this process is. In fact, I'd even suggest maybe we do not know simply because there really is no documented or built in process at all. Don't get me wrong, I've fought the battle time and time again, enough to be able to accomplish the task at hand. However, I have to take the stance that nobody should have to work this hard (archiving, unarchiving, editing files by hand, verifying, etc) just to manage files.
So seriously, can we just admit this area of Qtractor has been overlooked for far too long? This is such a good DAW for so many reasons. It's a shame basic project management is so neglected.
Me too
Funny you mention this. I've been using Qtractor for some time now, but only recently have I been going through a bunch of song ideas and branching them out into new folder song names. AND... funny enough... I'm running into some serious issues similar to what you mention. In fact, this happened to me a few minutes ago. MIDI files go missing, whether they are from the original project name... OR, as I create new MIDI clips, they have disappeared upon reload. I'm guessing that the project is still trying to put it under the old folder which no longer exists. I don't know if I'd call it a nightmare, but it is something that should be addressed as part of the workflow
re. Can we please talk about how crazy ...
I admit it might be confusing and adding to that some session renaming was buggy but, as you also know, it's been addressed recently on your request :)
there are probably two issues here, that also add to confusion:
a. changing the session directory;
b. changing the session name;
while a. affects only new files that are to be recorded and/or created thereafter, b. changes all existing files in their names--it was the later that has been marked buggy and leading to empty clips, especially if the clip has been copied around the timeline (linked). this is what has been fixed.
anyway, the best and highly recommended method to backup and relocate sessions (or projects if you prefer) across the file-system or even machines, is the archive/zip bundle method (*.qtz). do please do not try to move any files and/or directories around: that's really crazy and you should know that, if you've been doing that, you're doing it on your own risk.
one other thing that probably relates to some reported problems with said sessions used as "templates": qtractor has a special file suffix or extention to denote session templates: .qtt; you're advised to not use regular session files (*.qtr) as "templates", especially because they will retain the session name and directory, that you, most probably, will change it to whatever; always try to save as a "real" template file (*.qtt).
hth.
cheers
ps. as always, not dismissing on anyhthing, surely there's lot of thing on this regard (and others) may well be improved, but currently, it's all what there is :)
So looking at the SGML file (
So looking at the SGML file (.qtr) itself, I don't understand why <directory>/some/absolute/path/here</directory> is a thing at all. What's the point of this? One would think it might represent the path where session data is stored. However, we can see that each of the entries under <midi-list> is specified using a relative path to the path mentioned above. This, IMHO, is where things become more difficult to manage then perhaps they should be? If <directory> really represents the session location, why not just specify the absolute path there so each midi/audio file didn't have it's relative location managed as well? I'm not saying this move alone would solve all the issues with work flow brought up in this thread but it seems like it would be a good start?
At some point, I think it would also make tons of sense to refactor whatever is happening with the File/Properies/Session dialog that can be changed when working inside a project. I can't understand what the point of the Name field is and it seems like changing the path to another directory would be an ideal location to drive some kind of copy operation behind the scenes? Like, if I change the path and click OK, wouldn't it make sense to copy (or move if we're willing to get really crazy... LOL) to that directory while also changing the path in the .qtr file's <directory> entry?
re. So looking at the SGML file...
as said, the session directory is where all new files are created or recorded; if you change the session directory, the previous files in the old directory, will remain there.
having it to move and copy files around old and new session directories, is just another can of worms waiting to be opened. :)
one and last thing, the ssion directory name has nothing to do with session names; although you can set it like so, if you wish; session directories may well be shared by two or even more session/project files (*.qtr).
one good thing about session archive/zip bundle files (.qtz) are that they are tied to specific and unique session directory when extracted/open.
that's one of the reasons you should that for relocating and/or renaming a project.
br.
Hmmm... So, as long as the
Hmmm... So, as long as the directory path is pointing to the right working folder, all the assets should be identified? As long as the individual wav and midi files don't have their own paths, and all the assets are in that folder, it seems that making sure this directory path is correct should fix everything.
re. So, as long as the directory path ...
changing the session directory will make all files to be relative to it, when the session is saved to a regular session file (.qtr).
as said, any files that were in the previous old session directory, will stay there and their paths will be saved as relative to the new session directory.
please, don't assume that all session assets are (or will be) all located in the designated session directory, they can be anywhere.
exception is, again, for archive/zip-bundle session files (.qtz): ALL assets will be in the very SAME directory, which is in fact recreated on session open/extraction.
hth.
cheers
Add new comment