New Tool (3.1) xRules

Renoise Tools
32

I can get the buttons to show up as “renoise/trigger/note_on (4 arguments)” and “… note_off (3 arguments)” when trying out some rules. But somehow the MIDI mappings dialog doesn’t recognize the incoming MIDI messages coming from the button grid.

Ah, right - now I get it. This is down to how the internal OSC client works. It basically accepts two flavors of MIDI

  1. Routed MIDI, with the ability to trigger on a specific track & instrument.
  2. Raw MIDI being passed as if it came from outside Renoise.

xRules tries to be clever and always pass notes to the corresponding track and instrument, while anything else is treated as raw MIDI. And apparently, the notes are not MIDI mappable while the raw MIDI is. So that would explain your problem.

Good thing is, if you are looking to map the notes somewhere you probably don’t care about the track and instrument info.
So perhaps the “output_message” could simply be expanded with an extra option - let’s see if we can squeeze this into the next update :slight_smile:

It seems to only start the issues after trying to add a port_name condition

Thanks, that’s useful information

33

Could this tool be used to solve this problem?
https://forum.renoise.com/t/make-launchpad-matrix-light-up-when-using-keyzones/45743

TL;DR: Send information to the matrix of my MIDI controller to make it light up to indicate which of the buttons is currently used as a keyzone in the current instrument.

34

TL;DR: Send information to the matrix of my MIDI controller to make it light up

In theory it could, yes. But right now, the tool doesn’t even have the ability to send MIDI out. The next release (which will arrive in a couple of days) will feature MIDI output among other things.

And while it’s possible to do what you describe with xRules, the tool is really designed for more “simple-ish” purposes. If you want to run full-blown “applications” on a controller, I think you should check out the Duplex Keyboardinstead (and feel free to bump that other topic; Duplex already supports several AKAI controllers and we likely could make it support the APC key25 as well…)

35

Good thing is, if you are looking to map the notes somewhere you probably don’t care about the track and instrument info.
So perhaps the “output_message” could simply be expanded with an extra option - let’s see if we can squeeze this into the next update :slight_smile:

Awesome! Well yeah, I want some buttons to trigger instruments on a specific track, but I already found how to do that, and some to be mapped to effects. But I assume it’s easy to write rules for that, such as “when note is between … and …”

Do you have any idea how I could get this tool running on two instances of Renoise on Windows 7? When I open a second Renoise file the tools stops working on one or all the instances of Renoise.

36

I want some buttons to trigger instruments on a specific track […] and some to be mapped to effects

Yes, that would indeedbe a nice way to use this tool.

Wondering about the note → effect mappings. How are you doing this? Because, one thing I don’t really understand about Renoise is why we can’t MIDI-map individual notes to parameters.

In the Renoise MIDI mapping dialog, you can assign a note but then you have to control the parameter using the notevelocity. In practical terms, when playing something by hand this is really hard to do (and some pad controllers doesn’t even transmit velocity). I guess xRules is really handy here!

As for the multiple instance setup, it really depends on the audio/midi drivers that are installed on your system. Here, I can open multiple instances and they can all receive, send MIDI just fine. Lucky me :badteeth:

But apart from the device-driver issue, running multiple instances is actually a challenge to do right. Most often, you’d want each copy of Renoise to run with a slightly different configuration - see this topic for a more in-depth description of how that could be done.

37

Wondering about the note → effect mappings. How are you doing this? Because, one thing I don’t really understand about Renoise is why we can’t MIDI-map individual notes to parameters.

In the Renoise MIDI mapping dialog, you can assign a note but then you have to control the parameter using the notevelocity.

Maybe effects was not really the right word. I’m using some buttons on the Livid Ohm to control general stuff (start/stop song, loop section, record samples, …). As far as effects go I just toggle dsp’s on and off with them, apart from maybe the repeater dsp. I use the sliders to control the actual parameters.

As for the multiple instance setup, it really depends on the audio/midi drivers that are installed on your system. Here, I can open multiple instances and they can all receive, send MIDI just fine. Lucky me :badteeth:

But apart from the device-driver issue, running multiple instances is actually a challenge to do right. Most often, you’d want each copy of Renoise to run with a slightly different configuration - see this topic for a more in-depth description of how that could be done.

