Instrument modulation concept

Ideas & suggestions
161

Just to get it out, as I couldn’t see it mentioned before:

How about instancing modulation devices [copy > paste as instance]? Then some or all devices of a chain could be instanced to modulate something else and new uninstanced devices could still be inserted between them. Editing an instanced device would change all other instances (and the original) so things would keep in sync pretty well. Right click on a device could show all the places where that instance is used.

Not sure yet if working idea, just throwing it out.

Modulation matrix ideas are nice!

162

NIce! I like it

The advantage with what you suggest is that it can be applied across modulation sets and as KURTZ said it fits the established pattern matrix workflow. IMO the key is to keep it simple, I like where this is going.
It makes me think about how you would handle any existing mod chains that are over written, could these be blended or merged?

163

Yes, the modulation matrix allows drag & drops for all sets. But Imagine that you first select “one instance” (for example, a HADSR device) located in a chain, and then, you drag and drop it, in the modulation matrix on a slot in another modulation set. This “instance” of the HADSSR would be copied if the target location is empty, its parameters would be “merged”, if something identical allready exists, or it would overwrite a previous instance.

A switch button could define what to do : “mixing” source & target values, or overwriting them.

Concerning redundant sets / slots, I suppose that there will be a nice guy that would code a LUA tool, for converting “similar slots” into aliases in just one click, or to convert aliases into independant slots.

164

I’m sorry for being a bit late, but I’m having some health issues and actually shouldn’t be in front of the screen at all. Anyway, since I already announced this, I wanted to put this up. Won’t be able to respond to feedback afterwards. Just so you know. I hopefully didn’t forget anything important :-S

The idea is as simple, as effective and provides a huge flexibility, the extended way even beyond usual modular concepts, because it would offer complex setup modulators as single abstract elements. All within the current GUI.

The elements of the modulation setup, that are available in all target areas, are the basic modulations (AHDSR, Envelope, etc.). So there is actually nothing more logic, than making potential modular modulation elements, once applied on some target, a - modulation set related - part of these basic modulations and make them this way available everywhere else in the modulation set.

The initial idea:

So the “MyBlabla”-thingies contain the individual parameters of the device, applied somewhere on the origin target.

Three important points to consider here:

  1. Multiple usages of a modulation within a modulation set refer to the exactly same, exclusive modulation device. Changes on one usage affect all others too.
  2. On the first call of a modulation (per calculation cycle), the calculation is performed and the results are stored. Every following call directly delivers the stored results only, without performing a new calculation.
  3. References to modulations are only available within their related modulation set, to keep saved modulation sets consistent.

Maybe there could also be some indicator, which targets are affected by changing the device parameters. I personally don’t think, that would really necessary, because the are only a few targets anyway.

Well, that’d actually solve most of the non-modular issues. Still it’d keep things kinda uncomfortable, because you can’t set dedicated ranges or operands with the single modules, can’t share modulations with modulations on multiple targets, etc…

The extended idea:

The extended idea is keeping everything like it currently is, and extend it by a modulation wrapper in the basic modulations. I’ve called that wrapper “Modulation Subset”. New Subsets can be added/deleted to a Modulation Set by simply clicking the “+/-” in the browser. Imagine Modulation Subsets it like a Doofer for modulations and/or a modulation setup for an abstract target. Though Subsets won’t need any macro buttons, because they’d have to be bound to the instrument macro anyway and therefore are redundant.

r3modpic3.png1385×124

Example of an (opened) Subset usage on target “Volume”, combined with a “normal” AHDSR.

The expected behavior of Subsets would be exactly the same, like in the initial idea with applied modulations.

  1. Multiple usages of a Subset within a modulation set refer to the exactly same, exclusive Subset device. Changes on one usage affect all others too.
  2. On the first call of a Subset (per calculation cycle), the calculation is performed and the results are stored. Every following call directly delivers the stored results only, without performing a new calculation.
  3. References to Subsets are only available within their related modulation set, to keep saved modulation sets consistent.

