In a way it’s already doable manually, it’s just taking a hell of a time. 
I guess most people here already knows how that kind of manual workflow goes, but here’s a reminder (or information provided for the benefit of new users):
- Launch Renoise. This will be Renoise instance R1.
- Launch another instance of Renoise. This will be Renoise instance R2. (I usually have the different Renoise windows use different skins/themes to set them apart visually.)
- Start building a nested group track structure in R1.
- Load a previously saved .xrns song into R2.
- Start cut’n’pasting from R2 into R1. That means manually selecting and copy-pasting Samples, Virtual Instruments and Effects, DSP chains, pattern data, etc.
- Repeat from step 4.
The way I see it, everything is actually already in place. What needs to be done is only to take away all the manual effort involved in the above steps, so that we can just build a library of re-usable contents and automatically load such content from disc into an existing Renoise project without any significant manual effort.
In fact, we already have similar features for e.g. the DSP chains where we can load/save such chains across various projects. So it would be a logical step to introduce similar functionality in regard to Groups, i.e. load/save group track contents and linked stuff such as samples/instruments/effects. And such group track content could very well be probably 99% of the data of a Renoise song (.xrns file) with all its samples, instruments, effects, dsp’s, pattern data, etc.
Maybe with optional import features such as loading only samples, instruments and dsps from another .xrns file but leaving the pattern data unloaded (i.e. the user needs to open a second instance of Renoise and manually copy-pasting just the pattern data). Or a clip pool of pattern data sequences to select from. You get the idea.
Actually I’ve been suggesting similar ideas in the past. See for example this thread: http://forum.renoise…oises-renoises/
Although at that time I didn’t yet know about the upcoming Group tracks, and the level of powerful nesting that the Renoise developers had enabled. Now when we also have 64-bit and no longer the RAM limitations from the past, it feels very natural to take this step in development. This is also pretty much the only area where I personally feel Renoise is at a huge time loss. It takes me hours to merge together some 20 shorter Renoise songs into one package deal song. That’s a really annoying and painful contrast, because Renoise is extremely fast for virtually everything else.
Whatever the devs are cooking up for the next Renoise version, I trust that taktik, dBlue & co are well aware of all the potential inherent in the 6 level nesting of group tracks. I’d like to believe that kind of design wasn’t just some random choice, but rather that they’re on to something bigger here in terms of a workflow design that, among other things, will address the issue of having hundreds of “born-saved-and-forgotten” 4-pattern .xrns files… 