No-Gear Live Set

I can’t remember how to do this in OSX and Linux. (should be easy)
But, for wxp & previous I just remembered midi-yoke.
http://www.midiox.com/myoke.htm
(I don’t yet know anything about 7 or vista)

I used this a lot a few years ago.
This midi routing software device allows master/slaving instances of renoise together.
After installation ‘requiring a reboot’ it is accessed through the control panel if you need to change anything to it.

Was Super fun! Earlier tonight I had 2 of my latest songs uploaded to soundcloud synced together.
Just designate one instance as master and any others as slaves in midi prefs.
They are pretty light songs so this config ran magnificently on the old thinkpad in my sig which also has wxpsp3 on it.
In my case I need to be using directsound on both instances.


I got share this too, it is weirdly awesome, and has nothing to do with really anything, except that I stumbled upon it while looking for a midi master control program. (it’s fun & very creative)

http://www.wizardmaster.com/bludgeonsoft/wmcp/index.html
I would post the real image but the image on the site is not really what it is.

this might be a silly thought,… but i recall a semi-serious thread during the beta testing for 2.1 where someone suggested rewireing renoise to renoise.

it didnt really come to much from what i recall so maybe it was just a silly thought.

yep, that was me. :D
As funny as it may have seemed at the time, I still think it was a great idea.
I maybe shouldn’t have used the Flux Capacitor Image to denote what I was talking about.
…made perfect sense to me though.

Yeah it made perfect sense to me too, and i’m pretty sure i tried it out just to see if one would rewire to another. I think i did it,…

but trying just now i realize that we cant anymore,… ie theres no Renoise option in the rewire device.

maybe i was just dreaming that i did it :P.

but this would make renoise a pretty easy live tool, essentially two (or mroe decks) with crazy live tracker fx… especially if you know all your hotkeys etc. a truelly gearless setup.

how hard would it be to make it so you could rewire renoise to renoise?

how many trackers does it take to change a lightbulb? :P

*at post #9 I remember I got kinda pissed off, and post #10 I realigned to make sure the original post was not being mis-interpretted.

The idea is missing a way to work with songs at much different BPMs.
I’m not sure if Taktik was talking about rewiring renoise to renoise or track grouping later in the thread.

Our role is to figure out the best functioning & most aesthetically pleasing way.
which is pretty nice.

ahhh track groups,… sounds like a nice solution.

it seems he was infavor of something internal so i guess he was talking about something like track grouping.

cant wait to see what he comes up with.

wasnt there mention of the next upgrade having OSC stuff? I dont know much about it, but from what i’ve seen you seem to be able to connect anything to anything else if someone can figure out how to program it.

perhaps that will provide a temporary alternative until the track grouping thing comes?

none.

the lightbulb will never be changed,because the trackers are to busy tracking:)

I don’t quite understand how the Track-grouping idea relates, so I can’t really speak on it.

But Yes, OSC all depending on it’s overall implementation is certainly a great solution for this!

http://opensoundcontrol.org/topic/60

That part is for us, and is vastly awesome in context.
This part will really change things for us.

Either way in retrospect, the rewire renoise to renoise thing was certainly a flawed quick fix.

Only thing is, I’ve been following the talks of LUA that members have been having here trying to glean what they are actually saying.
From what I can tell, LUA will be available to only distinct areas, this is clear. The player is said to not be one of those areas, which makes sense.
With that though I get curious how much the implementation of OSC will be reliant on LUA. If it is very reliant on LUA, that could mean OSC is not built into the communications backbone of renoise but outside of the core system.

hah, i’m not even going to pretend to understand any of that!

Heh, yeah, it gets tricky under the hood!

I only have very limited to really no personal programming background or even any real idea what renoise is doing behind what we see. :) I just love using it!
But I do know a bit about how OSC works.
The basic premise of what I quoted is:

Each module, whatever it may be, (It could be anything from the delay dsp device to the pattern editor to the transport, or even a whole device chain)
lists all of the functions we can touch or control (address)

It’s all based on networking, Servers and clients and such.

Using a hierarchal style like a Directory Tree, you would see at a prompt.

I’m really rusty with this, and I’m speculating but,
this would be something possibly similar to what you might see as far as an OSC message you would be sent from renoise (acting as a server) to be able to address the delay dsp device:

/127.0.0.1:777/renoise, /track1/devicechain, /delay/IO (on off or True False)
/127.0.0.1:777/renoise, /track1/devicechain, /delay/L (float)
/127.0.0.1:777/renoise, /track1/devicechain, /delay/R (float)

this part: “/127.0.0.1”
is just a private place in your network, people call it home.
It’s an address that will stay inside your computer. (you can also use other computers and OSC devices around you or anywhere on the planet, but you need to know the IP Addresses of the computers & devices on your network & wherever else, which really isn’t to bad.)

this part “:777” is the port. there are 65535 of these, that is Much different than the 16 midi channels! :)

The rest of it: “/renoise, /track1/devicechain, /delay/R” is just my way of showing a tree like form to dig into getting at the parameters we could be able to access.

and the parts in parentheses are like rules of what you can do with them.

Float means you can use numbers like these “1.234567”

So yeah. it does get tricky. But, it’s amazing to see Renoise getting this,
it’s like seeing Renoise get arms, legs & a brain to computer interface all at the same time!

