Loading Multiple Songs Into Nested Group Tracks

Ideas & suggestions
1

Now when we have group tracks that can be nested in six levels, would it be possible to add a feature (either natively or by scripting) that loaded multiple .xrns files? (Or selected portions of .xrns files)

If so, wouldn’t it be extremely useful if all those short Renoise songs and experiments that just collect dust on our harddrives, could easily be loaded and used together into a single instance?

Consider something like this:

  1. You’re in the middle of newsong.xrns and suddenly remembers that you created something nice in coolbeat23.xrns.
  2. You create a new group channel and load the coolbeat23.xrns into that group channel
  3. You create a group channel called “Beats” and load coolbeat23.xrns, anothercoolbeat44.xrns, and percussion_mania.xrns into three subgroups.
  4. You decide to replace coolbeat23.xrns with coolbeat12.xrns instead
  5. etc

Of course, coolbeat23.xrns shouldn’t contain more than a maximum of 5 levels of nesting in its own group tracks, due to the limitation of Renoise’s 6 levels of nested tracks. That is, newsong.xrns would need to reserve the first “parent group track” for the loading of single .xrns files. However, ideally Renoise should be able to load non-nested, “flat songs” (such as all songs were prior to 2.8), into any level of the group track tree (as in the above example workflow scenario).

The concept of loading/saving group tracks as .xrns would definitely add whole new level of creativity to the overall Renoise experience. It’s probably quite common for Renoise users to have hundreds of 1-4 pattern “songs” lying around on the drive, most of them forgotten about. But many of those “songs” would actually be quite useful if only we could quickly load/unload them into the current project, complete with DSP chains, samples, instrument settings and all. Then just use the pattern matrix blocks or copy-paste to move stuff around and arrange/mix multiple .xrns contents according to taste.

Also now when Renoise 64-bit can use huge amounts of RAM, this concept seems even more appealing.

Just some food for thought… What other possibilities do you see here?

2

The idea looks nice, but what about different pattern lengths, BPMs, Pattern FX controlling playback, song settings etc.? Plus the restrictions on the depth of nested groups? Hm…

I’d much rather have multiple songs open in one instance of renoise, visible simultaniously. Maybe initially in song tabs, but detachable. Plus a playlist tool, while I’m at it. ;)

Edit:
Ok, if I want to copy and paste stuff easily from one song to another, there seem to be the very same problems as with your suggestion, so ok, +1 for you too. ;)

3

No, parameters such as different pattern lengths, BPM’s, song settings and pattern FX controlling playback wouldn’t necessarily cause any problems here. ;)

It would be up to the user to build a library of re-usable contents by editing/saving .xrns files that contained re-usable contents. So when for example file drumkit03.xrns gets loaded into a Drums group track in newsong.xrns, everything global in drumkit03.xrns would need to be discarded if it wasn’t possible to adapt such data into drumkit03.xrns’s own group track (acting as the new master bus for that imported song, but not as the overall Master bus for newsong.xrns).

But the most important contents in multiple .xrns files could always be loaded: their samples, virtual instruments and effects, DSP-chains, pattern data of notes/velocity/panning/effect columns, etc. Granted, if an external .xrns file could be loaded into a group track, it would probably have to be communicated to the user as being loaded as “Group Track Contents” or something similar rather than loaded as a full-blown song (to avoid confusions). I’m just pointing to the possibilities here.

Again, everything in such reloaded fashion would need to conform to newsong.xrns’s global parameters. So for example a 512 length pattern in drumkit03.xrns would spread across 8 x 64 length patterns in newsong.xrns when loaded as a content for a group track in newsong.xrns. Any necessary conversion goes for child parameters such as “Beats / Min” and “Lines / Beat” as well, when being loaded into a parent group track.

4

Sounds like a great idea to me, if it’s doable.

5

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):

  1. Launch Renoise. This will be Renoise instance R1.
  2. 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.)
  3. Start building a nested group track structure in R1.
  4. Load a previously saved .xrns song into R2.
  5. 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.
  6. 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… :)

