You are here

How to rename and move a project?

I've got a project named foo saved to ~/projects/foo/foo.qtr

I want to rename it. I open the project, use 'save as' to save it to ~/projects/bar/bar.qtr. Now when I look at the actual .qtr file, there's a bunch of references to .mid files which:

1. Are named with a prefix that uses the old name.
2. Point to the actual .mid files in ../foo rather than in the current directory.

In other words, my "save as" did create a new .qtr file but I'm still 100% dependent on the directory containing the data I want to move away from (in name and location at least)

I feel like Qtractor is just not doing the right thing here. When I save a project, the software should save everything about that project in a place that I specify. If that location changes, all dependencies (the .mid files) should be recreated in the targeted directory. If qtractor is content with simply pointing to files in another area of the system, that old directory may be deleted by the user and then the project would be unusable.

A new user to Qtractor would never suspect a .qtr file could contain references to other files that it would need.

Forums: 
rncbc's picture

Yes, regular session files (*.qtr) only store file references so that if you save it to another filename (Save As...) ALL file references will still point to the very same file locations, although in relative paths to the session directory, whatever it is at the moment you execute the save operation.

Note that the said "session directory" is about the place where new media files (audio or MIDI) will be created and stored on recording at a given moment--it doesn't mean at all that any files used by that session are in the same place or directory--again, only new created and/or recorded material will be stored there.
Yes it's true, you can set the session directory to any, even the same, directory or folder, all the time, for all sessions. You may find it ludicrous but it's how qtractor works since its conception, and pardon me, it won't change any day soon if ever. Sorry.

However, there's one particular exception to this scenario, one you ought to try and use whenever you wish to move away and/or rename the session directory in a self-contained format: the session archive/zip bundle (*.qtz): just rename the session file suffix (extension) from ".qtr" to ".qtz" in the File > Save As... dialog and you'll see what it gives ;)

hth.
cheers

cheers

Woah. The "self containing" format is exactly what I want and now realize I should have been using all along. This is a killer feature. Basically, it takes the place of the directory I've been storing my .qtr files in on a case by case basis. I can see how moving to .qtz will also let me version things if I want (not that I ever really do). This is great! Thank you :)

Is it just me or is it not possible to merge clips when working in a session opened from a .qtz file?

Thanks in advance

rncbc's picture

yes it's perfectly possible to merge clips on a session opened from a .qtz file.
when loaded the so called ".qtz" session is like any other, so there's no reason on having any different behavior.

there's something going on in there and I quite frankly don't know what it is...
as always, more (lots of) information is due ;)
seeya

FYI, there's a serious bug somewhere in this .qtz feature as I just experienced data loss. I don't have time to test and document in detail now as I need to recover but there's something serious happening here.

I'm basically now left with a file that when opened, left me with no choice but to accept some missing files. This results in some clips showing up blank where they used to contain data. It is these empty clips which are now preventing me from exporting the entire project as MIDI (qtractor seg faults).

I'm extremely fortunate that I'll be able to recover since the lost data represents work I did last night. I'll need to delete the "empty" clips and forge ahead. That said, there is definitely something extremely dangerous happening here with regard to this .qtz functionality. The feature is clearly renaming and/or deleting files somewhere in the process and should be refactored if I'm right.

Best,

rncbc's picture

Can you relate whether is anything you might find special on those disappearing clips? specially regarding their original filenames and file type and format?
what kind of steps did you go through before and until you notice the missing data?

I hope you still have the original regular session file (.qtr) and all the files and clips from there are still OK. If that's the case, try to reproduce the said "bug" by saving to and loading from another or new archive/zip bundle file (.qtz).

please?

Appreciate the feeback and sorry if I went into a bit of a rant as I found myself scrambling to recover. Next week, I'll try to reproduce this along with complementing documentation.
All the best,

rncbc's picture

it is me who's most interested in sorting this out
i'm totally aware that software as complex as this is no piece of cake or walk in the garden, quite the contrary!
i just hope to strike the hammer on a nail that's still nowhere to be found :)
cheers & thanks

rncbc's picture

any findings?

eagerly awaiting still :)
cheers

Thanks for the follow-up. At this point, my goal is to simply test the behavior of working with the .qtz format. I'll start by creating a new project in .qtr and then saving it to .qtz for the purpose of making the project portable. I'll document the steps as I go and see where I land...

Create a new project named test1.qtr with the following:
- 3 tracks, each with 4 bars filled with 16th nodes. Each track's notes are sitting on a unique MIDI note number.
- No outputs have been configured as we're only testing how data is saved based on the format used (.qtr or .qtz)

Now, with the .qtr open, I'll save it in the compressed format as test1.qtz

Performing a unzip -l against the .qtz, I can see what I expect in terms of the .qts, and the subdirectory holding the related .mid files

Next, I close everything, move the .qtz to another path and attempt to open it.

This works as expected. This tells me I must have done something dumb and/or reckless when I brought up this issue last week? I'm certain I must have been in a state where the .qts contained references to .mid files that were "outside" the directory of the .qtz itself but I can't seem to piece together the exact steps to recreate the scenario. My takeaway here is that I probably needed to be more careful as I was exploring this awesome feature. I'm totally good with that :)

Add new comment