New Tool (3.1) xRules

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.

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.

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.

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.

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?

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.

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:

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:

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.

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.

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.

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:

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

I feel that this tool have the potential of becoming something close (and maybe more powerful) as Traktor’s midi mapping features, something I’ve been waiting for a long time! A simple thing that would make all the difference would be a “when x = 0”: with that option MIDI controllers like my launchpad pro would stay illuminated even if xrules doesn’t receive any signal from the controller! PLEASE make this happend it would be so great!

“when x = 0”: with that option MIDI controllers like my launchpad pro would stay illuminated even if xrules doesn’t receive any signal from the controller

I don’t really understand - what is x and why is it good to have it set to 0?
Now I am confused :huh:

I wasn’t very clear sorry!
By x I meant any variable like note/midi channel/etc. and what I meant about the “= 0” part was to implement an option in xrules like: “when [c#5] isnt pressed on input [Launchpad Pro]” to be able to output the abscence of an action.
An example: let’s say I want to have a play/pause button control. With such option, I could have a LED turned on even if the track is paused!
I dont know if I make much sense the general idea is to have a completely color coder controller even when no buttons are pressed.

Ah, that’s absolutely possible. Assuming that the LP will output regular note messages, it would be a question of looking for a note-on and note-off message, respectively.

Or in the case of CC’s, perhaps 0 and 127? So, we are probably not talking about an absence of a message, but rather a question of what exactly to look for (remember, you can always eavesdrop on this stuff using the Renoise MIDI console… ).

Also, I have a classic Launchpad myself and there, you can completely disable the ‘built-in’ visual feedback (flashing LEDs) and stuff by pressing a special combination. Not sure if this is the case with the PRO model, though. But otherwise, I can’t really see a reason how you would want to keep a light turnedon, if it was not lit up in the first place.

But - before you go ahead and build an entire LP Pro control surface in this tool, I should probably tell you that the technology powering xRules will eventually be portedinto Duplex. And that_tool is based on the idea of having visual feedback and building entire “applications” around it - from bread and butter stuff like automapping mixing consoles to quirky sequencers and more. Because, with a grid controller you very quickly go into territory where you would want it to do more than lighting up the button you just pressed. And while it is theoretically possible to recreate something like a game of tetris in xRules, I wouldn’t recommend it ^^

For me personally, xRules is fitting a niche that I found was missing, and at the same time, for budding scripters is an awesome way to test stuff without having to create a whole tool for just a few lines of code.

Added an example of how to use Mackie Protocol with xRules:

https://gist.githubusercontent.com/bjorn-nesby/7a6d0ba2a0ed5bdeb5a9/raw/ecbde26bbc286376cbe1ee1936e04b6d5bf00930/Mackie%2520Protocol.lua

The example was tested with iCON iControls, and features basic control of mixer tracks 1-8 (volume levels, mute/solo) plus master track (9th fader)

But - before you go ahead and build an entire LP Pro control surface in this tool, I should probably tell you that the technology powering xRules will eventually be portedinto Duplex. And that_tool is based on the idea of having visual feedback and building entire “applications” around it - from bread and butter stuff like automapping mixing consoles to quirky sequencers and more. Because, with a grid controller you very quickly go into territory where you would want it to do more than lighting up the button you just pressed. And while it is theoretically possible to recreate something like a game of tetris in xRules, I wouldn’t recommend it ^^

I understand. This is very exciting! I can already imagine the possibilities! (And yes the Launchpad Pro can disable internal LED feedback like the regular Launchpad)

Very very slick. I just started playing around with out, trying to understand the OSC part.

I have examples that react to an OSC message, but the associated function gets invoked three times.

For example, if you uncomment the rprint in the TouchOSC example, the values get printed three times (in the scripting terminal window).

BTW, there’s a typo in that script, a missing closing paren on the line with :

x = xLib.clamp_value(x,0,1)

Very sweet tool though!