we can already run several instances of renoise today
why not take advantage of that fact and design renoise so that one instance could be enabled to act like a master and the rest would become slaves ?
that way we could easily glue together (into new songs) the many 1-4 pattern renoise “songs” that collect dust on our hdd’s
the master renoise’s matrix & pattern editor & instruments would control and trigger patterns in the slave renoises, all instances running in sync at the same time or starting/stopping after one another
renoise would become more modular, as we could just replace “drums04.xrns” with “drums07.xrns” if we wanted to try out another 32ch drumkit with new patterns on our current song
maybe this could also open new doors to having another type of arranger in the renoise master ?
Let’s look at the facts…People who are using multiple instances (myself included) are currently jumping through hoops:
On Windows, I’ve had to install alternative audio drivers for my soundcard (ASIO4ALL) so I’m able to share low-latency audio outputs.
On OSX, I’ve copied the entire Renoise application a couple of times to allow multiple instances
Not a Linux user myself, but this might fare better with Jack? I suspect there could be other challenges though…
All in all, this boils down to that running multiple instances is very OS-dependent, and therefore hard for us to support - at least officially.
One solution could be to use something like inter-Renoise Rewire / Jack transport/routing. This might prove useful here, but I remember that the idea of allowing Renoise to act as both slave/master was shot down when Rewire was first introduced in Renoise.
Another solution would be what you’re aiming at, .xrns - it sounds like a more integrated approach, with a functional arranger actually hosting a number of xrns files. To me, this doesn’t sound like a poor hack at all, because on top of the obvious advantage in being able to arrange multiple songs, it would solve the OS-dependent issues I just described.
that how I do it with jack on linux timing via midi see How To Record Voice While Liveplaying
so yes this could be great for Renoise instances synced & chained together
We would need an internal routing facility for this, Rewire does not offer this functionality.
If some kind of routing feature would be programmed, then better make this an all-round routing feature (also allowing to patch MIDI from anything to anything and audio from anything to anything)
I just dropped by the forums to basically request this! I think multiple documents would be awesome. I’m not sure master/slave functionality is needed? I mean what are the reasons other people have multiple instances of renoise? For me, it has to do with using one document to come up with ideas parts, loops, etc. and then rendering and moving them into my main “song” file.
I think for me, just being able to have a ton of renoise documents open at the same time would make things much more enjoyable. It would also add new life to the template feature. For instance, you have your main song file and then open drum loop template or a melody template or whatever. I don’t think MIDI sync is that crucial because it’s easy enough to render and move your files. We can already copy between renoise instances(at least on OS X), so I think many of the pieces are in place to get this working already.
Now, if the developers want to get really crazy later on down the road they could allow document “aliases” inside renoise where you could insert a marker to a new renoise document. This would be a better solution than clips or anything like that, in my opinion. Autoseek 2 . You’d probably want a new file format to group all these xrns files. Perhaps something like an a zip file with XML or how app files are on OS X? That way it’d easy for us to get at the guts of it and manage, and also keep everything organized.
to have multiple .xrns files open in a single renoise instance would indeed open up a new horizon of possibilities
here’s how i imagine the workflow could be like in, say, a future renoise 3, for somebody who hasn’t used renoise since version 2.7:
you launch renoise, thinking to yourself “now i’m the mood for loading some drum samples and make a cool beat”
but then you notice that you can’t load any drum samples, because in renoise v3 all you can initially load in that instrument list is .xrns song files
“ok,” you think, “this is a little bit different than how renoise used to be like” and so you load up a .xrns song from your renoise 2.7 days into instrument slot 1
“now what will happen”, you ask, “if i place out a C-4 on a track?” - then you hit play and whoaah! the .xrns song loaded into slot1 will start to play something, but it’s not the song’s first pattern
“weird”, you mumble, and replace the C-4 note with a F-4 note. - now it will play another pattern
you open the instrument window and discover that in renoise v3, the patterns of .xrns files can be mapped just like samples could in v2.7, allowing you to play and trigger patterns as if they were samples
“hey, this is cool”, you conclude, and load up a bunch of .xrns song files into instrument slots 2-5. - and now you have five .xrns songs open in a single renoise master instance
you soon discover how easy it is to load up the many short .xrns files you have on your harddrive, and mix them together into new full length songs
you also discover how awesome it is to experiment in the “Master” pattern editor, triggering drum patterns in drums07.xrns with single notes while at the same time triggering patterns from basses02.xrns and pads08.xrns
when you want to edit the individual .xrns files loaded into the instrument slots, e.g. edit stuff or add new patterns, you just switch from Master layout into the nested .xrns with a click
what i’m suggesting here is not a re-write of renoise’s code, actually i’m after is in essence some kind of “wrapper”, i.e. a special compiled renoise version where the layout and features would look a bit different, maybe even with a non-vertical arranger lane instead of a pattern editor
single .xrns files would still load in renoise the tracker (as against renoise the wrapper) and so in reality there would be two separate compiled softwares: renoise tracker as we now it, and renoise arranger/wrapper (new product hosting multiple instances of renoise the tracker), making it possible to not break anything in workflow, stability etc for anybody
i just woke up in the middle of the night, after having dreamt of this above described renoise 3.0 tracking experience…
what caused me to wake up was that taktik made this work a bit differently:
he coded renoise so that each renoise instance became a wrapper for other renoise instances
so we could have a renoise song in a renoise song in a renoise song in a renoise songs in a renoise song in a renoise song in a renoise song in a renoise songs in a renoise song in a renoise song in a renoise song in a renoise songs in a renoise song in a renoise song in a renoise song in a renoise songs in a renoise song in a renoise song in a renoise song in a renoise songs in a renoise song in a renoise song in a renoise song in a renoise songs in a renoise song… and any number of multiple renoise songs in any single renoise song…
and that just caused my mind to overheat and i woke up
Although I like those ideas as a kind of Clip-based approach to Renoise tracking loading Songs as Instruments still definitely has a lot of restrictions!
I would love to see some kind of Clip solution to above but more inline with the original idea of this thread I think the idea of Tabbed and Synced (to a degree) instances of a Song, which can be changed, loaded, edited, started, stopped, navigated etc etc all while others are playing or not. This coupled with a few other Renoise Live features (such as related to how MIDI may be shared across Songs) and a separate Keyboard Shortcuts list for when in Live Mode I feel is something that could take Renoise even further.
@ .xrns
I admit I immediately thought of recursive Renoise files where you had a song call another file that called the original song file!
Renoise files as “instruments” is a clever solution! It got me thinking though, about a separate program. I mean, you bring up a really good point about wanting to keep it familiar to current renoise users. In some ways I feel like the hyper-control that renoise gives you maybe isn’t conductive to this type of sequencing. I think there is valid reason to worry that the program will get bloated if it tries to do too many things, instead of focus on what it does do exceptionally well now. In my opinion for working with samples, especially in a rhythmic fashion Renoise is basically perfect.
I’m not sure it’s a good idea, but what about a Renoise file sequencer, that looks and operates mostly like Renoise, but is suited for Live use, and a more overlapping clip based approach? When you want to edit you clips they would open up in Renoise proper. This approach would have it’s own set of hurdles, as well. I wouldn’t mind making a separate purchase for something like this, because I freely admit these feature do go beyond the original scope of Renoise. It’s fun to talk about, but a lot of work for the developers!
Anyway…just to reiterate, just opening multiple .xrns files would speed up my use of Renoise a great deal regardless of whatever else is or isn’t done to Renoise.
I’m just curious what do you feel the restrictions would be for you and your workflow?
Well I’m thinking more for live performance than composing but let’s try and take a few ideas.
Semi-synced playback. EG will always start playing on a quarter beat, rather than completely free. So you load your song in a song-slow, cue it up and start playing your pattern(s)/sequence when ready. No need to enter note values and find the correct patterns for the right place.
Looping patterns of different lengths/time signatures. Sure Clips gives you access to some form of polyrhythms, as long as you are either looping a single pattern/sample, but still really makes sense to have the master pattern with a common divisor. Whereas with separate songs you can skip through either of them, at all time, again and again, without ever losing your timing.
Changing one component of a multi-part performance. Much easier to open up and view a whole song in a tabbed view than as an instrument and then add to patterns to play.
Shared MIDI devices; it will be a lot clearly to see instantly which you are working on a lot of the time IMO. Although that is a usability thing and could well be ironed out.
Yes most of it can be done with having multiple instances of Renoise running concurrently as it is. There are hardware limitations with that though (most ASIO will only allow one application to access the output.) An extra layer to Renoise, where you can load multiple instances within it, and has different keybindings that can be set up for performance or arrangement targeted usage, taking the qwerty away from always being a musical keyboard for instance. Guess it’s a bit like Ableton has the Session and Arranger views…
Sure there is much more that can be thought about and the two could well work together hand-in-hand.
i’d settle for any solution that expanded on the core concept of this thread: working in sync with multiple .xrns files
imo, if we “think inside the box” here, i.e. if we discard all the solutions that require an additional multiple renoise song wrapper or file sequencer/live arranger software or internal rewire-like sync between renoise instances, one of the best integrated solutions - besides the “tabbed .xrns” approach - probably is the extended clips import/export approach, where we could package together track(s) with instrument(s) and effect(s) into a single cluster that could be dragged and dropped into another instance of renoise (and naturally also previewed/imported through the browser, meaning we could play/audition/import them as a micro renoise song)
for example, you have multiple instances of renoise open and try out, say, different drum arrangements from drums1.xrns/drums2.xrns/drums3.xrns… and so forth. - when you finally decide to use the stuff in drums3.xrns, you simply select everything you want and click to make a package-deal of it. - then you drag that package into another renoise instance and it will automatically unfold into new tracks, expand/populate the instrument list with the orignal vst instruments/samples, map the samples as they were, attach dsp chains to the tracks, import the pattern data, import the pattern matrix, etc
this above solution could go well implemented with the concept of “folder tracks within folder tracks”, so that renoise could represent in the pattern editor different layers of data:
[+] first layer (“organic structures”): each track/channel represent a .single xrns song (or package, a container of select data extracted from another .xrns song)
[+] second layer (“molecular data”): the usual folder/group tracks within a song that renoise users frequently demand to avoid clutter
third layer (“atomic data”): the raw pattern data we currently have today in renoise 2.7
i think in this approach the instrument list, etc, would have to be in layers/folders too, for the sake of separation and ease of navigation (so that samples in drums03.xrns would be unfolded from a single instrument group item), maybe with different optional coloring etc as well - and, add a nice visual zoom in/out cross-fader effect to that (mouse wheel scrolling or whatever to navigate/flip between the layers)…
i also think this layered approach could actually hold the key to a full blown arranger within the tracker paradigm… for example, in the first layer (each channel representing a .xrns song), the note data could be mapped to treat patterns (within that specific .xrns song) as “instruments” - e.g. C-4 triggers a specific pattern, D-4 another pattern, etc. - while the second layer (“molecular data”) could treat “defined sequences/ranges within group patterns” (i.e. clips) as “instruments” so that a C-4 on this level is mapped to trigger e.g. lines 00-31 of specific tracks within that group…
. You’d probably want a new file format to group all these xrns files. Perhaps something like an a zip file with XML or how app files are on OS X? That way it’d easy for us to get at the guts of it and manage, and also keep everything organized.
