Forums
I've been doing some tests and I've been surprised.
If the session is from scratch, without templates: the sends between buses are done!!! However, they show the following peculiarities.
1) The Master Default bus only supports sending, not receiving.
2) The incoming signal goes directly to the track, it skips the fader and the volumeter. The output signal skips the fader, the volumeter works.
Similar problems were experienced during the development of the new AuxSend. Maybe there was a solution here too.
I leave it only as a testimony. Attached is the .qtz of testing.
File attachments
re. Zero Copy...
man, how many times do I have to say it again?
it stands the (dang old) advice for not connecting directly any own outputs (output buses and insert sends) to own inputs (input buses and insert returns).
what you may be experiencing here is the so called "new AuxSend development" will reorder the internal route processing of the output buses, entirely independent of their visual listing order, remember?
so, bear with me, while some direct loop insert sends/returns might have once worked before, on some tracks and/or buses, they also might stop or even start working again, once you mess with that said internal processing order ad-hoc.
so please, again, don't overlook the advice :)
Ok :)
It was just a curiosity. Maybe sharing it doesn't help much...
But when in doubt, I preferred to share it.
Greetings :)
Mostly, this is a…
Mostly, this is a communications problem. Remember, we're dealing with somewhat abstract concepts which are made harder to understand as folks use different words and terms to convey ideas and related components. It's a shortcoming of the communication method (forum) mostly; someone writes something that is true but a few months later it just ends up fading into the abyss....
Seems like a single source of truth would be a better way to document and showcase these ideas. It can't be that wiki thing...... it's too hard to interact with and is just too "read-only". It should be a git repo that showcases known-working setups which produce repeatable outcomes. That approach would make a ton of sense since all the "guts" of Qtractor's data are non-binary (.qtr and .mid files). A hosted git repo (a.k.a. github) has all the collaborative tools baked in already so people could easily do all the things (issues, PRs, etc).
The only thing I see that might block that vision is the "absolute path" behavior of the
<directory>element in the.qtrspec. If that would be changed to be relative, I could see people being able to profit like so...You get the idea. Maybe I'll throw together an example repo showing how I handle signal routing of a multi-output drum plugin (using AVL drumkits)
re. template repository and workflow examples
I think this is an interesting proposal. You could do it yourself.
It could be a complementary but independent project to Qtractor.
I don't understand the problem with the "directory" property.
In fact, .qtr files, inside .qtz files, do not include this property.
It is enough to save as qtz, open the file in Qtractor (which will unzip the file) and upload the folder to git.
If you don't want the qtz to be uploaded, add the qtz format to ignore.
The problem I keep seeing is with those plugins that in turn have dependencies (audio samples, sf2, sfz, text files, images...).
Not with the plugins themselves, since inside git you could create the .lv2 and .clap folders with all the plugins from all the projects.
Of course, with lv2 not all plugins are autonomous, some must be installed (calf and carla are the most essential).
But that can be fixed too. If someone doesn't have them installed they should, so you can add in the root Readme of GIT that installing them is an essential requirement.
In summary, the problem is still with the plugins that in turn have dependencies.
Example:
Imagine you want to make a Drumkv1 example with several drum sets for Qtractor with examples of midi tracks already assembled for each set.
No matter how you do it, it simply won't work.
Drumkv1 won't find the samples, and worse still, it won't even tell you the name of the samples that were loaded.
You will have to leave instructions for the person to rebuild the project track by track.
This would be solved if the plugins allowed project-relative paths for their samples.
Fortunately fluidsynth-DSSI does allow editing the path within the project and in presets.
Assembling custom samples in sf2 with Polyphone and using fluidsynth-dssi is going to be my solution for these cases.
In Qtractor plugins it should not include the dependency paths in the compressed part. But I don't know if that can be fixed now due to backwards compatibility issues.
The problem is that .qtz is…
The problem is that .qtz is a binary file and therefore, not conducive to this style of version control. It's fine for static artifacts like images, etc but not for things you'd want to see diffs of as time goes on. The problem with the
<directory>element (I've said this like 3 times already) containing an absolute path is that you'd have to reconstruct your file system in the event of a recovery in order for the .mid files (and other artifacts) to be found.As for the plugins, the
README.mdfor a given "project" would just provide clear instructions on how to satisfy the requirements of the project (install foo and bar, etc).Now I understand you
Yes, it is better as you say. The solution is very easy. Edit the qtr file and leave the directory label like this
<directory></directory>, or delete the label directly before uploading it.The paths will be relative to the .qtr file, and not to the folder. Everything will work fine.
When someone downloads it and makes changes, when saving, the path in
<directory>it will be created absolute to their own computer.Everything will work fine. You just have to be careful to delete that label before uploading the project.
Actually, I've done that…
Actually, I've done that regularly in order to move a project's .mid files to a subdirectory named
session. Then Imvall my .mid files to that directory... all is good. Come to find out, Qtractor, when saving the session, rewrites that relative path to the absolute equivalent. Try it and you'll see...True
It would be useful if the user could decide if he wants the paths relative to a file or a directory.
It would just have to add in general options:
Session relative to [directory/file].
If it is relative to a file, you should just leave the session path blank.
I don't know if Rui is going to be willing to do this. Actually, I also find file-relative paths more useful.
Meanwhile... in the qtractorSession.cpp file.
On line 64 change:
sessionDir = QDir().absolutePath();
to:
sessionDir = "";
I haven't tried it. But I'm going to. Then I'll tell you if it works.
sessionDir = ""
It seems to work. I'll leave it like this until I need to compile again to see if it causes conflicts.
re. sessionDir or <directory> ...
hi, I really appreciate your input, however...
to be absolutely honest, the
<directory>tag in the xml session files it's kinda something of a legacy from times of yore, say two decades already?fact is, one has to cope with all scenarios: bad old and good new ones.
back then, again decades ago, qtractor had no sense of property or a session folder or directory of its own, where ALL material would reside down under it; no, no and no, and to be (partially:)) honest again, it still doesn't, at all.
the golden rule has been one that still remains, is that the session directory was, and still is, the place where all NEW created material, say recorded, is placed or stored first hand. It doesn't matter if it is not close to be relative, to whatever other external or linked material you might import into session.
so, to have my hands washed clean, so to speak, I frankly don't know the short or long term consequences to setting the
sessionDIr = "";so please, be extremely careful and test thoroughly that resolution, on all and every scenario... it is not simply enough to say seems to work.
hope you understand
thanks
I know there may be conflicts
I know that what I do is a test bench. That's how I put it.
We are trying to find solutions to portability.
It is something fundamental. If it does not exist in the world of proprietary music software, it is precisely because of the proprietary philosophy.
In free software, being able to port and share should be a priority.
Curiously, this occurs in the proprietary framework with music software. Not so with graphic arts software. And the fact is that music has always been strongly linked to copyright and commercial interests. Graphic creation is much more generic and practical than music (signage, documentation, training...) and subjecting software to such strict privatization would have been dysfunctional.
From the beginning, it has been possible to encapsulate graphic arts projects. They even had to invent a partially editable and universal encapsulable format, PDF. Because if not... you can't work. It's unviable. Projects should be able to be shared without losing their integrity.
I don't know if I'll be able to solve anything. For now I'm learning a lot. In fact, I'm now starting to realize many virtues of LV2 (I just published a reflection in the thread I created about portability related to this), such as being able to create presets that behave almost like plugins with their own identity.
But learning and realizing things is a slow road...
Not sure what you mean by …
Not sure what you mean by "relative to a file". The location of
sessionDirmust be a directory since that's the directory used to persist artifacts like .mid files, etc. Personally, I'd just like to have the ability to set it to something likesession/(the final slash isn't needed, I'm just adding it here for clarity). In other words, I've always been in favor of a project looking like...That way, I could just scp or rsync
/path/to/projectanywhere for backup purposes. Restoring would be a breeze because I'd be able to copy it back to/path/somewhereelse/projectand just run Qtractor against the .qtr file. That's what I've always tried to have happen.I don't know if I understand you
Let's see if this is it.
What I think you mean is:
./MySession
What I indicate is:
./
----
"./MySession" doesn't work. If you want that, the way to write it is as I indicate:
./ or directly not put anything "", which is the same thing.
What does "./" mean or leaving the session folder blank?
It means that the project folder will be the container for MySession.qtr. It doesn't matter what it is called. That's why I call it relative to file, that is, to MySession.qtr.
It is precisely this, making the session relative to the file MySession.qtr, which allows you to make your backup scripts by indicating the name of the MySession folder and its absolute path.
/path/to/project/MySession/baz.mid
That would be the absolute path seen from the backup script.
But that path seen from Qtractor (MySession.qtr) must be a relative path to the MySession.qtr file "" (i.e. empty).
Try it and you will see that everything works. (It is different if it could cause conflicts, which we do not know. Although I do not think so, since QTZ works like that.)
By the way
By the way, the folder name is also automatable in the script.
Because the real session will always be the .qtr file.
You can make the script in the following way.
Search for .qtr files recursively.
When you find one, tell me the name of its containing folder.
That will be the info for the "projectdir" variable.
You're confusing me :)…
You're confusing me :)
Please read my post again where I explain why I'd want a "clean" project directory (the location of the .qtr file) and a relative subdirectory used to hold all related artifacts (session data). I don't know how to explain any more clearly and I've already tried like 5 or 6 times now. :D
Add new comment