The thing is, I was able to do this just fine on Windows 7, before using the tool. But I need something like this tool, so that some of my mappings keep working while switching through banks on my controller (https://forum.renoise.com/t/create-midi-mapping-coming-from-any-channel/45527). Something that’s strangely enough not a native feature.

My audio interface (Komplete audio 6) can handle multiple instances of Renoise. And I can split the MIDI messages from my controller using Copperlan. The only thing I needed to do on startup was select “VMidi 1” in one instance of Renoise and “VMidi 2” in the other instead of my controller. Each time I opened a new file those preferences remained. Using this tool on one instance of Renoise works fine. But once I open a second Renoise screen, one or both the OSC servers can’t receive MIDI and the tool gives error screens. Each time I open a new file it also messes with the preferences of the tool itself. This has probably more to do with how the OSC server handles data, then with your tool. So sorry for messing up this topic.

38

The thing is, I was able to do this just fine on Windows 7, before using the tool. But I need something like this tool, so that some of my mappings keep working while switching through banks on my controller [/url])

Hm, if you are already able to initialize the devices across multiple instances then yeah, I wonder why running the tool would break things - it really shouldn’t.

Also, you made me think a bit more about this whole multiple-instance scenario. The batch-launching trick I linked to above will make it possible to launch each instance of Renoise with certain tools enabled or disabled. This would be one way to go, having xRules interpreting MIDI in one instance, with the other one running ‘standard’ mappings.

To improve on this, xRules itself could have a “multiple-instance” option, which would automatically detect if other instances were running when launched, and (if this is the case) make it use a separate configuration. So you would start Renoise A and then Renoise B, each with a different set of options/rules/devices/etc.

39

OK, just finished v0.61
Download:http://www.renoise.com/tools/xrules

IMPORTANT: If you have created rules of your own, take a backup of the /rulesets folder. The new install will overwrite the existing ones!
(you can find the folder from Tools > Tool Browser > rightclick and ‘reveal’ )

This is only the second release, so I’ve fixed a number of the reported issues. Probably introduced some new ones too :smiley:

But really, the big news is that now it can both send and receive OSC and MIDI.
Before, it was limited to receiving MIDI and passing that into Renoise - now, you can do quite a bit more. This also means that the user interface has been re-organized a little bit to more room for new stuff.

If you want to work with OSC data, the pattern syntax is quite simple:

-- interpret incoming pattern with two integer values
/some/pattern %i %i

-- of course, you can also specify a literal value
-- (these two are interpreted as integer and float, respectively)
/some/pattern 42 3.145

-- you can assign names like this (will show up in the UI)
/some/pattern %i:foo %i:bar

-- all supported value types:
-- %i int32
-- %f float32
-- %n "number" (can be both integer or float)
-- %s string

-- define an output pattern like this
/another/pattern $1 $2

-- the "tokens" determine the order of incoming values 
-- so, in order to flip the "foo" and "bar" around you would do this
/another/pattern $2 $1 

-- note also that if no output pattern is defined, the output is 
-- based on the input pattern

Btw: I just realized that I have not yet implemented OSC prefixes on a device level. So if you need to use prefixes, simply apply them to the patterns themselves.

When I write rules for the button grid. I can get it to produce sound. But I’m not able to MIDI map the buttons to effects.

This should be now be possible. To pass messages to Renoise without the extra routing information, select “internal_raw” as the target.

40

This should be now be possible. To pass messages to Renoise without the extra routing information, select “internal_raw” as the target.

Tested and it works. Thanks!

Now I just need to get this tool running on two instances of Renoise. Found that when enabling the OSC server in the Renoise preferences of one instance, the OSC tab in the preference screen of the other instance stops receiving MIDI messages and the other way around. With the new update of the tool, the settings in the options tab remain the same when opening a new xrns file. Was previously not the case. And I also don’t receive any more error messages coming from the tool. So it’s clearly a problem with how the OSC server functions.

Will try the link you posted above. But I have no knowledge of scripting.

41

