when i select my midi controller (korg taktile) Xrules writes out this
That’s a timing clock message - haven’t added support for that yet, sorry.
But perhaps it would be better for the tool to ignore unsupported messages instead of throwing an error?
Changing the following line simply into “return” should do the trick:
Btw: the taktile showing up in xRules, but not in Noodletrap is indeed strange. But the tools are not sharing any code, so we need tolook at that separately.
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?
I’m using a command line tool I wrote to send OSC.
I just retried it. I don’t see the duplicate output for the TouchOSC example, but I do see double output for my own, which are essentially the same (respond to a specific OSC pattern).
Is there some setting that might have the side effect of a rule being invoked more than once?
I added a simple rule to the TouchOSC set and it to behaves fine. Seems there’s something about my own rule set that has rules getting triggered more than once.
I’ll poke around some more.
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.
results.
What is this syntax:
/space %n:bar
I understand up to the colon. But what is the part after the colon? What’s “bar”? How does that work?
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 0So, 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 %fI 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.
I like this. I prefer, for example, OSC of the form “/track/%n/pattern/%n/randomize” instead of the less-clear “/track/pattern/randomize %n %n”
Using the data-type specific wildcard makes it easier to understand what’s expected, too.
A follow-up on my “duplicate triggering”:
I created a new rule set, added a simple OSC rule that called a function to print a message. When I send the matching OSC message I see the message twice.
I then shut down Renoise and copied the rule set file into the “examples” folder, and renamed it to avoid a conflict. I edited that file to respond to a different OSC pattern, but left it otherwise the same.
I then restarted Renoise and imported that copied rule set file. I sent OSC for this copied rule set, and the matching function is only triggered once.
So, if I create a rule set via the GUI it seems to get triggered twice. But if created as a file and then imported, it works as expected.
It’s not the folder; I tried again, this time just copying the original file in place (and renaming and editing the OSC pattern) and then importing it. Works fine.
I wonder if the tool is reloading the rule set from file as well as having it in memory (or something) from being created via the GUI, and therefore it runs twice.
@Neurogami: thanks a lot for your detective work, it’s really appreciated! I have an idea about what could be the problem, looking forward to trying it out…
What is this syntax:
/space %n:bar
Oh, it’s quite simple - it’s a display name you can choose to assign to a value - if you want. Once assigned, xRules can use this name to present more intuitive choices e.g. in the list of aspects
MIDI become these display names automatically, e.g. when you choose a note message, ‘note’ and ‘velocity’ are nothing more than display names. With OSC, things are of course not so simple…
New version out - xRules v0.75
This release contains primarily a number of bug fixes for the OSC side of things, as reported by Neurogami.
It should now be much more reliable when cooking up rulesets in realtime, and not just when loading from disk.
Also, I’ve applied some polish to the MidiInput class, where NRPN interpretation had a few edge cases.
(feature) xTransport - extended control of the Renoise transport
(feature) xParameter - control parameters using relative MIDI messages
(feature) condition: show a text input when matching by string
(feature) conditions: compare float values with variable precision
(usability) when showing ruleset options (“more”), automatically select first active tab
(tweak) MidiInput no longer throws errors when receiving unrecognized message
(fixme) MidiInput: 7-bit NRPN messages - numbers were wrong size
(fixme) MidiInput: 14-bit CC with number #0 was treated as 7bit
(fixed) OscRouter: patterns without values match similar patterns with values
(fixed) OscPattern: “multiple rules responding to one message” - caching bug fixed
(fixed) newly created OSC rules either run twice or not at all
(fixed) maintain pattern/route mappings when adding/removing rules
(fixed) sporadic errors when removing rules/rulesets while receiving messages
thank you kindly!
I noticed one of my rules doesn’t work anymore in the latest update.
when message type not equal to controller change
and number between … and …
then output_message to internal_raw
In version 0.65 this works. But in the latest update I stop getting logs when adding the second line about numbers. Already compared the preferences.
I noticed one of my rules doesn’t work anymore in the latest update.
Thanks, this was an easy fix. I’ve done some testing and released a new version.
(fixed) numeric comparisons accidentally got broken in v0.75
(tweak) longstring support for clipboard export (more readable)
New release (v0.77) - including an example of how to do “parameter automapping”.
Here is the description of the new rule:
-------------------------------------------------------------------------------------
AUTOMAPPING OF DEVICE PARAMETERS
(and record automation, pass messages on to Renoise)
-------------------------------------------------------------------------------------
This ruleset will listen to a specific CC message (1, or mod-wheel),
and apply the value to the selected parameter in Renoise. All other
messages will be forwarded to Renoise (so, still useful).
Automation recording is performed automatically when the
parameter is automatable and edit mode has been enabled.
## How to select a target parameter
1. In Renoise, while the lower DSP automation lane is visible, the
currently selected parameter becomes the target
2. Else, we target the _first visible parameter_ of the selected device
in the Mixer tab (whether this tab is visible or not). This makes it easy
to provide a 'fallback' parameter, simply by right-clicking the device
Of course, mod wheel (CC#1) is just an example. You can change it to whatever you like.
just tryed v0.77 on linux:
usual upper case bug 
just change filename “vCellTextfield.lua” to “vCellTextField.lua”
is xrules good for this scenario?:
i have a processing.org osc server listening
just want to send some message
(for example signal follower output value)
to control visuals in processing
(some basic music visualisation)
just want to ask before going exploring/reading about xRules
Yes, the same bug you’ve reported before. Will fix it for all my tools, thanks!
As for what you suggest - not possible with this tool ATM. It’s processing external input only, not monitoring Renoise internals.
Not that I have some stubborn idea that it’s not ‘supposed’ to do such a thing. It just hadn’t occurred to me.
Obviously, something to consider for the next version
Ive bought Volca FM some days ago, amazing thing!
But it lacks velocity, or touch sensitivity to be right.
The way how you can solve it is mapping your midi velocity to CC41 on Volca FM.
In standard daw you can use tool that is called midi notes to CC from Piz. It is amazing because it transmits velocity for every note individually even if you play chords.
Renoise doesnt support this midi plugin (or midi routing to be precise) so ive mapped VELOCITY TRACKER into CC41 by midi instr automatization device. It works great for monophonic sequencing! But it doesn´t support polyphony sensitivity, if the notes are played in the same time, all notes have the same velocity.
Do you think that your tool can simulate what midi notes to CC from Piz does? It would be great!
I suppose that velocity tracker device doesnt work for every note individualy if they are on the same row.
Thank you!
xRules can’t make this a reality as it only cares about processing messages as they arrive.
But it’s absolutely possible using Renoise 3.1 - it does support MIDI routing
First, insert an instrument that listens for the specified MIDI input and add the midiNotesToCC as plugin.
Then, create another instrument which is connected to the MIDI output port and select that instrument as the target for the piz plugin (Plugin > Midi Routing)
I just checked, and it seems to work. Also, the midiNotesToCC plugin is clever enough to have a “thru” mode which send the note after the CC messages.
Thanks a lot!
But i cant replicate it.
I can insert MidiNotesToCC as FX plugin on the track or inside the plugin, not as a instrument
and i dont know how route it into the second instrument with the midi output.
Help me there please
and sorry for offtopic
I can insert MidiNotesToCC as FX plugin on the track or inside the plugin, not as a instrument
I think it’s supposed to be an instrument. At least, this is how it shows up on my system.
I downloaded the “complete” pizmidi_x64.zip bundle, using x64 builds for Windows, both plugin + Renoise - no sandboxing.
Ive unpacked the whole bundle and rescaned plugins.
Still didnt see Notes2cc in synth plugins just in fx plugins. When i selected it Renoise told me (didnt before) something like: “this plugin seems to be synth, restart renoise”
dont know what is going on but after restarting renoise its here and its working.
Thanks again
I am an absolute beginner to xRules and lua.
I want to convert incoming MIDI-CC #20 to NRPN to control the cutoff of my Prophet VS.
The attached script is recognizing incoming MIDI-CC #20 and sending a proper NRPN string. But unfortunately I can’t figure out how to pass resp. map the incoming MIDI-CC #20 value_2 to the NRPN MIDI-CC #6 value_2.
Can anybody help me?
Thanks a lot in advance.
I want to convert incoming MIDI-CC #20 to NRPN to control the cutoff of my Prophet VS.
I can see you’re splitting the CC message into multiple messages, to create an NRPN message.
I took a quick look, because the built-in NRPN message should be way more comfortable to use.
But it seems that (and this is probably what threw you off), there is a need to define the following
bit_depth = 14
(this really shouldn’t be necessary but also won’t hurt. In this particular case, it seems to make the NRPN message work as intended).
So the way I’d suggest it would be like this (3 steps)
message_type = 'nrpn'
bit_depth = 14
Of course, you could use the ‘set_message_type’ via the graphical UI too - the snippet above is basically just killing two birds with one stone.
If you need to change, scale values somehow, this can be done as simply as adding the following statements to the code snippet above:
values[1] = 200 -- Number: set to fixed value
values[2] = values[2]*2 -- Data: increase by x2
Splitting into the MSB/LSB parts are done automatically on output. In other words, the message is turned into this kind of message:
-- ### build NRPN message
-- 0xBX,0x63,0xYY (X = Channel, Y = NRPN Number MSB)
-- 0xBX,0x62,0xYY (X = Channel, Y = NRPN Number LSB)
-- 0xBX,0x06,0xYY (X = Channel, Y = Data Entry MSB)
-- 0xBX,0x26,0xYY (X = Channel, Y = Data Entry LSB)
-- TODO optionally, when 'terminate_nrpn' is specified...
-- 0xBX,0x65,0x7F (X = Channel)
-- 0xBX,0x64,0x7F (X = Channel)
Define which output port to use (‘set_port_name’).
Define the output method (‘output_message’ → ‘external_midi’)
Also, check if NRPN is enabled and that the desired output port has been enabled in Preferences > MIDI
Thanks a lot for your helpful advice!
The script is working perfectly.