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 .qtr spec. If that would be changed to be relative, I could see people being able to profit like so...
git clone https://github..com/whatever/qtractor-workflows.git
cd qtractor-workflows
qtractor zero-copy/project.qtr
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)
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)