No-Gear Live Set

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…

now there’s a thought,…

what if, for the time being, you guys go back to the basic idea of 2 turntables and a mixer, ie: you throw out all the requirements for syncing, bpm matching etc, all the fancy stuff,… cos fundamentally all you need is a DJ mixer inbetween 2 renoises.

dj’s should be able to sync things manually shouldnt they?

put the dj back into DJing dammit!

disclaimer: i dont dj so i most definately dont know what i’m talking about.

i’ve made a rather crude video of a basic version of the patch i’ve been talking about as a proof of concept. i’ve started a new thread over here:

Oh man I just figured something out in 2.5.

"Controlling renoise… with renoise!: :)

I don’t have my glasses with me so I won’t go into too much detail, just how to do this.

You must have some sort of midi router to begin with, OSX (IAC) and linux (jack & alsa) have this, in windows use something like midi-yoke (it works perfect)

-I’ll try to make a recording of this once I find a decent screen capture for OSX.

You need at least 2 instances of renoise open for this renoise on renoise fun.

you can either do this synced or non-synced.

Synced entails making one renoise a master & the other a slave,

In the midi prefs of renoise(Master) in the middle at MIDI CLOCK Master select the routing device, such as IAC Bus 1, Out to MIDI Yoke:1, Midi Through Port 0

On instrument 00 go to the Instrument Settings, to the MIDI Properties then Device select IAC Bus 1, Out to MIDI Yoke:1, Midi Through Port 0

now that is set.

now go to the Track DSPs

insert a Meta MIDI Control Device, as the instrument, make sure 00 MIDI (cha 1) is showing.

Go to one of the “Untitled” sliders and give it a CC number like 22. (make sure the CC is next to it)

Now insert a LFO meta device in the same track and link the destination to that slider you just set up.

The slider should be moving at this point. and this slider is what we will use to begin telling Renoise (Slave) what CC controller we are using.

Now on to Renoise (Slave)

Of renoise (slave), goto midi prefs, at the top MIDI Master Keyboard / Midi Mapping:

In Device A, select IAC Bus 1, Out to MIDI Yoke:1, Midi Through Port 0 remember that is whatever you chose it to be in the instrument 00 of renoise (master)

Then at the bottom at MIDI Clock Slave, set it to whatever you have your MIDI Clock Master set as in renoise (master)

After all of that we are ready to start mapping, with the MIDI MAP.

**make sure you save the files now.

Now you can do all kinds of very weird & interesting things from the Renoise (Master)

Open the MIDI MAPPER CTRL + M or apple + M

and select the BPM!!! (Beats / Min.)

You can close MIDI Mapping at this point and see the BPM shifting with the LFO from Renoise(Master)

Now everything you saw high-lighted when you had the MIDI Mapping open, you can control from Renoise (Master)

The true power of Renoise! :walkman: