Oh yeah…and
+1
I can think of a good reason to slave other Renoise applications to a master Renoise application: Using several .xrns as instruments (or instrument banks/pattern pool/etc).
For example, suppose that in drums.xrns there are various drum kits and lots of patterns with programmed beats.
Instead of having to manually load these drumkits (or whatever) to the song.xrns file one is working on, one would simply load up another instance of Renoise and slave it to the master.
(That is, Renoise loaded with song.xrns act as Master, another Renoise loaded with drums.xrns would act as slave.)
This way one could build lots of kits and set of instruments in a semi-modular fashion, somewhat similar to how the “Combinator” device works in Reason.
Anyway, I wonder if such scenario is possible? Or are there technical limitations to consider that put an end to such dreams?
Currently instruments are not controllable yet, they need to be attached to a midi channel and then reply to CC commands, which they currently don’t.
The RNI structure is really better off for a big restructure so that all these shortcomings as multilayer etc. are implemented.
Slaving Renoise to Renoise master for this would be a temporary excuse.
Hmm… sorry, I don’t seem to get your point. What has the RNI structure got to do with anything, if we’re only talking playback sync?
If several Renoise songs are running in perfect sync with each other, one could actually treat each Renoise instance as a group/channel/set. I would be able to build my songs extremely fast because of this simple fact:
- loading melodies.xrns as Renoise application #1, running as ReWire Master
- loading bass_and_chords.xrns as Renoise application #2, running as ReWire Slave
- loading drumkit_14.xrns in Renoise application #3, running as ReWire Slave
- loading FX_kit52.xrns in Renoise application #4, running as ReWire Slave
That is, in total there are 4 Renoise applications open, each loaded with a Renoise song-file. The Master (melodies.xrns) controls playback of the slaves.
The way I see it, this would be a vast improvement because it would let me build “banks” of material that could then be recycled and easily re-used in other song projects. Would also make it possible to have A/B-monitoring of the same song, etc.
The Renoise Master wouldn’t need to control anything in the Renoise slaves, just be able to trigger the playback of them all in perfect sync. So that would be the limitation (on purpose).
So I ask this again, just because I’m really curious: Is this scenario something that is even possible with the current Renoise implementation of ReWire? Again, observe that I’m not talking about “full” ReWire control, i.e. Renoise Master could control instruments etc within the Renoise slaves – no, I’m just talking about the audio part, i.e. the sync playback of all open Renoise instances.
Yes this is possible, but I still can’t see why spreading tracks to more than one Renoise helps you to get an overview. What you want is track groups in one Renoise, not multiple tracks in multiple Renoises. All Renoises look the same, so you will get easily lost in what you want to do in which instance then.
The only thing I see where slaving Renoise to Renoise makes sense, would be a Live playing scenario:
You want to play songs after each others in two instances, mixing them in between.
Now with the new ReWire slave sync mode in B3 this seems to be possible, but we still have a bunch of problmes that will make that akward to use:
- You have to use/add ReWire-In Devices or the other instance won’t be slaved at all. This especially is a problem because while loading new songs, those are temporarily “missing”.
- BPM jumps. You would have to prepare all songs so that they are running at the same BPM. If you forget this, you’ll load a song and suddenly things are played back in a BPM that you didn’t expected.
- Navigation is hard in two instances. You easy get lost in which Renoise is not what. Master or slave. Where do I have to do what.
I think all those problems and wishes look a bit as if they could work with ReWire. To make that a great feature & experience, this is not enough, and should be solved in Renoise with dedicated features. No half-assed features please.
track groups is what we need.
im with taktik on this
Original post reminds me of http://www.youtube.com/watch?v=anwy2MPT5RE
“I love renoise. I’m having renoise rewired to renoise and renoise and renoise and renoise”
OK. Track groups in one Renoise sounds fine, and will probably be much better. Hmmm… I must have missed that discussion. Basically what I found appealing was the idea of having these “groups” treated as single independent objects, to be reloaded/re-used in any song projects. That way one could distribute entire .xrns-files that acted like single instruments or kits. But the overview loss will probably make such a chain a mess. And there is always the Combinator device in Reason just waiting to be slaved to a Renoise master.
I kind of agree with this. Multi instance renoise would be eventually be bettered by a single instance that allowed the same feature functions as multi instance of the current 2.1 would/could. Also a single instance with better live playing facilities would obviously be more cpu and brain friendly in an already stressfull stage environment.
Trancender’s suggestion, for example, could be tackled by linking an instrument(like a kit) with a track/tracks and their DSP chains that would automatically load and insert themselves when you load that instrument=> which is an extension of track groups idea.
Once meta control routing across tracks can be implemented you could dedicate a single track as a “live control centre”.
For playing live, simplicity, stability and practice are your friends. Better 1 Renoise in this case.
That would be great.
Regarding songmixing, it is already possible to merge different songs (with the help of renoise-tools). So we have some different songs in the pattern-sequence and with the new live-pattern option it is easy (and great) to mix them.
The problem are the loads of tracks now; when merging 8 songs, you might have 60-80 tracks and no overview anymore in the trackscope. Now muting the right tracks is impossible. For live situations this is essential.
Some ideas to fix it:
-
do not try to show all tracks in the track-scope-window but organize it page-wise: limit the max shown trackscopes per page to n=8/12/16. When having more than n tracks, you can click on an icon to turn to the page with the next tracks (the master track is shown on every page).
-
option to hide all empty tracks in the trackscope (tracks that do not play any sound or have no notes in the currently played pattern)
-
the already mentioned track-grouping: The user can specify n tracks per group; maybe the groups can be coloured and become a name, in order to distinguish them easily. The margin of the track scopes (and maybe also tracks in the pattern) get the color. Next to the trackscopes there is an list of which track-group(s) should be shown.
Besides, an idea to distinguish different songs/sections in the pattern-sequence: the user can give each pattern a color (naming is already possible).
Bring on tabbed Renoise!
Firefox did it
Internet explorer did it
Safari did it
Birds do it
Bees do it… 
Your parents did it as well…Else you could not post that.
I’d Do it. …with renoise that is. 