New Tool: Instrument Chainer (Experimental)

Renoise Tools
1

Et violá:

A tool that chains multiple instruments to one.
(Meaning you can trigger multiple instruments with one MIDI key)
What do you need to do?
-Enable the OSC server in the Renoise preferences: Set to TCP on port 8000 (default)
-Right-click in the instrument box, in the context-menu go to “Tools -> Instrument Chainer” You get a list with all current instruments.
-Check the check-box for each specific instrument that you want to add to the chain.
-Select the track you want to route the audio and notes to.
-Select the midi device you want to use.

You can use a virtual midi cable like LoopBE to send the midi notes to the script, but use the master-track to send the audio to.

If you use your ordinary midi device (don’t use the selected native midi device also as midi-in device!), not all notes get properly recorded so that’s what makes this script not really super interesting for recording options.
But you can pretty reasonably control multiple instruments in Renoise and this is without needing ReWire…

Edit:Fixed note-off problem not being recorded(virtual midi cable only?), added sort of pattern insertion algorithm when using native midi devices to write in the track though above 2 linked instruments, this doesn’t work reliably anylonger.

1.05:added multitrack support… this mode is actually usable, also in song-record mode.

2

Got an immediate error after trying out this script after install:
[i]
"‘C:\Users\plugexpert\AppData\Roaming\Renoise\V2.6.0\Scripts\Tools\com.renoise.InstrumentChainer.xrnx’ failed to execute in one of its menu entry functions.

Please contact the author (Unknown author) for assistance…

std::logic_error: ‘add notifier: the given function was already added to this notifier.’
stack traceback:
[C]: in function ‘add_notifier’
main.lua:52: in function ‘initialize’
main.lua:19: in function main.lua:18"
[/i]

EDIT:

To be more complete, I first got the following message:

[i]"Could not connect to server reason: Socket connection timed out

Please check your network connection and try again"[/i]

I checked the preferences and the osc server was already running, tried the script again and bamm, error noticve like above.

3

Okay, the notifier problem should be fixed for that specific occasion. (Reuploaded and attached the tool in the first post)

Is the OSC server running in TCP mode and on port 8000?
If neither of both are correct, it won’t connect. You can also changfe the specifications in the “globals.lua” if you desire another port or ip-address.
The default is localhost.

4

quality , cheers vv

5

Oops, was running in Udp instead of Tcp, changing this setting + installing the script and enabling my small midikeyboard (akai lpk25) and I was able to chain 4 instruments together.

However playing the midi keyboard had the notes hang indefenitely, right clicking the stop button and starting the script again after closure gave me the same error notice:

[i]"'C:\Users\plugexpert\AppData\Roaming\Renoise\V2.6.0\Scripts\Tools\com.renoise.InstrumentChainer.xrnx' failed to execute in one of its menu entry functions.

Please contact the author (Unknown author) for assistance…

std::logic_error: ‘add notifier: the given function was already added to this notifier.’
stack traceback:
[C]: in function ‘add_notifier’
main.lua:52: in function ‘initialize’
main.lua:19: in function main.lua:18"

[/i]

EDIT:

Seems like the hanging was initially the fault of using chiptune sounds with sustain enabled, but it still crashed after hanging. Right now I have the sustain off in the instrument editor and things are looking good!

Thanks for this tool by the way, is there a possibility one can select the normal computer keyboard to play chained instruments?

6

Okay… i made one more change where it is checked if the notifier is already given. (within the same minute i uploaded the patch)… i highly suspect you probably missed the last one as the “Number of downloads” still mentions “0”.
But this part is now double checked. Not only is the notifier removed, but also skipped if it still was assigned.
There are apparently cases where i can’t remove the notifier from the routine because some triggers won’t be happening anylonger.

If notes hang, this probably mean the OSC server missed a note-off message. That is the unreliability of this kind of communication that makes this a tricky feature.
With UDP, missing messages is even more of a problem. Would probably not be a bad idea if the server would have some feedback system on the UDP protocol to ensure messages have arrived.

