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.
Add new comment