6

Anything that is Renoise branded IMO has to be smooth and flawless. You have already mentioned ignoring important factors such as differences in BPM, LPB and pattern length. And then let us not get into the problems that may come from Send Tracks. All this to me points to it being better utilised as a script of some sort, whether it can be done with the LUA API and thus done “online” or if it would need to be an advance on the Merge Songs tool (offline) I don’t know.

I think songs in tabs and an extra mixer layer (and better ways of copying full tracks, all patterns with effects, sends and automation between them) with another level of mixer and effects for playing them together is more the way to go for a native solution.

7

I’d love to have songs in tabs, that would be awesome. But then you probably open up another can of worms as well, such as: what happens with all the routing to external midi stuff in the various songs? What about ReWire? And so on…

I’m somewhat thinking more in terms of a “Group Track Contents” object here, because such an object would make it possible to selectively carve out portions of a song’s resources for re-use in other songs. We could store variants of the same material and just categorize it under different names, rather than having to load entire songs. Basically what I’m after is just the kind of “package-deal” that can be opened and saved between Renoise songs. Such a package-deal would have clear limitations and the user would know about what qualified as such an object before saving it.

Anyway, it really doesn’t matter to me whatever the solution here would be, so long as it’s making it easier to recycle and mix together material from multiple song sources. That’s the major issue and I’d love to see more discussion about it in these forums.

8

bump

9

I agree, loading multiple songs in one instance (for example in tabs like milkytracker) would be a nice feature. Though it wouldn’t be very different from having several instances of renoise running at once, other than some minor interface details.

This “load song into another song” feature i guess would be waaaayy too complicated to implement, and there’s probably a LOT of potential problems that could be caused by this. Just my wild guess.

10

There was another idea about this in another topic, I think, otherwise maybe just in my head, where another song would just be placed “after” another… It should be quite possible, maybe better/faster/stronger though to do it in a script/program from outside of renoise… But with the new BPM automation you can set any BPM, the only thing is that sadly we can’t group send tracks, but maybe it’s not needed. It’s also fun then to experiment sending snaredrum signal of one song, to the kickdrum fx send track of the other, etc… And all the pattern fx would still just work! It’s probably much better than two Renoise instances because there’s a lot of people using asio drivers where you cannot connect more than one program (amirite?)

I’m (re)learning C++ anyway, why not make a xrns combinator?

11

Let’s first deal with the problems before looking at the possibilities…:
How would you load several different sequence ranges which have different repeated sequences and different aliassed tracks?
If you wouldn’t mind that everything is added to the existing sequence, then the problem is solved quite easily. But if you want those sequences be loaded in parallel to what exists or specific into a sequence range then there are rules to be defined for that to work.
However regarding the “adding to the existing sequence”, it is easier to work with parallel opened copies of Renoise and copy / paste between those versions.

12

How is that? because when this tool / outside-the-box-app is made, you can easily integrate stuff (sounds) from one song to another… You can do that with two opened renoises too, but on many systems you won’t know what fx chain / instrument / sample / preset you are copying since you can only hear one renoise at a time. On linux with Jack of course you can have multiple instances producing output but in windows I haven’t been able to compose in two instances simultaneously.

13

Maybe try to split leght in the tracks? One track one leght. Merged tracks in pattern any time its big chaos for arrange. I hope you understanding me))

14

@vV:
I really don’t see any problem involved in my suggestion, since I assume that the user exports a library of re-usable contents that strictly conforms to a pre-specified song structure when imported again. I’m not suggesting that the user should export whatever in 180 BPM, 6/8, 512 row patterns with lots of fancy and complicated pattern command stuff in it, and then expect to magically import it back into another 4/4 90 BPM song structure with 64 row patterns. It should be the responsibility of the user to make it easier for himself. Specifically, group track import/export should strictly conform to the current limitations of group track contents.

A first step could be to apply the group tracks concept for the samples/instruments too:

Then also importing the DSP chains into the (sub)group tracks, treating each main group track as the master for the imported song(s).