The thing I was writing about LUA was just me trying to figure something out, OSC needs a server to direct all the inputs and outputs.
That’s why I brought that up, as I am curious if LUA will be handling all of this or if there is an OSC server actually inside Renoise’s brain right now.
Because the change between 2.5 and 2.6 it’s said isn’t to be too much, but the change between 2.1 to 2.5 must have been A Great more than what some of us may have been lead to believe.
-A possibly very large rewrite of the stuff we don’t need to see.

two. one to track and one as a slave to rewire.

taking beta 8 on stage tonight, pray for me it won’t crash! ;)

good luck mate! hope its a good one :)

p.s whats your set up :P

No crashes :) and was flipping all kinds of beatsyncable plugins through each other, muting and solo’ing channels with the BCR controller. Learned some things, what worked with the songs I was ‘remixing’ and what not, so feel confident to push it harder live in a couple of weeks. Shame there hardly were any people there, so that was disappointing. Venue was catered to the arty (people sitting on the floor) and not so much to the 195 bpm amens ;) . A kick to hear my new tracks on a ridiculous good sounding system though :) .

I mixed tracks from cd on and off with loading tracks in Renoise on my laptop. Had a pre-determined order planned out, which I felt would be good for the night and live improvised the tracks in Renoise with the Bcr and plugins. Used a small Behringer mixer and also have used an extra monitor to drag the plugins too for oversight of tweakage.

i’m justing playing around with max/msp and rewire, because if i could rewire slave two instances of renoise to max/msp as a master it would be very easy to make a nice little mixer program to crossfade between the two renoises (and other more fancy stuff, in theory). this i could also post as an application so other people can use it if it worked okay.

the trouble is, it would seem when i open a second instance of renoise it doesn’t ask me whether i want it to be a rewire slave or not like the first… it just opens with the direct sound driver instead and ignores the fact i have a rewire master open.

does anyone know whats going on with this… is it not possible to slave two instance of renoise to a master?

That sounds interesting genfu, my only question is how you would go about syncing 2 songs that were not within an acceptable bpm range of each other?

To elaborate, say you have 2 songs with samples that are intrinsically linked to separate bpms, say 137.26 and 175. (bpms that can’t be multiplied or divided amongst each other) We would need these 2 songs in the rewire master to somehow be playing together within a precise degree, so the rewire master would whack out the slave instances timings, since the rewire master is the master BPM control, from what I know about this, which is not really enough. Since we have no real method of pitch shifting or pitch bending, this is the only thing I can see that really stands in the way of this working for the Dev Team to implement it.

I think this part is somewhat simple , through declaring itself something like this:
max/msp(master)
renoise(0),
renoise(1) and so forth.
So whenever another instance of renoise is loaded is sees other instances being declared and follows accordingly asking to add itself to the master. Once in, load songs, full asio, midi and in a bit OSC! ;)

I really don’t think this would get in the way too much if at all of those of us who use multiple renoise instances separately & in different ways.

That is the purpose of the thread I started about rewiring renoise to renoise.

This is the basic initial idea of what I would put in the patch, if it were possible to rewire 2 instances to max:

DECK A
-play
-pause
-resume
-stop
-link bpm to B
-manual bpm
-play at interval (e.g. at the beginning of the next bar, 4 beats etc.)

DECK B
(the reverse of above)

then you have a crossfader with selectable angles, perhaps a patchbay for midi routing, a soundfile recorder for recording the set etc. also an option to route the output to 4 channels for use with a real dj mixer if you have the hardware.

as far as changing bpms of songs goes, how well it works would be a case of trial and error, but for the most part I would expect that to synchronise songs you need to really design them at the same bpm, or a similar enough bpm that you can change the one bpm to match the other. if someone is doing a set in a particular style, most tracks would be in a similar bpm range (e.g. 135-145 or something)… in that case it should work okay to sync tracks in this way. it might be something you have to consider when writing your music, or you reformat a track for live use so that it will sync up okay (you’d probably want to do this anyway to make a version with plenty of pre-rendered material so save on cpu).

note that the idea of the patch is that you can sync tracks in a similar tempo range but you can also just start-stop songs from the beginning or a cue point, either instantaneously or at the beginning of the next beat/bar etc. so if you have two songs at a different speed you can do what a DJ might do and not blend them together in sync, but start the next track promptly at the right point. the idea was also to facilitate that.

finally, the patch is advantageous because it pipes the audio from both renoises out through max using one audio driver only.

there’s nothing much in this idea which would be particularly difficult to build if i could slave TWO renoises to max.

yes… that’s exactly what i want to happen.

sorry, what thread are you referring to here?

That’s an interesting idea, I didn’t know the bpm could be disabled for certain slaves.

Here is the thread:

It’s pretty much the same thing we are talking about here and goes into a little more depth, I guess. Also some other ideas or rather interpretations too.

ah okay… thats a pretty old one now isn’t it. worth resurrecting or not? the thread seems to cover more confusing (to me) applications of the concept. but for the kind of DJ/Live applications i’m talking about it would seem to make perfect sense to implement what you propose of Renoise (1) Renoise (2) etc. I’m pretty sure (but i do need to check up on this) that it would then be possible to sync each renoise independently or simultaneously from max/msp, which would make constructing a DJ mixer application a breeze.

Since you can already use a different audio driver to get audio out of both, and control the transport via midi with midi-yoke, i’m going to attempt something basic with what is already possible. but really rewire would be the ideal way to do this in terms of audio drivers and synchronisation…