Making each Renoise instance run with a unique OSC port would be a first step towards getting this whole multi-instance stuff working. That’s easy, you can change it in the Renoise OSC preferences (just remember to copy back those changes to ‘your’ config.xml).
However, to really get this thing off the ground, xRules also needs to “support” instances of itself. We are only partially there.

42

I went on a bit of a scripting binge yesterday, and have drafted that “multiple instance, configuration switching, whatever” feature.

Here’s how it works.
First of all, it’s disabled by default - you have to go into the options to enable the feature:

profile_options.png?raw=1

Once enabled, and you have chosen “choose profile on startup”, xRuleswill greet you with this dialog:

config_profiles.png?raw=1

It basically acts as “tool launcher”, and most of what you can do with profiles is squeezed into that dialog.
If you choose to remember a setting, you can always bring the dialog back by going into the xRules options.

Need to test a bit more, then I’ll release it.

43

OK, here is the preview.

As usual, take a backup if you have created rules of your own!

NB: If you modify options for a profile, you need to hit the ‘update’ button to save the configuration settings into the current profile.

It’s a small thing, but perhaps easily forgotten…

@iseeclouds: would be great if you could test it?

44

I really can’t tell how much I appreciate your work Danoise!

So I successfully got two instances running with different preferences using this script. It was a bit of searching to get everything configured right using the tool, but it’s working now. The only errors I noticed after testing it for more then an hour are:

  1. When I open the second instance, I get nothing in OSC preferences. When I close and re-open that instance, it works. Not that big of a deal really.

  2. This sometimes also happens when loading a new xrns file. Mostly closing and re-opening the instance once or more fixes this. But I can imagine this is not something I’d like to see happening while doing a live set.

  3. The second usually, but definitely not always, precedes with an error screen.

scripting-tool-error.jpg

Will let you know if I bumb into anything else.

45

Thanks. I did another tweaked version, but still consider it a preview.

Attachment 6592 not found.

removed attachment

Note that bugs are usually a snowball effect. So, once “something bad” enters the system without being detected, things can go wrong in any number of ways.

The first error message (or “symptom”) is the most important one

But I can imagine this is not something I’d like to see happening while doing a live set.

Yes, this tool is all about live performing. Whether in your living room or elsewhere :slight_smile:

46

Got the same error screen again after 15 minutes of testing out the tool with different songs. First thought it might have something to do with loading xrns files that have missing external vst plugins. But then I also got the error screen when opening a song without vst’s. Once the error screen pops up, it starts to happen more often. I suppose that’s what you mean with snowball effect?

Also noticed that when closing and re-opening both instances, the xrules preferences (midi input and osc port) of one of the current profiles are not saved. It just takes the presences of the other profile when re-opening. Even when updating the current profile before closing. This doesn’t happen when closing and re-opening one instance, while leaving the other open. Don’t know if this was also the case with your first preview. Don’t think I tested it.

The second “error” is not that big of a deal. But the second really freezes the tool and takes some time to fix. Besides these things, this tool does exactly what I want it to do. :slight_smile:

47

Thanks, I think I found the problem.

I did some tests while running multiple instances, but not while using the batch configuration file switcher - somehow it affected things.

So, actually using that I soon stumbled upon the same issues that you reported. Should be fixed now

Download:http://www.renoise.com/tools/xrules

While this is technically still a preview release, I figured it was time to push it the tools page.

Especially as the download contain a bunch of additional features.

First of all, it now receives and sends sysex.

I made the following rule to demonstrate how you can receive MMC transport (a standard feature on many keyboards) and use it to control the Renoise transport:

https://gist.github.com/bjorn-nesby/9ebb07af6896d8373c47

A little note on the syntax used to specify sysex values:

-- written as hexadecimal numbers (00-FF)
-- sysex must start with F0 and end with F7
F0 00 01 02 03 F7

-- use wildcard to indicate 'any value'
-- (here we match the third and fourth only)
F0 * 01 02 * F7

Also, internal routing between rules and rulesets is now possible. You can think of it as the xRules equivalent of the DSP Send Device

Here is a simple example, which takes any MIDI input and routes notes into Renoise while everything else goes into a MIDI output of your choice:

https://gist.github.com/bjorn-nesby/388b90863b11f9ec59cf

