Randy Note Columns is quite slick. It’s fun to play with, tweaking settings and note columns to get assorted results.
The code originated with OSC Jumper. One of the early experiments with Renoise OSC hacking was swapping track volumes. It worked.
There was another project going on (Beat Masher) that allowed for song manipulation from a phone app (Control). It was created to provide backing tracks for jamming; it was easier to twiddle values on the phone than using the Renoise UI directly.
That Control program allowed for about five tracks; pairing up tracks to allow for volume swapping (to vary things up) would be limiting. What would be better would be allowing for pattern variation within a single track. Hence, note-column soloing.
Meanwhile, back in OSC Jumper, code was added to allowing getting data back from Renoise. The idea is to send an OSC message to OSC Jumper that registers a timer function to send back an OSC message with assorted details (current pattern, BPM, whatever).
That lead to creating timers to swap note-column volumes.
A simple version worked fine, but to get the right results seemed to require some kind of UI. That lead to Randy Note Columns.
Once Randy was looking good, and the parameters understood, it only made sense to revisit that OSC API.
Here’s the thing: Every tool that exposes an OSC interface needs an OSC server, and that server needs a unique port number.
This makes life tough for OSC clients that want to make use of all those tools. Things are much nicer for the client if there’s is just one server to think about.
OSC Jumper knows about the built-in Renoise OSC server and will proxy OSC messages that begin with /renoise/. It would be a bit more trouble for Jumper to know about some arbitrary number of other OSC servers. It’s not impossible; just not maybe the best first choice.
Another (presumably better) option is to just have OSC Jumper handle all the OSC, even for other tools.
This allows for having a single OSC port of entry. It means core OSC code is stays in one place. (There are other ways of accomplishing a single source for OSC code but it introduces other problems.)
The first experiment with this was in having OSC Jumper load the files from the Rotate Pattern tool. (This was actually done for Beat Masher, but increasingly it feels that some tools are just minor variations on each other; another motivation to see about having a single OSC tool.)
It worked OK, though there was an interesting side-effect: Duplicate menu items.
In order to get the desired code from Rotate Pattern it was necessary to load its main.lua. The code there in turn caused the creation of another pattern rotate menu item. OSC Jumper has been updated to remove this duplicate, but it points up the value of splitting out behavior in Renoise tool files.
OSC Jumper now tries to load code from Randy Note Columns. You need to have that tool installed in addition to OSC Jumper if you want to use its features via OSC. Things have been compartmentalized so that only the code implementing the core Randy API needs to be loaded. GUI code, tool set-up code, that all lives in different files.
It’s still clunky. A file previously named Rotator.lua s now called Shared.lua but that doesn’t feel right either. It holds the code that attempts to load code from other tools, and if successful it adds OSC handlers. Aside from the name (the file isn’t for code being shared, it attempts to see if others will share) there’s, again, much duplication in the how files are acquired. Plus it mixes two things: snarfing other files, and implementing OSC handlers bases on those snarfed files.
As it stands it seems the most likely place OSC Jumper will be looking for code to reuse will be from other Neurogami tools. That means it could assume those files follow some conventions, such that there can be a more generic function for locating and loading external tool code. It might make sense to devise a naming convention such that any time there’s something new for OSC Jumper to grab it will automagically load the boaster files based on the file name.
When testing out the reuse of the Randy code, in interesting result surfaced. Note-column timers were added using OSC, but they were never cleared when using the Randy GUI. After a bit of puzzling the reason seemed obvious: Those are two separate tools that just happen to be loading the same files. However, all of their data exist are separate.
This is not a big deal if you know this to be the case. It has also kicked off a new quest: seeing how to share data among different Renoise tools.