New Meta Device : Weighted Value Mixer

Here’s my suggestion for a flexible new meta device, inspired by the ideas discussed in this thread.

Johann, I know you’ll be reading this, hehe, so let me start by saying that I really like your basic idea, but I firmly believe that it would be incorrect to have the weight/bias amount placed on the originating device itself.

We currently have the Key-Tracking Device, LFO Device, Signal Follower and Velocity Device. Adding the weighting function to each device may involve redundant/duplicate code to be maintained, not to mention any future meta devices that might appear. This would in turn add extra cpu/memory overhead to each device, just to support a function that many people may never even use. Finally, the design is not self-contained since there would be weights scattered over many different devices, and this would needlessly complicate the calculation of the final weighted value.

I believe a dedicated new meta device would be the most sensible option here. This would be more in keeping with Renoise’s proven and successful design, where we have smaller, specialised devices that perform basic tasks as efficiently as possible, and only when they are absolutely needed. Overall this provides the user with a more flexible and modular approach, while keeping unwanted clutter and overhead to a minimum.

Here is a device mockup that I have created in Flash: (give it a try!)

( In the real device it would not be possible to set the input values, since these would actually be determined by whatever modulation source is connected to that input. The input sliders are here just for your convenience while experimenting. )

We can see that it is almost like a reverse Hydra device. It has multiple inputs to receive the values generated by modulation devices such as the LFO Device, Signal Follower, etc., and these inputs are mixed together based on their respective weights, to finally produce a single weighted output value that is then connected to a device/parameter positioned further down the chain.

Since everything is self-contained in this design, calculating the weighted value is quite trivial:

// Input values in range [0.0 to 1.0]  
// Each input represents the current value/state of a   
// modulation device such as an LFO, Signal Follower, etc.  
inputs = [1.0, 1.0, 0.0, 0.0];  
// The weight of each input in range [0.0 to 1.0]  
weights = [1.0, 0.5, 0.5, 0.0];  
// To calculate the combined weighted output in range [0.0 to 1.0]  
sumOfWeights = weights[0] + weights[1] + weights[2] + weights[3];  
if (sumOfWeights > 0) {  
 scale = 1.0 / sumOfWeights;  
 output = ((inputs[0] * weights[0]) + (inputs[1] * weights[1]) + (inputs[2] * weights[2]) + (inputs[3] * weights[3])) * scale;  
} else {  
 output = 0.0;  


soon we can build a neural network with meta devices! :>>

hopes Db starts coding/scripting devices for 2.6 :)

Amen to everything, though I don’t see why the inputs couldn’t just be interactive sliders just the same, considering that’s how Renoise handles inputs otherwise. Why deny users weighable MIDI CCs?

This is for sure a great idea and also perfectly sketched (as usual from DBlue). But is this really something for Renoise 2.5?

Aside from the discussed-to-death left-to-right order restriction, i don’t see why not? With automated weight sliders it’d open for a wider range of control methods, such as XY devices driving more than 2 parameters.

That’s really up to you :)

I’m personally not in any hurry for this functionality, but it would be nice to have it some day. Mainly I just felt like sharing my thoughts after reading the earlier thread.

The device itself is obviously quite simple, and I doubt it would be much hassle to implement overall, but I understand 100% that you have more important priorities leading up to the official release of 2.5, so you’ll get no complaints from me if this one has to wait a while.

It would be nice to allow modulation devices to trigger script dialogs and vice versa, i think this might be doable with scripting it requires a few additions to the current API though.

With the possibility to upset some people, skip this for 2.5, its really awesome as is.

Save it for 2.6, 2.7 or something.

+1 on this… but as this functionality can be hacked together at a privative level with a hydra, I don’t see the need for it this release.

If the existing selection boxes aren’t already coded once and reused, this would be a good oppportunity to change that.

I actually mean that. I just looked at how many places the exact same option box combo sits. If that is not handled by generic code… I’d be surprised.

But yeah, granted, every parameter (of every device) would require buffers, some way to accept more than one input… I can agree to disagree on the desirability to have this overhead for the increased flexibility of not having to insert a device when you decide to change a weight, or have more than one device affect a parameter… but the hollow arguments and the switch and bait I’m sick of. I don’t even care about the features as much as about this half-assed babble. It’s like when someone says “murder is bad because it costs money”, I WILL argue that murder can actually be quite cheap, and that WILL to some people give the impression that I condone murder. As seen a billion times on these forums. Someone makes an argument, I refute it, and in 9 out of 10 cases the reply is NOT “point taken, but here’s another one”, but just page after page of the same BS in different words, with lots of ;) and stuff. Gah.

Well, that’s a matter of perspective I guess. For me the meta device would be the ass backwards way to do it.

