Improving project portability

Just chiming in to point out there would be a cost in terms of duplication (multiplied times N). I tend to think "good housekeeping" lends itself better (or at least as good) and will, for the sake of making my point, just describe the portion of my workflow which is geared to address this area of portability.

1. One bus per instrument named using a short mnemonic string formatted as N. Examples would be NM1, NM2, NM3 (Tal NoiseMaker synth instances), ODIN1, ODIN2, ODIN3 (Odin2 synth instances), SF21, SF22, SF23 (sft2 soundfont instances)... you get the idea. The point is, I know what synths I personally like and tend to work with so I'm always going to know what each of these descriptive labels means.

2. Track names are used to reference both the bus reference (which we've just established serves as a instrument reference) as well as the name of the patch used. I always place the bus reference alone on line 1 in order to end up with a clean mixer and the patch description goes on line 2.

Basically, those 2 ongoing practices essentially "self document" things in a way that allows me to reverse engineer what's needed should I need to revive a project on a system (maybe a new install) where this or that plugin isn't installed. Of course, that's just going to get me up and running for tracks using a default patch.

If a track ends up using a patch that's been customized, that second line is changed to Custom and I take care to go back into the instrument itself and export the patch. The custom patch is exported to a file name like NM1.whatever_extension_is_appropriate and saved to the same directory as the project itself. Now, I've persisted the custom patch and tied it to the project itself...

In the case of Soundfonts, we typically store these in a "central" location for good reason (they're potentially quite large). This is where I would not duplicate the thing and store it alongside my project because I should be backing up my soundfonts (and other central artifacts like 3rd party plugin-specific patches, etc) anyway. Again, the ongoing work used in the project layout steps described above serve to "point the way" in the scenario where we need to recreate. Of course, that's just focused on the layout/recovery side of things. When we need to share our things for collaborative purposes, I've broken that discipline and will export (if needed) and/or duplicate a patch or soundfont as needed but that's all part of a more rare scenario as we tend to collaborate less but should always be thinking about recovery.

I also tend to keep my .mid files in their own session directory because I don't like a cluttered project directory. I do this by editing the .qtr file itself and modifying the <directory> node. A quick mkdir session and moving all .mid files to that location and I'm good to go. Of course, I don't do this right away but soon after a given project feels "legit" and something I know I'll continue to work on. By maintaining a clean project directory, I can maintain a README.txt with any instructions (maybe when I'm collaborating), any custom patches, etc... In other words, those things would be quite difficult to spot if I were to leave dozens or even hundreds of .mid files sitting around. Also, I always create a export directory and use it to write files which are exported after a mix-down. Again, keeping a clean root directory yields big wins. Also, I always run the awesome cleanup function contained in the Files right-click menu after a mix-down/export so things are kept nice and clean.

Here's just a few quick screenshots showing these easy wins in action.

In general, I'd be cautious about asking for these type of work-flow assumptions to be baked in despite the awesome and well intended inspiration. I'd actually say it's the lack of those work-flow assumptions being baked in that provides me with the ability to do what I need to do in order to address these concerns.

and just to throw a monkey wrench in, it might be super cool if Qtractor used a git repo as a data store?

...I'm running away

hi,

most of what @G3N-es asks is already in place if and only if:

• the plugins in use are in the LV2 type;
• you save the session to archive/zip file type (*.qtz).

all other plugin types, store external file paths in their own blob format, so it's almost impossible to track them down anyway--only the plugin itself understands what it's in its own black box--now multiply this for each plugin type you're using... luckyly, some plugins will embed the whole crap of a file contents in the said blob, hugely bloating and impacting the session file size, save and load times... problem solved in these particular cases only, but with a cost.

hth.
cheers

Yea, I don't see the upside to managing plugins in this fashion. Imagine the following scenario...

Over the course of the past year, you've cobbled together a dozen songs; each leveraging a particular plugin. Using this model, each of those now contain a copy of the plugin.

Now you want to update the plugin in order to benefit from a bug fix or new feature... whatever. You have to now hunt down and do the needful across each of these projects. It just doesn't scale at all; especially when we expand this thought exercise to a dozen or more plugins. You'd be better off automating your "centrally installed" plugins via something like Ansible, a shell script, or whatever.

bundling always seems fun but it ends up just sucking

Hold your horses!

I now strongly believe you're going into a goose chase...

Write this down, will you?

1. plugin binaries are not portable between machines or (file-)system images, period.

2. LV2 plugin URIs must at all times be unique and identify one binary instance and only; the host LV2 inventory makes sure this is the case on all times; working around that (like adding several search paths where one and many might be found, at any given time, will lead to the proverbial undefined behavior, that being only one instance will ever get called and it is uncertain which will be, probably the wrong one (in this regard, it all deeply depends on the libLILV implementation in charge).

so, I would recommend to follow not on this idea--is out of (our/qtractor) control--and put simply, it is not just an uphill battle, rather a predictable lost one.

hth.
cheers

GN3-es,

I don't think you need to avoid sf2/sfz at all because of the fact they're so standard. In other words, it's so easy to find a freely licensed thing to play them (Calf Fluidsynth comes to mind but there are obviously several others). As for the actual sounds, this is what I was talking about earlier when I was saying you'd just organize all of these somewhere on your box and simply include that path in your backups. I know backing up this type of data (sound libraries of any kind) can be costly in terms of size but that cost will only get paid the first time. Subsequent backups are going to be incremental assuming you're using something like an rsync or whatever.

The trick is to ALWAYS know exactly where a given plugin is drawing its "patch" from. If you look closely at ODIN2's export functionality, you'll notice it exports your modified patch to its own preferred location. I always drop into a shell and cp or mv that exported patch to the root of my particular project so I have what's needed to rebuild/recreate in the worst case scenario. That level of discipline and workflow best practice yields benefits time and time again across several other plugins I won't bother to list.

All in all, this has been an interesting thread and I do think some good ideas have been brought up. I still wonder if Qtractor's <directory> element can be changed to use a relative path rather than absolute. Granted, backwards compatibility can't be sacrificed... I totally get that.

Well, sure.. for something so generic, I totally get that and appreciate the thought you're putting into the creation of the work. I had assumed you were talking about a more personal work/creation where you'd be making a needless sacrifice.