Furthermore Subsets are able to modulate themselfes and other Subsets (within the same Modulation Set).

EDIT: And of course I forgot something important. :rolleyes:

Usage of a strict modular concept: Use Subsets for everything.
Usage and keeping of the current concept: Just ignore Subsets.
Usage and mix of both mixed: … explains itself

  • The Subsets would also make Bracket Devices obsolete.
165

Hey Bit_Arts, thank you very much to take time to deliver your ideas with mockups, while you have some health issues, I hope you’ll get well soon. Indeed I would never be able to “guess” exactly this idea, without any mockups and subsequent explanations.

We previously focused our thoughts on the upper section of the modulation panel, introducing a “modulation matrix” where elements are considered like “slots”, that are easily managed by simple drag & drops & shortcuts for specific behaviours…, we also introduced the idea of “slot aliases”… good, but indeed, we totally forgot to think about aliases for modulators themselves, through this bottom window :

… it looks also very simple, and very elegant, to let users create their specific parameters in each modulation “type” and let them reuse their MyMODs everywhere later on ; if users modify their original MyMOD, each instance of it used later one on sets where they’re placed would be automatically be affected ; truely, the “alias logic” is also there. The most interesting thing is that this idea perfectly completes the ones that some of us suggested here yesterday, about the way to use modulation sets like we allready use the “pattern matrix”.

Because for example, you could populate sets by dragging and dropping the MyMODs or Subsets, directly on empty “modulation matrix” slots. With shortcuts, we could have the ability to overwrite, or add, or “merge & create a new subset”, when dropping. And once you use the upper panel you should “populate” the empty slots with drag& drops, ctrl+shift drag&drops, things like that.

As one of us suggested before, using colors & numbers should help us to have a better “overview of the slots of modulations matrix”. So while clicking on a slot (for example, with the middle mouse button), we could define its color. And all the aliases would have the same color and a dedicated number.

166

Thanks for taking the time to come up with this concept, Bit Arts
Flexibility, but it isn’t forced upon us :slight_smile:

And it brings something new and useful to the table:

The Subsets would also make Bracket Devices obsolete.

In case anyone is wondering what a bracket device is/could be:
http://forum.renoise…before-add-sub/

167

Any news on this?

168

If we look at Bit Arts’ basic implementation (the initial idea), it is about making aliased devices possible:

[quote=“Bit_Arts, post:164, topic:40050”]

  1. Multiple usages of a modulation within a modulation set refer to the exactly same, exclusive modulation device. Changes on one usage affect all others too.
  2. On the first call of a modulation (per calculation cycle), the calculation is performed and the results are stored. Every following call directly delivers the stored results only, without performing a new calculation.
  3. References to modulations are only available within their related modulation set, to keep saved modulation sets consistent.

So, to actually use this feature we could

  • Drag a device into any modulation set (a row in the modulation matrix)
  • Right-click and choose “Alias this device”
  • The device now appears under Aliased Devices in the device list (E.g. “MyADHSR”)
  • We can now insert it into any other domain (volume, pitch, panning etc.) in the same modulation set. It can be inserted before or after any existing device(s) in that modulation set
  • Realistically, I would want to add a macro assignment - after all, what use is an alias if it isn’t meant to be changed?
  • In any way changing the original or aliased device parameters will affect all devices - including MIDI mappings and macro automation
  • Changing the focus to another set will loose the reference to the aliased device (it is removed from the device list),but the device itself remains in place
  • Deleting the source device will unalias the aliased devices, but not delete them (?)

This is how I understand the basic implementation, with a few additions :slight_smile:

But - for aliased devices to appear only in the same modulation set seems like a big limitation. Many instruments designs needs multiple modulation chains, all talking together.

As I read the post, the single-set limitation applies to the extended idea too. Maybe I don’t completely understand the concept after all, because it seems like a rather odd technical restriction to force upon users. Edit: restricting to the same set would also make such a set self-contained, easy to load/save as preset. So not purely a technical limitation, I guess.

169

Deleted - ill timed.

170

