What is xRules?
xRules lets you rewrite and transform incoming MIDI/OSC messages on-the-fly, using a visual programming interface. Outgoing messages can be routed into Renoise, or passed on to external devices.
Why xRules?
The motivation for creating this tool was to create an environment in which it was easy to define some custom behavior and exchange this with other users (or multiple Renoise installations). Everything xRules does is described as a simple lua table, which you can save, export, import and copy/paste as you like.
Also, the tool represents the culmination of my efforts to streamline code from my library projects, xLib and vLib as well as Duplex. As a result, it has a pretty snazzy user interface and powerful MIDI handling (including NRPN, 14bit message support)
@ledger: Works here. Try again? (might have been a small server hiccup).
Oh, and I just noticed that, when the tool starts from a fresh install itās actually in a disabled state. You can see this, as the logo is crossed out. Once you add a few rules, it should enable itself (you can actually control this from the options dialog)
Also, donāt miss out on the small āsquareā button in the right side (toggle expanded/compact UI)
Wil turn into this (default, empty ruleset)
I really should make it so that, when the tool is freshly installed it will auto-expand once some rules arrive.
could this tool be used to record the note-event output of a midi generating plugin into the pattern editor?
Or perhaps send an midi-arpeggiator vst output to multiple instruments at the same time?
Hm, any lua tool only can pick up messages if they arrive from the āoutsideā = external MIDI. So, to capture such stuff youād need to set up a loop-back device. There is a miniscule amount of latency involved, would be interesting to see if this was in fact useful (I know some people have experimented with this).
But yeah, then everything xRules does would be possible, also with arpeggiators and stuff.
I would like to suggest a simple note counter that you can check and reset.
Also, is it possible the xRules processes already recorded and replayed notes just like a midi fx? That would be awesomeā¦
Also, this tool IMO is no excuse for the Renoise team not to implement a proper midi routing, like a feedback port, multiple routings by channel etc. danoise cannot workaround all missing features in Renoise basically
Also, this tool IMO is no excuse for the Renoise team not to implement a proper midi routing, like a feedback port, multiple routings by channel etc. danoise cannot workaround all missing features in Renoise basically
Counterargument: Iād prefer to see see such features maintained as add-ons and extensions so that a ) the core of Renoise is easier to maintain, and B ) these additional features can get improvements and bug-fixes independent of official releases of Renoise itself.
That said, there may be performance improvements or additional behavior made available if a feature is implemented in native code as part of Renoise. But unless thereās a compelling reason to roll a tool into the core it might work out better being an add-on.
Neurogami, I would agree with you, if the LUA api really was capable of precisely and efficiently doing such things like live note mangling.
There was a screenshot on imgur of the Renoise source in a devtoolsā¦ Donāt know url anymore. It didnāt seem to take advantage of a sophisticated class structure (like base dsp, inherited dsp etc), but seemed to have a quite flat structure. So maybe thatās the reason, why the team doesnāt seem to be tremendously motivated to make Renoise a perfect DAW? Maybe they should rethink the base concept first? Also must be a pain to do this for three OSā¦
Neurogami, I would agree with you, if the LUA api really was capable of precisely and efficiently doing such things like live note mangling.
Yeah, thatās the catch.
There was a screenshot on imgur of the Renoise source in a devtoolsā¦ Donāt know url anymore. It didnāt seem to take advantage of a sophisticated class structure (like base dsp, inherited dsp etc), but seemed to have a quite flat structure. So maybe thatās the reason, why the team doesnāt seem to be tremendously motivated to make Renoise a perfect DAW? Maybe they should rethink the base concept first? Also must be a pain to do this for three OSā¦
Itās amazing how a code-base can get complex and gnarly, even when you KNOW that code-bases tend to get complex and gnarly and you try to stay organized.
Sometimes a datastruct decision that made perfect sense at the time comes to bite you in the ass later.
It seems the listed input rules are way more specific than the output rules, excluding call_function. For example CC10 on chan15 with a value greater than 64 has a pretty limited output unless a specific lua function is coded. A more comprehensive/commonly sought list of outputs would be desirable- maybe sort of like lua āpresetsā, similar to how the pattern effect commands are selectable from the edit gui, not just entered via text. Also a handy way to copy and paste input and output conditions would be nice. In its current state the tool is great for 5 midi transformations, not great for entering/programming 125. Awesome tool though!
It seems the listed input rules are way more specific than the output rules
Having such a visual interface is mostly about being able to create a rule without having to consult a user manual each time.So, if I understand you right then really, all the tool would need was the existence of a custom input function, similar to the output function. Then we would truly have ābest of both worldsā. More than anything else, I want this tool to be_useful._
Speaking of useful: 125 transformations - wait, what? I guess youāre talking about some very specific purpose here. Would that be solved with an input / output function? Andā¦ mmmā¦ I guess those functions would need to share share variables among each other?
The tool fails to load on Renoise startup.
Linux Mint 17.3 Xfce
Iāve been without a linux machine for a while now. You just gave me a reason to install Mint
I would like to suggest a simple note counter that you can check and reset.
A note counter could be done simply by having a function which contain a counter (a variable). So, for each incoming note you could increase the pitch, etc.
But thereās a missing element (still waiting to get implemented), because you would easily end up with hanging notes - as the incoming note(offs) would not be the same pitch as the outgoing ones. So, to work around this xRules needs to have a voice manager, something which could automatically keep track of incoming notes, and - if they are triggering a voice - keep track of when the original note gets released. Even if you can pull this off in xRules now, itās obviously a task better handled by the tool itself.
Actually, the whole project started last summer as I was talking to a friend (drummer) who wanted to create a performance with a big element of āchanceā. Basically he could be playing an edrum kit and, for every note/strike, a different sound (random or otherwise) could get triggered. And while you can do this with Renoise and maybe commands, keyzone cycle and whatnot, itās not that simple if you need to output to MIDI hardware. And even if xRules can do this now, itās a question of whether the receiving end - whatever hardware that might be - will eventually choke on all those notes. I brainstormed a bit with Neurogami during the development, and he had experienced similar problems processing notes from a Kinect device.
So, thereās clearly some important stuff still on the TODO list, but I also wanted to release it and get a discussion going.
Also, is it possible the xRules processes already recorded and replayed notes just like a midi fx? That would be awesomeā¦
Well, xStreamdoes this. Similar approach, they even share much of the same codebaseā¦
Having such a visual interface is mostly about being able to create a rule without having to consult a user manual each time.So, if I understand you right then really, all the tool would need was the existence of a custom input function, similar to the output function. Then we would truly have ābest of both worldsā. More than anything else, I want this tool to be_useful._
Speaking of useful: 125 transformations - wait, what? I guess youāre talking about some very specific purpose here. Would that be solved with an input / output function? Andā¦ mmmā¦ I guess those functions would need to share share variables among each other?
I actually meant sort of the opposite. I think the output should have a broader palette of output presets. Custom is great and endless really, but perhaps some functions may get used over and over again. Manual entry vs selecting a stored preset and tweaking.
And i meant 125 rulesā¦oopsā¦, not transformations. If I have 4 conditions with a 3 action output and I want to apply it to another CC for instance, then thats another 7 steps to copy it. If I have to do that for 16 rules, it becomes very tedious. Copying condition groups and output action groups is essential. Again, manual entry vs copy/paste and tweak.
And i meant 125 rulesā¦oopsā¦, not transformations. If I have 4 conditions with a 3 action output and I want to apply it to another CC for instance, then thats another 7 steps to copy it. If I have to do that for 16 rules, it becomes very tedious. Copying condition groups and output action groups is essential. Again, manual entry vs copy/paste and tweak.
Sure, if you are doing something which is functionally similar many times over. But, you can always copy the file itself, itās just a basic lua table.
Perhaps you could take some time to explain the actual setup you are thinking of?
Also, I have considered to implement a āsend deviceā which could route messages to a different rule (or even ruleset). Pretty sure this would be the most flexible approach.
Sure, if you are doing something which is functionally similar many times over. But, you can always copy the file itself, itās just a basic lua table.
Perhaps you could take some time to explain the actual setup you are thinking of?
Also, I have considered to implement a āsend deviceā which could route messages to a different rule (or even ruleset). Pretty sure this would be the most flexible approach.
The simple-ish explanation:
Iāve made a Renoise template that makes the Arturia Beatstep Pro a 16 channel sampler/sequencer/groovebox. The sequence runs within the BSP. The editing of the samples is done via the BSP control mode, which effectively turns all buttons and knobs of the BSP into midi controls on a given channel- therefore 16 channels are available. So for instance the sequence of Drum Pad 1 is editabe via MIDI channel1 of the control mode; drum pad 2 is editable on midi channel2, etc. Sample select, vol, pitch, pan, lpf cutoff, lpf res, send 1, 2,3, lfo amount/shape/rate to send 1,2,or 3 are all of the editable parameters. The only real midi ātrickā is that the sample select has to run an incoming CC to the piz midi transpose(mapped via doofer) before hitting the sampler intsrument. (It had to work this way due to the BSP design) So transforming a relative CC to a note transpose for each specific channel x16 is the goal. This is simply one example that Iām currently working on.The template is pretty much done, but if I could create one using only ānativeā Renoise devices and not the piz plugs, that would be preferred. Most param edits are fine with midi mapping, but some work better with a midi transformer.
It is exactly functionally similar many times over, because each drum pad has a corresponding midi channel that adjusts certain parameters. I never thought of copying the file itself, and that is the best solution I think. An internal clipboard wouldnt be a bad addition either- if it is possible?
The send device sounds awesome! It would be like a doofer or macro of xrules! Thanks again for the great work
