Could you name a few effective usage situations for slaving several Renoise sessions to one Renoise Master?
We had a small debatre about it, but could not find a good effective use for this idea.
Everytime …choice’s …signature …comes long …
CAnnot resist… …must click …have to watch …
the steve zissou dance…over …and …over…Again …
multiple songs at the ‘same time’, of course!
(plus, gets rid of the idea of wanting more than one song loaded in renoise.)
plausibly could even send different songs to different outputs, which would be extremely cool w/ multiple songs at the same time and a sweet computer all controlled by Renoise “The Master of It’s Self”.
I really don’t have any idea if it’s possible, that’s why I through in the double inverted flux cap.
@Gentleclockdivider, I agree!
You just can have only 1 master, the other ones will became slaves automatically.
Well, that is not really a problem if that only regards Renoise.
You can start/stop the song from anywhere.
There should be a good answer upon having more Renoise sessions slaved to a Renoise master.
Loading multiple songs is not going to work out because all slaves start at the same position as the master, so for DJ purposes, this idea already drops a fatmen’s pants.
pimp my track
i can’t be bothered to think about this anymore.
change the topic heading back to what it was.
whoever did it, fucked it all up.
i didn’t draw the picture for it to be misinterpreted.
in the picture the digit in parantheses is the instance, not the routing.
the routing is declared with the damn red lines!
okay, ‘red arrows’ that could misinterpreted to be pointing backwards.
however that is not the case.
the red arrows denote the rewire master’s control.
something happens when a rewire slave registers itself with the rewire master right? some form of an ID, which i can only speculate.
it registers itself as “Renoise”
what the idea is stating is to increment the instance to allow multiple instances of rewire slaves.
in the host a rewire slave list would look like:
I understand the idea you want to go, but i still do not quite understand the effecient use of that…
I can give only one example where it might be useful:
Windows Vista 64-bit having 16GB of memory.
Renoise Master is addressing 4GB and memory is getting full, yet we need more instruments so we instantiate another slave so we can claim another 4GB of memory for extra instruments.
Currently that makes sense… however as soon as Renoise would support 64-bit, this idea will than be overruled at the instance.
Another use could be cooperative song-writing:you co-write a song with someone else, but instead of wasting eachother’s patterns, you write your own version so you can instantly “diff” both versions. (A/B editing).
These kind of needs form the ground to ratify such implementation as slaving (multiple) Renoise to Renoise.
From my standpoint, Idealy, the usage allows ‘synced, realtime live mixing’ or ‘synced, automated mixing + rendering’ of multiple renoise songs. The premise is slaving multiple renoise in parralel to a master being either renoise or another master.
I haven’t hooked up my midi controller w/transport control to see if renoise’s transport accepts bpm control changes, but I do know ableton and some other rewire master/host apps do. So either way, we do have that bpm change now.
What about using a different soundcard for each Renoise instance? (although I have no idea WHY anyone would do that )
What about using different timing resolutions in each Renoise instance?
What about recording Renoise live into Renoise?
now that would be awesome
Of multiple patterns, yes this cannot be done with the Render to sample feature.
I think it would be good if you were using different LPB settings on each instance. Really high on some (eg for technical drum programming) and low on others (bass lines). Also makes polyrythmic composition easy. (not to downplay the delay column; I love the delay column )
I suppose this amounts to a multi-instance alternative to a zoomable pattern editor.
This part Vv:
I meant more as a declaration on the slave side.
Instead of the rewire master trying to discern between multiple instances, the slaves would declare themselves as:
this would be as they are added to the rewire list.
also if possible a corresponding number in the background of the pattern editor, like an underlay would make this quickly discernable to the user denoting which instance was in front of them.
Kickofighto’s explanation is perfect with usage of different LPB’s quickly allowing realtime non-destructible usage of different timings.