I commented the routine out which made this possible because it worked half-assed: I have no idea how to detect note-off events since the keyboard handler i use for this, does not provide my keyboard routine this intel for that once i release a key.
It only tells me if a key was hit.
If also “depressed” states are given, i can happily bring back that part.

For now i’m going to bed.

7

Mmm, I have the two break loops supplied with the renoise install (amen & apache) beat-sliced & beat-synced over 2 instruments. Chaining these and triggering the individual hits through the lpk controller, more often then not, results in only one break-slice playing opposed to both at the same time :( , think I have the configuration set-up right, dunno what is the problem. Can’t believe the Osc server is missing that many messages, could it be my firewall interfering?

8

How is the NNA set? Remember that both instruments are triggered on the same track, so i guess NNA applies here.

9

NNA’s are set to ‘cut’ right now, as I’ve never tampered around with these settings, what is best to choose here?

10

Best bet is “continue”.

11

legendary :)

12

why are you using osc over tcp (as opposed to over udp)?

13

interesting tool,at first glance it works,will have to test it more though.

14

Well, the main.lua has the function connect_to_server() at the bottom…

Simply change this:

  
function connect_to_server()  
-- client, client_error = renoise.Socket.create_client(osc_host,osc_port, renoise.Socket.PROTOCOL_UDP)  
 client, client_error = renoise.Socket.create_client(osc_host,osc_port)

into this:

  
function connect_to_server()  
 client, client_error = renoise.Socket.create_client(osc_host,osc_port, renoise.Socket.PROTOCOL_UDP)  
-- client, client_error = renoise.Socket.create_client(osc_host,osc_port)

And then change the server-type to UDP and you can then easily test the difference. You need to put a bit endurance in the test, you will notice the irritations only after a little while.

15

had a small thought about the placements of notes

or idea/FT/nonsense

heres a image

16

I’ll have to see if i can manage that by bundling the messages somehow. Currently they are sent serialized which makes this kind of control impossible.
And if i send them in a bundle, i suspect that Renoise would still treat the bundle-contents serialized anyway.

17

ok sounds good,i really think it makes more sense to place the notes(of especially breakbeats)like the top of my shitty image shows :D

so if thats doable,that would make more sense IMHO

18

I doubt trigger/note_o## would work this way if i would require GlobalOscActions, but i would have to test that first. (The docs already sais these are processed internally, so doubt i can circumvent the TCP transmission here)

I would need an extended note-registrator like the NoteRouter approach, for off-line editing…
Won’t ofcourse do any good in real-time;
Specially not if i have to check the note-states (are they currently note-on or has a note-off been passed) → This makes the script really slow stuff down.

19

Well, note triggering is not part of the current API for a good reason: XRNX tools run in the UI thread. But note triggering stuff should happen as fast as somehow possible in the player realtime thread - every ms counts here.
VV: we discussed that, you know why its done like this. And its also not that I don’t want to allow such realtime scripting in future. But I’m right now quite happy if we manage to get all the stuff we already now have in the API smooth and stable. One thing after the other?

Your hackaround, using Renoises OSC implementation is technically interesting, yes. But its still a, well, really cumbersome hack and will never work perfectly. Please lets not encourage everyone to copy and paste such hacks, but do it the “right” way as soon as we are ready for this.

20

I’m not posting this tool online on both tools and the SVN for these reasons. The tool does supply some interesting information for the usage and desires.

The OSC note trigger allows us to do real-time stuff, but this way you can also see how it relates to pattern recording and stuff that also supposed to be done real-time internally.
Let’s suppose i was sending this info from outside Renoise using PD without internal hackery, the problem of registering notes in the pattern editor is still equivalent. In the current case i am actually not hacking anything yet-> pure gathering and sending the messages.

I’m not eager to use hacks and do pattern editor recording across the internal process but i do consider it appropriate to describe what can be done and what will not suffice to just answer the questions that are base upon experiences.

edit:Another thing is:This scripts also stresses the UDP server thoroughly, so can also be a good test-script to get the UDP networking a little tighter. Though, seeing that the server receives the messages perfectly, it may not be a UDP communication problem, but more how this communication or the messages are handled.