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.
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.