Edit:wow, I forgot one more important feature that I added yesterday: device hot-swapping. So now you should be able to plug in your controller_after_ having started the tool, and itshould automaticallypick it up and initialize everything.

All these new features are still quite rough and will need some further finetuning. The configuration switching thing, on the other hand, should be working by now…

Check it out, see if it has become more stable? I think you can still run into the occasional bug and my efforts will now be directed at fixing remaining bugs, not adding any more major features.

48

I did some tests while running multiple instances, but not while using the batch configuration file switcher - somehow it affected things.

So, actually using that I soon stumbled upon the same issues that you reported. Should be fixed now

Awesome! So far I haven’t stumbled upon any of the previous errors. Looks to be stable.

Thanks to this tool in can finally have the live setup I’ve always wanted. Hope some of these things can be integrated natively in a future Renoise version.

49

Awesome! So far I haven’t stumbled upon any of the previous errors. Looks to be stable.
Thanks to this tool in can finally have the live setup I’ve always wanted.

Great, that’s good to hear! Do share any gigs and stuff with us :guitar:

Hope some of these things can be integrated natively in a future Renoise version.

What I would like to see was that we could capture and process “internally generated notes”. Right now, we can send OSC messages to trigger instruments. But what if we had the opposite too - instruments that _generated_OSC messages? (could be specified just like choosing a MIDI output). That would mean that a tool such as xRules could also be made to work on existing pattern data, and not just the MIDI input arriving from an external source. Effectively, using OSC we could keep things “in the box”, and not have to rely on ugly workarounds involving MIDI loopback cables and whatnot.

50

A new version has been released, mostly fixing a number of bugs and finetuning some features

As usual, you can download xRules from thetools page.

Changelog v0.68

(fixed) xOscMessage - values not included when cloning messages for output
(fixed) xOscRouter - when using wildcard patterns, only first pattern was matched
(fixed) options: custom OSC devices were not correctly saved 
(fixed) with multibyte support enabled, pitch bend of 0 not transmitted
(fixed) error when an activity indicator is lit as new model gets imported
(fixed) when removing first ruleset, no ruleset is selected afterwards
(fixed) using device_name in condition could corrupt the rule
(feature) xOscDevice prefix should now be working
(feature) xRule/sandbox - access values in other rules 
(feature) shutdown (clicking logo) now closes devices - previously it just ignored input

In this version, there is finally some proper documentation for the tool.

It’s part of the download but also locatedhere.

Edit: good news for the next version - one of the most stubborn bugs has been squashed!

I just made an effort to safeguard against those stray error messages that can arise when you are switching between songs.

It’s tricky, because putting the safeguard everywhere would make the code absolutely bulletproof, but also slow down things. So I decided to perform this check as messages arrive, since a message can arrive at ‘any time’.

Seems to work, and this should take of one of most stubborn bugs - the kind which would only happen ‘sometimes’, and be hard to reproduce.

What I’m doing is to put a safeguard in as messages arrive. If we are in a limbo (with no Renoise song available), the message is simply ignored.

What’s nice about implementing it in this way is that we could possibly cache the message and output it once the song document becomes available. A bit like how a computer keyboard has a cache that allows you to press a button sequence even when the computer is not responding :slight_smile:

51

Version 0.72 has been released - download from the tools page

(fixed) missing reference to document while loading a new song
(fixed) no default message-type defined when converting from OSC (now using sysex)
(feature) high-res automation recording (use in callback, configure in options)

Since xRules can receive high-resolution data from OSC and 14-bit MIDI devices, it makes sense to be able to record automation of it’s own, instead of passing it on to Renoise. By default, it will record high-resolution automation in the time domain as well as the values themselves - you can control this setting and more from the new Options >Automation panel.

The following example shows how you can map an(y) XYPad with TouchOSC, for quick recording using the tilt sensor

https://gist.githubusercontent.com/bjorn-nesby/0be894c6940031710946/raw/53f2761209638d10b33add2a3e352c9fcd7fa4cf/TouchOSC.lua

The example above is making use of the newly added record_automation,has_automationmethods (link tomanual):

https://github.com/renoise/xrnx/blob/master/Tools/com.renoise.xRules.xrnx/xRules_README.md#methods