Just signed up to ask for details about licensing MUC but turns out new users can’t send private messages
Any chance you can send me the details please?
Also - some constructive feedback: The 30 min demo timer + permanent lock feels to me to be too aggressive for something with this much complexity.
It has taken me hours so far to get my head around MUC, and I think I finally have a good idea of how it functions and can improve my workflow greatly, but it took a lot longer than 30 minutes (think multiple hours).
I know it’s difficult to find the right balance with this sort of thing to avoid people taking the micky but as a newer Renoise user (with a new MIDI controller) this felt somewhat hostile.
I am pleased to inform you that I have just released the new MUC v3.0 build 361.
You can download the MIDI Universal Controller tool in the first post, here.
This new version includes some more additions, some fixes and a very important feature: the parameter rerouting customization for instrument plugins. You can see all the updates inside the Update History.
Parameter Rerouting for Instrument Plugins
The instrument plugins are disparate, each offering an ordered, hard-coded list of specific parameters, each with a different range of values, where the infinite-spin wheels are the ideal knob.
The main control problem through the MIDI input is that it is not possible to modify the order of the list, being impossible to route the MIDI input to control specific parameters that the user wants, since their physical MIDI controller has limited physical knobs (several buttons, wheels…). The user has a physical MIDI controller with a limited amount of physical controls, and the instrument plugin can have hundreds of parameters. How to control all that, or at least the most interesting parameters of each instrument plugin?
The MIDI Universal controller, through the “Instr. Plugin” section, allows you to display an ordered list of all the current plugin’s parameters, in such a way that each parameter is linked to a virtual slider bar. Additionally, via the “Rou” switch, it allows each slider to be rerouted to any desired parameter, using the master slider. Here a simple example:
Example of the Tricent Plugin, with 93 parameters (8 rerouted)
This allows the MUC to be customized for each instrument plugin, so the user will only have to do their custom routing once, forever.
MUC will save each routing configuration automatically, so it works for any session or song project, without the need to re-route again.
The routings are saved in the ins_plugin folder. You can make a manual backup of this folder if in the future you want to recover all the rerouting settings of all your plugins.
Thanks to all the features of the MUC, it allows sophisticated control of a multitude of parameters even for simple and cheap physical MIDI controllers.
Tips for Buying the Best Physical MIDI Controllers to Control Renoise + MUC
Don’t buy physical MIDI controllers USB with faders. Faders (slider bars) have a limited range of values, from 0 to 127.
Don’t buy physical MIDI controllers USB with limited-spin casters. Like the faders, they have a limited range of values, from 0 to 127.
I am aware that with the two previous points I completely kill 90% of the USB MIDI controllers that are currently on the market, but that’s the way it is.
The ideal is to buy a MIDI controller USB that has infinitely rotating wheels (8, or 8+1 at least) and several banks to multiply the number of these wheels, (3 or 4 banks, or at least 2). This allows for direct 8x3 or 8x4 MIDI input routing. The infinite turning wheels have no range limitation, they can select each value within the value range of each parameter, being the ideal physical control for any DAW, especially if the user wants to control a multitude of parameters.
It is also advisable to to buy a MIDI controller USB with buttons to be able to press and release, which act as a switch. The pads should also be able to function as switch-type buttons.
If you have a MIDI keyboard or MIDI pad or MIDI controller and have not yet tried the MUC, you should!
Steps for Rerouting Parameters for Instrument Plugins
Turn “On” the MUC.
Go to “Instr. Plugin”.
Load a instrument plugin from the “Plugin Sel.” List.
Pres in the switch in “Rou”.
Press (simple click) the right button of each slider to change the selected slider to reroute your parameter. The index of Slider Master as changed (it is the index of current slider with a parameter).
Press and hold the right button of the desired slider to reroute the parameter of the the current slider preselected. Or use the Slider Master to change the parameter of the current slider.
Repeat these steps to each slider index desired.
Example of the Tricent Plugin, with 93 parameters (8 rerouted)
Do the same for the other desired instrument plugins. Each plugin will have an individual rerouting configuration xml file. This xml it can even be manually edited from a text editor. Save up to 1000 parameter indices (for each instrument plugin).
MUC will save these rerouting settings in the “ins_plugin” folder, valid for any song project. Thus the user will not have to waste time routing the MIDI input continuously.
This way, every time you want to start a new project, you only have to load the .xrnm MIDI mapping file once from the MUC when it is powered off (Dropdown List 4). Remember to expedite the use of these types of files. So in a single step of 2 clicks, you will have all your MIDI routing, even all the custom MIDI rerouting of all your virtual plugins.
Retrieve the original parameter of a slider
One last trick. How to retrieve the original parameter of a slider?
Just single-click the right button on the desired slider to select it. Then press and hold the same button. This will restore the original parameter.
In the MUC Preferences Panel there is a new button (below) called “Restart Routing” which allows you to restore all the original routings of all the sliders of the current instrument plugin.
I am pleased to inform you that I have just released the new MUC v3.1 build 369.
You can download the MIDI Universal Controller tool in the first post, here.
This new version includes some fixes and improvements, being a minor update, but no less important, since it directly influences the performance in the most demanding slider panels… You can see all the updates inside the Update History.
I am pleased to inform you that I have just released the new MUC v3.2 build 374.
You can download the MIDI Universal Controller tool in the first post, here.
This new version includes some fixes and improvements, being a minor update, but no less important… You can see all the updates inside the Update History.
Hey! I’ve been thinking of using this script but ultimately decided on making my own Duplex script, and I have some suggestions and feedback I’d like to make based on my experience in doing so!
Turn the sliders into tiny knobs (or ideally if possible, text boxes that display the value while acting as a knob. That way, you can still drag them up and down with the mouse, and ctrl for fine-tune. The sliders can’t be fine-tuned by holding ctrl and take up so much space, they don’t have to be if the primary purpose is to act as a visual indicator of position for an external controller.
The lack of dedicated volume and panning areas (knobs 1-8 controls the volume for tracks 1-8 and so on) is…strange. I can’t see myself thinking, “I’d rather be able to control volume, pan and RGB color values of a track rather than the volumes for multiple tracks”. It’s really cool that you could change the RGB values by the way, but similarly I’d like to control the volumes for multiple tracks when mixing.
Endless encoders are nice, but without a button to decrease the sensitivity of the knob by, likesay 10 times, it still has the same range limitations as standard MIDI CC knobs with a range of 0-127 do. They spin infinitely, but they still increase/decrease by 1s from 0-127. This is probably a limitation of Renoise’s MIDI-MAP, but similarly there also isn’t any acceleration. Endless encoders only have, for example 24 PPR (pulse per revolution), meaning that you’d have to turn the encoder clockwise about 5 whole revolutions to go from 0-127 currently. They still remain better than standard pots/faders in that their values don’t jump, but the lack of soft-takeover is the only reason why.
That said, I like reaching for my knobs cause they’re fast, not because they’re precise. Adding acceleration for endless encoders, and implementing soft-takeover for non-endless ones would make a huge difference. If you’d still have to stare the the screen to know where your endless encoder is, quickly moving the knob to the old position and changing from there isn’t a big deal compared to being able to precisely control the parameter regardless of how fast you’re turning it.
The lack of parameter rerouting for track effects (and optionally sample effects, but lesser priority) seems odd. They are more likely to fit within 8 parameters when properly rerouted, and Slider Master is only viable when using a single-fader controller such as the X-Touch One. Native FX don’t need this of course, but it’s nice to have for VST plugins.
I get the overwhelming amount of parameters in instrument plugins, but eight isn’t enough as you have said. There are a lot, Adding the ability to somehow have multiple routing configurations (or parameter banks/pages) for each plugin would make it truly viable beyond just assigning the sliders to the macros. Dexed for instance, you could have one config for each operator, letting you map 64 parameters and then some to just eight knobs. Do check out Bitwig, they do their parameter mappings pretty nicely. This also applies to track effects too; for a channel strip plugin you could have one config for the EQ section, another for the compressor and so on!
I hope this isn’t too harsh, I can see how much work went into this script and it pains me to see how much functionality it has while falling short of being usable in my book, especially given that this is a paid script. Currently MUC is a powerful, yet slow beast. If using the mouse is faster than using MUC, there’s no point.
Hi @HikoriHawky, thank you very much for your comments!
Most of your comments refer to “lack of speed”, but MUC already has a speed modifier (the top right dropdown “x0.75”… on the top bar). This allows you to speed up or slow down the scrolling speed of the knobs, for the physical infinite-spin wheels. Thus, MUC can be not only slow (accurate) but extremely fast, both. That being said, I will comment on each point separately.
I designed the MUC with sliders to be very similar to a track DSP effect device. So any user is more familiar. But it would be possible to switch to a display mode with value boxes, so that it would take up less space. But this would be a lot of programming work.
However, MUC is more intended for MIDI Input (control from your USB MIDI controller), but if you want to control the sliders with CTRL + mouse dragging, you can do so by activating the “Mouse warping” checkbox in “Renoise: Edit/ Preferences/GUI/Global”. Unfortunately, the API has no control over this.
In short, yes you can use CTRL + drag with the mouse (with Mouse warping).
This point is very interesting. In fact I could implement new dedicated control panels for pre volume, post volume, pre pan, post pan, for example. But why limit it to 8? These panels could load all bars for all tracks. I don’t promise anything, but maybe I’ll implement it later.
Your points 3 and 4. As I mentioned before, MUC already has an accelerator for the infinite spin wheels. Just use it.
However, the use of limited-turn knobs (0 to 127 values) is a physical problem, not a programming one. If you raise a fader upwards, there comes a time when it finds a physical limit (value 127), and the same downwards (value 0). Implementing a software decelerator here just wouldn’t work.
In other words, the faders and the limited-turn wheels (which are the same thing), are designed for value ranges from 0 to 127 values, with a precision of 1 if the range does not exceed 127 values, or with a lack of precision. (jumps) if the range is very high, for example from -1000 to +1000. Renoise, and the VST/VSTi plugins offer a multitude of parameters, some with very exaggerated ranges, where control with these types of knobs is simply not feasible.
In short, this is a pervasive problem for hardware component manufacturers, who still insist on including limited-travel sliders, and limited-travel rotary controls (0 to 127) in their MIDI controllers, when in reality these controls are that, limited. You’ll see that serious modern mid-range and high-end MIDI controllers claim to implement infinite spin wheels, because they are the true knob for controlling parameters of widely varying ranges.
I can tell you in another way. Most cheap (and some very expensive) MIDI controllers on the market are useless for true DAW control. It is best to run away from these MIDI controllers and only purchase MIDI controllers that have infinite spin wheels. I’ve discussed this several times on the forums, but I’m glad you raised this topic.
An example that I often discuss is how to select a specific instrument in the instrument box with a fader or limited wheel, if you use more than 200. Movement of the knob will cause index jumps if it is programmed to go from 0 to 255. It is a problem of physical limitation, not of programming.
This is a “sensitive” topic. Renoise’s native effects devices are limited to 35 parameters (if I remember correctly). Asking a user to reroute all of these parameters is really convoluted and a huge waste of time for the workflow (apart from the hassle of programming it). The reason is because the quantity is relatively small, only up to 35, and many of the devices the quantity is small. Therefore, it is best for the user to get used to the order of parameters offered by each effect device.
The point is, if the user really wants to control all the parameters from the MIDI input, they’d better have a physical MIDI controller device with a minimal number of knobs. For example, 8 knobs, without banks, would be a very limited number. The best are MIDI controllers with several banks, at least 3 or 4. That would already be 32 knobs (32 complete MIDI routings).
Another way to get around this is to use the master slider. In it you can simply select the parameter you want in advance and always use the same MIDI routing (with one wheel you control all the parameters). You need a previous selection step, but there is no other way to do it faster.
MUC has the ability to reroute all instrument plugin parameters. It also remembers them for later Renoise sessions. This is an extraordinary feature!
I’ve been thinking a lot about this topic. However, once again rerouting things is a huge job for the user. How many parameters would a user really want to control of an instrument plugin from the MIDI input? All? 8? 32? 64? As you increase the number you realize that it is unfeasible for a reasonable workflow. You probably just want to control some strategic parameter. In this way, you can reorder the first parameters in the list to control them.
Bringing up “multiple layers” of routing for the same instrument plugin sounds very interesting. But to be honest, the interesting thing would be if that use was offered to you by your USB MIDI controller through banks.
For example, the Akai MPD232 has 3 banks for its 8 infinite spin wheels. That’s 8x3=27 routings. For the user to memorize the 27 routings a bit in his head is already a feat. But being divided into 8 and 8 and 8 makes it easier to control. You just press a button and change banks.
In summary, in the end we want everything to be solved via software when most problems come from the hardware. The vast majority of the cheap or mid-range USB MIDI controllers on the market are just “sales devices”, not well-thought-out controllers to control a DAW, because there are hundreds of variable-range parameters. If the manufacturer make MIDI controllers with infinite spinners and lots of banks, 4 at least, but why not 8? And that this was the standard, we would not have so many control problems. MUC is intended to solve most of these problems (offer more control for smaller MIDI controllers). But it’s also about finding a balance between software and hardware, and trying to control all parameters from modest MIDI controllers isn’t a good path either.
That was quick, thanks for the detailed response! I’ll reply in turn.
1.
I had mouse warping off since I use a tablet, so that’s on me ww. Fair enough!
2.
The 8 track thing, what I meant was control of volume levels and the like in banks of 8, not only the first 8 tracks as most midi controllers with knobs or faders have them in sets of 8 (Either 8 knobs, 8 faders and 8 knobs and 16 knobs are the most common from what I could see). For the last two, you could have something like Vol + Pan as well for a standard mixer setup! For controllers with 16 knobs specifically, those (Arturia Beatstep for example) arrange them in 2 sets of 8, so it still matches up! Unless it’s those with 3 sets of 8 knobs (Akai MidiMix), then the last 8 knobs can do…I don’t know, sends too? Sends are an oddball in Renoise, so ehh.
Even if you could theoretically load 128 volume tracks sliders onto the panel at once, you could only control so much without needing a remap. Theoretically you could have an X-Touch + Extender combo or something that gives you even more than 8 slider/knob combos, but those are the exception rather than the norm. Really, it’s more of a workflow thing rather than a technical possibility.
Here’s an screenshot of my personal duplex script to show what that could look like: The page buttons (Pg.) here switch between track pages (selected_track_observable automatically changes pages too), faders mapped to the volume and the knobs mapped to panning (the GUI displays them as sliders, personal preference just for visual indication).
3/4.
The acceleration is for the endless encoders: turn fast for big changes, slow for precise changes. With the speed modifier though that isn’t necessary, thanks for informing me of them!
That said, I had no idea it was there until you mentioned it. I just saw “0.75x” on the panel, had no idea what it was for, and skipped it. Maybe that could be better labeled?
I still prefer standard knobs despite owning two controllers with both options, but I see the power now. Especially since the speed multi can be midi-mapped, that is genuinely actually really cool.
If I had to make a sugesstion though, again, an option to have a “slow” and “fast” multi as a toggle option would be nice, as it would make for a faster workflow and not all controllers have a 9th knob/fader that could act as the multi. Having to manually select a multi from a drop-down list with the mouse isn’t a viable option there.
5.
It is definitely a daunting task having to map each knob. Speaking from personal experience here, being able to control a whole synthesizer from the controller, heck, an entire VCV Rack patch, is pretty addicting. Lots of setup required for the sheer level of control you could have! Eight assignable parameters is still better than none though!
Having multiple MIDI assignment layers if supported by the controller is an option, but then you run the risk of having to remember which bank you’re in, which parameters are assigned to which bank’s knobs, and all the parameters you have mapped are displayed on the screen simultaneously. You’re still limited to how many layers your controller has at the end of the day. A more viable option to take advantage of them is to have, for instance, one layer handle Volume and Panning, and the other for other parameters according to what’s on the GUI panel.
An idea I had for my duplex script is to not only have parameter pages, but parameter banks that can have multiple parameter pages if needed. That way, I could have let’s say a parameter bank for operator 1, page 1 of the bank assigned to EG Level/Gate and page 2 handles course/fine frequency and so on! Done with that operator? Switch the parameter bank. Here’s a gif of my scuffed implementation of this idea; I had the parameter banks be assigned to buttons so I could have muscle memory remember which bank is assigned to which button.
Here’s an example gif of how the parameter mapping works in my script. The visual feedback of which parameters are assigned to a knob/slider is key in making this viable, no need to remember the routings here!
Exact. This is valid from the point of view of the software programmer. Get the user to have a fast workflow and don’t overcomplicate things for the user.
However, in practice, the hardware driver itself has a lot to say. If you only have an 8-wheel bench, this is certainly a limited driver.
It is possible to create a specific software program for a specific piece of hardware, intended only for it (and others like it). But when you think about hardware in general (USB MIDI controllers) there are many cases.
The opposite can happen to you. If you use 8 wheels with a single hardware bank (only 8 routings) and the software must switch to 8 parameter by layers, you are limiting the use for other hardware that brings multiple banks of 8 (eg 4x8=32 MIDI routings). It is certainly a complex issue.
Using 8 wheels/sliders by layers throughout the program could be an option, which can be turned on or off. And why not layers for 4 or layers for 16? Every user with their MIDI controller will want something specific.
However, everything is subject is very interesting. If you look at Renoise, it’s a program that’s clearly not focused on facilitating MIDI routing. There is no way to unify control, probably because the MIDI implementation was a later feature. No in-depth thought was given to these issues.
I guess that Renoise is more focused on automation. Do you want to automate a parameter to control it with a knob? Ok, pre-route it. But don’t route 100 parameters, because that’s not practical. And don’t switch tracks, because if you route the volume of track 1, it will only work for track 1. If you switch to track 2, you must use another routing. Really impractical.
MUC avoids all these problems. You route the tool once, get used to the order of the parameters, and you’re done. With Duplex, if you can program, you can tune it to your specific MIDI controller. But it will be of little use to you for other different MIDI controllers. You will have to create something new again.
Lastly, by treating only 8 parameters on the screen, you also limit the view of other parameters that are hidden (belong to another layer). To avoid this problem, there should be a GUI that could display all the parameters and at the same time a perimeter frame that would surround the groups of 8 parameters.
I’ve been playing around with this and can’t see a way to load a previously saved mapping file. Is that possible?
I’d also like to map MIDI controls to specific devices on specific tracks, but with some exceptions (master volume on the master track, for example) the tool only seems to action the track currently selected. Is there a way to bind mappings to track-device and have it work even when out of view?
Yes, Turn OFF the MUC. Find “MIDI Map”, select your previously saved mapping from the popup, then press “Load”.
Currently, the behavior of the tool is basically to pre-select what you want to control, and then use the knobs through your MIDI mapping.
It would be possible to design a tool that would allow you to pre-choose a particular parameter of a particular track to make it permanent. But we are talking about “tracks” which are a variable that may or may not exist. This makes this tool only useful for one song. That is, in each song you would need a reconfiguration (routing of specific parameters), extra work for the user.
I think you could build a new panel called “Custom Tracks” (or something similar). It would allow to pre-select a track and save the parameter, in a panel of 15 or 30 sliders. It would control 15 or 30 multi-track custom sliders, no matter which track you have selected.
With MIDI mapping, you can use a knob/fader to select the desired instrument (variable) or two buttons (permanent) to up or down on the instrument box.
