New Tool (3.1) xRules

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!

The missing parenthesis is obviously a typo, thanks for noticing.

I will be back from a small easter holiday next friday, so if someone wants to test, please replace that ruleset with the version locatedhere)

Btw: that gist above is using the new output format, where multiple lines of text are declared with [[double square brackets]]. To me, this seems much more readable, and you can copy/paste functions without having to replace /n linebreaks. I have found that ‘mining’ rulesets for functions is quite useful, and this little change makes it so much easier…

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

Weird, are you sure you’re not mistaking number of invocations for the value itself (it comes with three parts) ?

Perhaps I have probably overlooked something… You know, TouchOSC sends out a constant stream of messages so it’s quite easy for a detail like that to get drowned out in all the noise. But while testing with my monome, I am pretty sure thatthis didn’t happen.

Edit: I just checked - if I disable tilt sensor (to avoid drowning in data) and just look for a basic pattern such as a pressed button, things work as they should.

Makes me wonder if you tested this with a similar source - TouchOSC on iOS?

Another thing that I would like to hear your opinion on (or someone else who works with OSC on a regular basis):

Right now, an OSC input pattern can specify the “pattern” and “values”, with the latter being able to use wildcards or literal values. It’s nice and flexible, but often, you also encounter a bunch of patterns that are so similar that it would be nice to be able to apply wildcards to the pattern itself.

For example, the TouchOSC layout called ‘Simple’ defines a number of buttons on the second page as having these paths: /2/push1,/2/push2,/2/push3and so on…

When pressing one of these buttons, the first value is set. For example

-- pressed 
/2/push1 1

-- released
/2/push1 0

So, while you could create a condition for each of these patterns, the xRules UI would get quite crowded. And even if we are talking about just 16 buttons, it’s a repetitive task that no-one would enjoy (as a sidenote, Duplex doesn’t have this problem, as we are using control-map files)

A simple solution would be to allow wildcards as part of the pattern (the path-like segment), and then capture whatever value is specified there.

-- capture button index and state
/2/push%i %f

I considered making it an asterisk style wildcard. But I think it’s good to be as specific as possible - the pattern above is specifying an integer value, so it wouldn’t accidentally capture a pattern like /2/push /more.

Another reason it’s good to be specific is that, with integer values xRules can improve response time by caching the results.

Hi,

when i select my midi controller (korg taktile) Xrules writes out this - ive deactivated my midi controller in renoise midi and ive enabled OSC - no difference.

btw.maybe this is reason why Noodletrap doesnt see my Korg Taktile?

g