To me “how much impact does this have” is something I would want to tweak while tweaking the LFO or signal follower it relates to… instead of just “what weighting device does that lead in to” (and then having to remember/separately tweak what device/parameter that weighting device affects, and which weight the LFO I’m currently working on has there).

Also, if it was done how I originally proposed it - why shouldn’t one be able to also view any “incoming” routings (plus weights) to a parameter as well? “this parameter has 4 devices affecting it”, with a popup to affect their weights and change the focus to those devices?

HUH?? That just totally depends on how it’s done. What a claim.

And another, kinda random note: it is not needed and not really useful to cap the weights at 1. They get added up and divided by their count anyway, and this way have more room for afterthoughts.

Yes :) …osc and surely the inclusion of some Arithmetic operator-meta devices (+ - * / %) will make this possible!

Geeks. The lot of you. :P

Firstly, I just want to quickly address this and hopefully clear the air…

I can’t speak for anything that happened in the other thread, but if you sensed any kind of hostility or conflict from me starting this thread, then please accept my sincere apologies, as I can assure you that was definitely not my intention. Having already programmed a couple of weighted systems like this myself, and making my share of mistakes along the way, I only wanted to share some observations about what stuff seemed to work best in the end.

Yeah, I’d be surprised, too. I wasn’t referring to that particular aspect of it, though. What I meant was, the weighting function could be considered as quite a specialist or exotic feature, since it’s probably not the kind of thing that every single user will have a need for. Even if the code to handle the weighting was quite generic, in my opinion it would still be more sensible to have a self-contained device that handled all of the weighting logic, rather than adding the same functionality to each individual meta device (and any other meta devices that are added in the future). The end result would be less code to maintain overall, with fewer potential places for new bugs to appear.

I have to say, I just don’t think this is the correct way to approach the problem. A parameter is such a fundamental core component of the system that any changes to its design should be handled with extreme caution. In a typical song with a lot of DSP devices there could be thousands of parameters in-use by Renoise, so it’s absolutely crucial for things at that level to operate at maximum efficiency. Any problems or unnecessary overhead introduced there could become exponentially worse as the project grows. Therefore, it would be overkill to make every single parameter of every single device more resource intensive this way, when it’s likely that only a tiny fraction of parameters in the song itself are actually using the weighting functionality.

A parameter should also not have to deal with anything beyond its usual scope, like whether or not it has more than one controller affecting it. By design, a parameter is pretty much completely passive, and is often unaware of things going on elsewhere. It simply represents a value that can be modified by the user or by a controller such as a meta device, but once a parameter change has been received it is up to the parameter’s parent device to decide what action(s) to take next, not the parameter itself. There should never really be a situation where a parameter is dealing with more complex logic, or looking back through the DSP chain trying to determine what is connected and how it should actually handle whatever it finds, etc.

Using your example from before:

Let’s keep in mind that a weight is only meaningful when used in conjunction with other weights, so at any given moment we need to have access to all the other weight values in order to perform the calculations. If there is no dedicated weighting device to provide data storage and handle the calculations, then at what point do the calculations actually take place? Is it the Filter that must work backwards to analyse all the possible meta devices connected to it, and then calculate their respective influence before updating its value? Is it the job of the LFO devices? Should LFO1 do a lookup on the Filter, figure out that LFO2 is also connected to it, then work its way around the DSP chain to do a lookup on LFO2 and fetch its values, then finally perform the weighting calculations and apply that value back to the Filter?

Do you see what I mean? When there is no device dedicated to handling this stuff, it suddenly raises a lot of weird questions about where and when certain processes should take place, which meta device is responsible for what and in what order do they operate, where should certain data be stored in order to remain accessible to other devices that need it, etc. It just seems like a lot of unnecessary logistical problems for something which I have already demonstrated to be incredibly easy to do - assuming the self-contained weighting device were to be used.

Well I can’t really argue with you there. All I can really say is that I have put quite a bit of thought into this, and it seems to me that a self-contained device would be the most logical and sensible choice, not to mention requiring the least amount of development time to implement.

I just happened to use the typical 0.0 to 1.0 range in my example to keep things clear, but the weights are ultimately calculated as relative values, so you’re quite right - they could be presented to the user as pretty much anything you want, as long as it’s a value ranging from zero to something greater than zero.

Here’s another demo to show the weights working as you’ve suggested. I’ve also spruced it up with some fake LFOs… two sinus LFOs types running at different speed, plus a random LFO, and a remaining slider for manual input :

I like the idea of having one separate metadevice for this. Keeps it clear and is good design imo.

Allowing for singal multiplication in addition to eh… addition would kind of solve my calc request…


fuck me you’re clever