When we first save a QTZ file, it attempts to save itself inside the "session directory." This is an error.
This happens even if we have QTZ configured as the default format.
.QTZ files should be saved outside the session directory, as opening them creates this directory alongside them.
If we follow the inertia currently imposed by Qtractor, the result is a QTZ file enclosed in a folder that doesn't belong to it, along with recording files that shouldn't exist (since they are now inside .QTZ).
If you redirect to the project directory, since the name doesn't automatically include the extension, accepting it again will try to save to the wrong directory.
Adding the extension manually is logically fixed, but it is somewhat frustrating, even somewhat comical :) .
Inertia:
Projects/My/My.qtz
Correct:
Projects/My.qtz
Projects/My
At it is now, the My folder in the correct mode does not disappear immediately when you close My.qtz (maybe it should), but the next time you open and close it does disappear correcly.
PS:
Other observations
Actually, when working in QTZ, it shouldn't ask for the session name and folder when recording (which is much more annoying than you imagine) or saving.
They're unnecessary.
When recording without saving, it should generate a .temp directory for recording, and delete it when closing.
Where? Inside the directory specified by the startup template or in $HOME.
Although it doesn't really matter where. In QTZ, that directory is bound to be deleted. In QTZ, the directory is always temporary; it's created and destroyed when opening and closing QTZ sessions.
When close .temp must be deleted. But for this it must ensure that the qtz can never be saved inside the .temp folder. A warning appears when trying to save: "The session cannot be saved to the temporary folder."
Another option is to never delete the .temp file.
Anyway, I don't know what the best solution is....
Greetings
re. Improved .QTZ Saving...
not quite an error per se, but probably wrong or just bad practice :)
you're asked where to save the session file anyway, whether it's a zip/archive (*.qtz) or else, and of course it asks first to save on the current session directory.
that way, it's your call, not qtractor's.
however, there's this dangerous move when you explicitly do, for instance, a "Save As..." into the precise directory that happens to be the current session directory of an open zip/archived session file (.qtz)... yes, that extracted directory will probably vanish as soon as the session is closed later.
again it's your decision to do any of that, although the later could raise a warning message of some sort, something there isn't at the moment but could be in the near future, if you see fit ;)
regards.
It's not worth it
I've decided to work only in .qtz.
Qtr presents some conflicts:
1_
Saving versions becomes dangerous. If I modify a MIDI file in version 5 (or worse still, rename the session), all previous versions are broken, rendering the functionality useless.
2_
The problems with dependency files that can disappear at any given time.
...
Back to the post:
I think I've found a smooth way to solve this.
The default project folder is set by the template. I think this isn't documented, and it was driving me crazy: where does that default "proyect path" value come from?... But I finally figured it out.
The way I solve it: The project path in the templates is,
myPath/Projects/.TEMP
This is how I tell Qtractor that I want all temporary recordings to be saved there.
When it's time to record, the annoying session window appears.
I put anything in the name. For example, "x".
The reason for the annoyance and the "x" as the solution:
1- I'm testing workflows: the project isn't meant to be saved, it doesn't need a name.
2- I'm doing improvisation exercises: the project isn't meant to be saved, it doesn't need a name.
3- I'm inspired. I know I want to do something to be recorded, but I don't know what it is yet. It will be defined as I sketch. It's not the time to name it. That window interrupts inspiration...
A name? What name? You're still brewing, my creation. I'll name you John Doe like your grandfather... Where were we going? Oops, I forgot. Inspiration is lost.
(The question is really annoying at that moment.)
4- I know exactly what I'm going to do, it's a defined project, and it has a name. Okay, no conflict here. But that's 0.1% of cases.
This is why I think that in the case of .qtz, it's not necessary to ask for a directory and name.
Qtractor could create a .temp file on the fly. And as for the name, the user can edit it at any time. The default could be the file name when saving.
That would avoid the question.
However, I understand that Qtractor already has a defined way of working that works for both qtr and qtz.
You can seamlessly switch between formats on the fly.
Changing this doesn't make much sense either.
So I'm sticking with the "myPath/Projects/.TEMP" template trick.
Yea, I've always struggled…
Yea, I've always struggled with the "auto magic" portion of the "save as" work-flow. I don't personally use .qtz but probably agree with the points raised (I briefly skimmed).
Honestly, for as long as I remember, I just settled on using the work-flow as is and then manually "fixing" it. Let's say I have a project that lives in /projects/foo. I'll manually create the /projects/foo/session directory and then 1) move all the .mid files to that session directory then 2) change the session.properties.directory value to that path. The point is, I want my .qtr to live in a "clean" location as opposed to being scattered with among a bunch of other files. Of course, that doesn't really matter (aside from neatness) and doesn't speak to the larger point being made about why it's so disruptive and confusing to simply bootstrap a new project.
I raised the point some time ago which is a bigger deal. The point about that session.properties.directory element requiring an absolute path. That's a big deal because it makes it more difficult to restore a piece of work when restoring on a new system. That system's file system would need to exactly match the system where the data was created in order for things to work. G3N-es, you're not having to deal with that because you're using .qtz files which are (essentially) relative.
All my nits aside, I've always wished saving a work in Qtractor was less user-friendly? Of course, every time I pause to try to think of how I'd like it to work, I realize there are edge cases and I start debating myself. Though, at a minimum, I do think the following would make sense and be more intuitive to work with (when working with .qtr files at least).
oh and yay me, I remembered my forum password :)
re. /projects/foo/session
You don't really have to do it manually.
Parts of the "myPath/projects/" path. It's the one you specify in the tag in the template.
When the session properties window opens, it will appear:
Now add: foo/session/. And you get:
Qtractor will create the "foo" and "session" directories and save the files to "myPath/projects/foo/session/"
When it's time to save, save it to:
"myPath/projects/foo/foo.qtr."
I'm glad you're back.
Relative Session Paths
To create relative session paths, you first need to decide what the reference point will be.
The logical thing would be to use the "projects" folder... but this concept isn't predetermined in Qtractor. And that has its advantages.
For example, thanks to this, I was able to define a .temp directory, which is a different concept than a projects folder, and I was able to get it to work the way I intended.
Others might want to have multiple default project folders... In short, endless possibilities.
There is a variable for "SessionDir" in the configuration file. However, all this does is save the last session directory; it's variable. It doesn't fulfill the function of defining the directory.
In Qtractor, the closest thing to defining this "projects" directory is to assign it within the template.
I think what you're saying would be useful in many cases. It would be something like this:
[X] Projects directory relative to: [MyPath/Projects] [⌄]📂
Then the project path (according to your example):
MyPath/Projects/Foo/Session
It would be
../Foo/Session
The properties window would appear by default:
Directory:
[../ ] [⌄]📂
And you would complete it with "Foo/Session":
[../Foo/Session ] [⌄]📂
PS
Although it is also true that in case of "moving" or back up, creating a bash script that searches in the directories "<directory>MyPath/Projects" and replaces it with "<directory>..//" is easy to do, in fact it can be done even without script with Kate or Geany.
G3N-es, I've read your…
G3N-es, I've read your comments a few times and find myself confused. I have to think we're blurring the lines between 2 different sets of concerns. You seem to be thinking more about the templating side of things (bootstrapping a new project) whereas my comments regarding absolute paths vs. relative are focused on recovering a project.
I say this because a relative thing shouldn't be concerned in the slightest with the concept of a root directory (what you're referring to as a "reference point"). A relative directory is completely sovereign.
About the suggestion to automate the manual editing of the .qtr file, sure... I could easily script it as you said but I do remember discovering Qtractor goes ahead and sets the property back to the absolute path when saving the session.
re. "A relative directory is completely sovereign"
True. You've opened a topic that touches on philosophy.
And I love that. Because philosophy is logic, and it never lies.
Why is a relative path sovereign? Because the reference is "I."
Who is "I" in a computer document? The document. Therefore, dependencies are relative to "I."
However, in Qtractor, this isn't the case. "I" is the folder with the document's dependencies, leaving the document thus stripped of its identity and adrift.
(In my opinion, I think it was a mistake; however, Rui saw it as a solution at the time... and it can no longer be changed due to backwards compatibility.)
I think I've come up with a seemingly simple solution.
Rui, would it be possible for Qtractor, when opening the session, to not change the path to absolute if the user enters a relative directory in the session properties?
1- Start without a "/".
2- Start with a "./".
3- Start with "../".
re. "A relative directory is completely sovereign"...
maybe, let's see...
should we try this way?
byee
Ok
Thanks for answering, Rui.
@windowsrefund If the absolute address is restored every time we open a session, the solution was always to go to the session properties window and specify the relative URL before saving.
It's not the most comfortable, but it works.
It's another reason I switched to QTZ: to prevent files from being relative to the session folder and ensure they are relative to the document.
Based on what you've said, I think for how you want to organize things (if I understand correctly), this would work:
../Foo/Session
for:
MyPath/Projects/Foo/Session
You can take the Projects folder to any computer, or different locations on your own computer, or upload them to GitHub for anyone to download, and everything will still work fine.
Try it.
If I don't understand correctly, the path will be different.
re. relative session directory...
now in qtractor >= 1.5.6.4git.314dd8
take notice: EXPERIMENTAL!
please test this with old and newer saved session files, as much as thoroughly as you can! (remember to backup, backup ad nauseam...)
ps. otoh. I'm afraid I can't understand the whole issue about having an absolute path in session xml
<directory>anyway: if that precise directory doesn't exist at the time the file is open, then the session directory just silently falls back to the exact file's location--or am I day-dreaming?This is HUGE! Will test…
This is HUGE!
Will test today. Thank you.
Just following my instincts…
Just following my instincts to run a test (after refreshing my backups).
Steps:
Expectation(s):
Results:
Odd. After completing step 3 and attempting to save the session, I'm prompted with what looks like a Save As dialog where Look In is populated with the absolute path pointing to the session directory and I'm being asked to save the session file name (in the mentioned session directory.
This is unexpected and confusing? For the time being, I'm going to undo my changes to the .qtr file and just back away slowly :D
The directory element in the…
and it probably is, as expected:
<directory>session</directory>and you say it isn't? assuming your .qtr file was saved to /path/to/session then the new loaded session directory is:
and that is indeed expected.
and it doesn't--at least here--or does it? :)
Hi,My intention is to have…
Hi,
My intention is to have the .qtr file reside in the project directory and the project's artifacts (e.g. mid/wav files) reside in a subdirectory named session.
So when testing, I changed the Directory value to session and expected things to "just get saved" to the .qtr file I had opened. Instead, I was prompted to go ahead and save (a new) .qtr file (to the session directory).
But modifying properties doesn't mean saving
The form doesn't say save, but rather accept.
The command to save is save.
I prefer to keep the final confirmation step with the save command. It gives me more security.
I find it more confusing, as you say :S.
Yea, I didn't mean to…
Yea, I didn't mean to suggest I'd expect the underlying .qtr file to be updated when changing the properties. That would happen when using File/Save. I was just thrown off when I was prompted to save the session (as mentioned above).
:O It seems to work
Now it just works as expected.
My first test was a disaster... until I figured it out.
Attention!!!
Don't edit the path as relative in properties, or it will be a disaster. Just let Qtractor do the magic.
Now it works like this:
Session folders are saved within the "directory" tag in a path relative to the qtr file. No matter where you defined that folder, it will be saved correctly within the file as relative to the .qtr itself. Recordings (samples, midis...) remain relative to the session directory.
Examples:
1
Directory=MyPath/Projects/Project_A/
SessionFile Save in=MyPath/Projects/Project_A/Project_A.qtr
Saved in Project_A.qtr= <directory>.</directory>
2
Directory=MyPath/Projects/Project_A/Wavs_MIDI
SessionFile Save in=MyPath/Projects/Project_A/Project_A.qtr
Saved in Project_A.qtr= <directory>Wavs_MIDI</directory>
3
Directory=MyPath/SamplesAndRecordsOfAllProjects
SessionFile Save in=MyPath/Projects/Project_A/Project_A.qtr
Saved in Project_A.qtr= <directory>../../</directory>
I don't recommend it. It's a known shared dependency model that causes a lot of problems :).
Logic tells me it should work just as well with older projects, but I haven't tested it enough, so I'm sticking with it.
PS
To summarize:
1- Dependencies are still relative to the session folder, since that's where they're stored.
2- Session folders are now relative to the document, which gives the project its identity.
Conclusion:
Finally, portable projects without having to use QTZ :).
The user will simply notice that everything works as expected.
1. If you duplicate a folder to create a new version of the project.
2. If you migrate all your projects and samples to another location (as long as they maintain the same structure relational/relative between them at the destination, of course).
As I read the examples above…
As I read the examples above, I don't think you're actually benefiting from true relative directories. If you were, there'd be no reason to specify any part of the directory structure above (outside) Project_A
Either I'm reading it wrong or your explanation is worded in a way that leads to my confusion.
When you mention Directory in each example, what does that represent? The value in the directory element of the .qtr file?
What I'm shooting for here.... given a .qtr file lives in /A/B/C/foo.qtr, that .qtr file would contain a directory element of D
Then, you'd end up with this:
/A/B/C/foo.qtr
/A/B/C/D/bar.mid
/A/B/C/D/baz.mid
Now, the C directory is the project directory meaning it could be backed up, restored onto another machine, and loading the foo.qtr file would work because it will find every artificat in the D directory.
re. As I read the examples above…
nope.
qtractor won't ever create any directories, whatever that be, when opening a .qtr session file on another machine.
that's the truth, the whole truth and nothing but... yada yada ;)
I wouldn't expect it to…
I wouldn't expect it to. Remember, I was talking about the benefits of restoring a project which means all parts of it have been recovered. In other words, the backup would contain the artififacts directory the session depends on.
re. Directory , what represent? The value in tag inside .qtr?
No, thanks to the change Rui made, the value in the .qtr tag will always represent the path of the directory where you save your recordings relative to .qtr.
You don't have to do anything; Qtractor does it all automatically for you.
"Directory=" in my example represents the value you must specify to Qtractor to set the recording directory. You must specify it as an absolute path, which is the most understandable for the user. However, now it won't save as an absolute path, but as a relative path.
What you want to do is my second example, and it works fine with the update:
1. I specify the absolute path in the session properties window:
Directory=/A/B/C/D/
2. I save the session document:
SessionFile Save in=/A/B/C/foo.qtr
3. What appears inside my .qtr file?
Saved in foo.qtr= <directory>D</directory>
And everything works perfectly.
For example:
1.
Upload to GitHub C (session), and everyone who downloads it will be able to run it.
2.
Upload to GitHub B (sessions), and everyone who downloads it will be able to run all the sessions it contains.
Strange... strange…
Strange... strange... strange.
So I just did this.
cp -R song song2
song2/foo.qtr contains a directory element with value of session
Loading the song2/foo.qtr file succeeds because it is able to find all the artifacts in the song2/foo/session directory.
This is good.
However, the File/Properties dialog still contains an absolute path to the session directory. This is pointless of course. Granted, at this point it's just cosmetic as the correct functionality has already been confirmed. However, my previous post (above) tells me weirdness happens when the user changes that path.
I'll continue looking at this tonight when I'll revisit the idea of changing the path... just to see the behavior. Maybe this is perfectly fine.
Add new comment