I just want to applaud the devs here for sticking with Bit_arts here and treating his request and red flags with respect from the start… Not to mention huge kudos to Bit_Arts for sticking with the devs and plowing through the trolls… that was painful shit to read. Glad you stuck around with us here, bit. Ignore the trolls. search “willingness to opine” on google images if you need a laugh :)

my only question… how the fuck did you get your hands on a beta w/o having to pay for an upgrade like I did? :blink:

171

I would like to add the following to a revised sample modulation concept:

  • Possibility that each voice can influence each other using simple math calculation like multiplication (sophisticated ringmod), subtraction (like subtractive synthesis)

  • Possibility to retrigger/restart a loop or from a sample position: Introduction of modulation target “sample position”, so I can control the sample position of one voice by using another voice (leads into nice sync modulation)

172

this isn’t really true. if you used a modular synth with patch cables you can only direct one signal to another, unless you 1st plug into a multiple. now, if you’re using banana cables that works more like how many software programs are. imo, i like multiples because they help keep things organized and you can quickly re-route many signals instead of recabling each one. i love multiples i have as many multiple as modules. ;)/>/>/>

doesn’t hydra work just fine? what am i missing?

modulate hydra’s input with an envelope and then direct any of it’s 8 outs where ever. to make them slightly more fancy it would be cool if you could throw some math on them to process before going back out. things like invert, half, double, rectify, etc.

ETA: oh i see, 1st time messing with this in 3. you can’t choose hydra with the doofer stuff. well hopefully, they’ll add that. in the mean time, can you can choose something that can target hydra? gonna try now.

ETA2: wait no, yes you can. lol. what is the issue then?

ETA3: oh the instrument editor! haha. isn’t the easy way to “fix it” to make it work like the effect chain? imo the problem is the inconsistency. unipolar/bipolar switches should be on each, both should have meta controls, etc. whatever though. seems like much ado about nothing…back to using renoise.

173

Back. :) Was curious, what was meanwhile going on about this topic. :D First of all I really hope, you’d rather consider to implement the extended idea instead of the initial one, because compared to simple aliases the Subsets enhance things a lot.

Of course I’ve also thought about global valid modulations. But since the whole concept is based on (sample-related) modulation sets, there is no way of keeping these things concistent and independent, when going global within the same set. It’d of course absolutely make sense to provide global modulations and I’d really like to see them implemented, too. Just not as part of sample-related modulation sets. Just to remind, that’s btw a “problem” (I’d actually not really call it that), that already existed with the origin R3b-modulation concept and nothing that comes up with changing to some new concept.

Global modulations should, if really considered, follow a strict concept of allowing the modulation access only one way: “global modulation set → sample modulation set”. Everything else will most probably end up in a huge mess.

174

Global modulations should, if really considered, follow a strict concept of allowing the modulation access only one way: “global modulation set → sample modulation set”. Everything else will most probably end up in a huge mess.

Yes, this is the biggest challenge with any truly modular system: you can’t just selectively slice away a part of a system in which things are inter-connected all over the place, and expect it to work afterwards. Saving a “template”, as it was previously suggested, isn’t really a proper solution to this. I mean, it sounds good in theory but I think it would be frustrating to use in practice (rigid at best).

A much simpler and clean implementation is what we already have - provide the ability to save and load presets, all limited to the current set - this is conceptually a lot easier to understand and work with IMO.

So, I am actually not very enthusiastic about the idea of aliased devices - I mean, the “current set only” limitation make them seem kind of irrelevant to me. I can definitely see the advantage in some cases, but nothing that couldn’t be achieved in the current system with just a few extra seconds of copy-paste. And the alternative - making them work across modulation sets - really seems to open a Pandoras box of complexity, exactly what I think we should seek to avoid.

The idea of subsets, on the other hand…this is really great stuff, and gets a big +1 from me. It is exactly the kind of reusable, shared type of “building block” approach that we can all benefit from.

If we focus on this, instead of aliased devices, we would also avoid to have ugly choices like “what should happen when aliasing a subset - will it then be limited to the current set?” - instead, it could simply go into any set, whereever you wanted - exactly like a Doofer :slight_smile:

175

This has nothing to do with modularity. The current system neither has global modulations. You’d face the exactly same “problems” (which aren’t problems), when you’d introduce global modulations to the current system.

You’re not getting tired of repeating the same nonsense on and on and on. There is nothing clean and simple with the current implementation. In best case it is from a coders point. What you have, compared to the voice architecture of any common sample payer, is a most redundant and idiotic concept, that makes the worst possible solution the default solution.

How about fiddling with some architectures from other sample players? The limitations to a single set don’t make aliases irrelevant, just because you personally don’t know what to do with it.

Yeah, let’s add another device working redundant. Sounds like a reasonable solution for redundancy issues.

Uhm, but that’d “forget” the actual point of the whole discussion: the redudancy, technically as much as from the usability point. We’d just have redundant Subsets instead of redundant Modulation Elements then and the whole discussion would have been pointless. There’s actually no way around Aliases, no matter how they’re called in the end.

The important point is to understand, modulations have to follow a hierarchy:

Global modulations set → Sample Modulation Set → Modulation Subset (on same level as Sample Modulation Set)

Modulations in general can only be applied to parameters on the same level or lower and are not allowed to affect prior modulation levels. That’s actually all to understand.

Edit: I’m still not sure, if someone is only playing stupid here to avoid changes to the code or if he just is that stupid. I’m out at this point. Enough time wasted for nothing.

176

i agree totally here. for what does Kontakt exist? i always read things like “renoise is a sample mangler” or “renoise is a sample based tracker”. why does it support vst then.? i suggest to focus the professional needs instead of playing with Doofers. these are funny toys, nothing more…

177

Yeah, but I don´t have anything against doofers i love them as i loved combinators in reason. They doesnt conflict with my “request” anyway.

178

Kontakt unfortunately only “exists” for specific OS. Despite, if you would skip everything from Renoise that already does exist as third party VST, what exactly would be left then? I don’t really get that point…

179

How about fiddling with some architectures from other sample players?

Most samplers I’ve had experience with are based on a hardware tradition - containing pre-defined modulators (AEG, LFO, etc.) that can be assigned to various aspects of the sound. However, the modulation system in the new sampler allows you to combine unlimited LFO’s (or any other modulation device) and make them affect each other via multiplication, subtraction, etc. It’s a different kind of system altogether, not trying to reproduce features of hardware, where you most likely will have a fixed number of modulators. You could call this approach “software native”.

But, that’s also why I like the idea of “global aliases” - they would promise to deliver this familiar functionality, albeit in a different (more powerful) sort of way.

180

A very professional discussion we have here. “Idiotic”, “playing stupid”, “professional needs instead of toys”. Helps a lot to convince people to your point of view.

I personally also don’t really mind the redundancy here, because macros are able to control more than one parameter and thus can compensate this in most cases nicely. The enforced uniqueness of devices does on the other hand avoid too many indirections.

What we have now is indeed a very uncommon approach and it also has its limitations, yes. Instead of connecting a set of “loose” modulation sources to some loose targets, you’re setting up sources for a small set of specific targets.
You guys pointed out the disadvantages of this approach in the past 7 pages of this discussion, no need to repeat that, but the advantage of this is that you always have an overview of what happens and thus also full control over how exactly a target is modulated. You can see in “one page” what exactly influences and builds up the entire modulation for e.g. volume. In an “open system” this might not be the most flexible system, but definitely one which is manageable. And I clearly prefer manageability over redundancy and even flexibility in this special case.

If we can extend the current system in an easy way with such global modulations, then yes, sure. But I don’t see why redundancy is the most important problem to solve here.

What I’d like to see instead (again very personally) are a few things which simply are not not possible with the current system, like cross modulation of devices (e.g. controlling an AHDSR’s attack with a keytracker, an LFOs frequency with an LFO and so on). The current system does not allow this, but this does not mean that it’s not possible to extend it to allow such things. Shouldn’t we concentrate the discussion more on that instead?