Yes! This would be great…
I have created something which works pretty well as a per-phrase envelope using 0Exx command (envelope offset).
pleas see this report of a small bug which has a demo inside
If the devs hadn’t kept all of these things a secret from the beginning, maybe we could have TOLD them about possible problems and they could have avoided them?
I really don’t understand what’s happened to the direction Renoise is going; what is the purpose of the devs spending years working on things without even asking their users if they want them? Why would it have been so hard to just put up a list of potential improvements and let registered users vote for the ones we wanted the most, and also DISCUSS possible problems they might have? It’s crazy.
I am also thinking about moving to FL Studio, and taking advantage of the end of year sale. Looks like Renoise devs are turning into the Microsoft of the tracker world - just bring out whatever you want, without asking your users, and then look on in wonder as sales plummet…
Hear, hear. The interface should only use the mouse when absolutely necessary, the whole workflow could be dramatically improved if keyboard shortcuts were more obviously displayed in the interface itself (by choice, of course, so you could hide them if you didn’t want them, or had learned them) - who can remember 100+ keyboard shortcuts?
Have a look at Schism Tracker, an updated version of Impulse Tracker - THAT is how the keyboard should be used. You can use the cursor keys to move between fields logically, etc.
Almost all the new stuff in Renoise 3 is of no interest to me whatsoever, I just want the interface to be improved, which should have been the easiest thing to code, yet it’s just being ignored.
It’s probably because renoise developpement is not a democratic process, but a “I do what I can” process. I don’t really share points of views, about the idea of a devteam totally ignoring people here and working like autists. The problem is not to collect opinions, about the ideal tracker. The problem is that the ideal tracker “that everybody likes” isn’t that easy to code. Devs and the alpha testers, they probably know what you want. But the question is : are they able to do what 99% of the userbase wants ? (assuming that the userbase wants something coherent that works on a long term basis). We would be 1.000.000 to be okay for just one feature that we voted for, the number isn’t that important if, anyway, nobody can code it and make it work without causing new problems from another point of view.
I keep in mind that, in a true democracy, when the elections are won, your favourite politician never does what’s been promissed before, anyway. Democratic opinions are like “wishes sent to Santa”. And, in the end, Santa does not exist, Santa gives what he has, and does what he can do, no more no less.
Please, let us not derail this topic into political discussions, or anything that does not explicitly deal with the modulation concept in Renoise?
I was challenged to explain why I felt that the proposed system, with a more “modular” approach to modulation chains, could be a good and a bad thing.
Now that I’m back from vacation, I have the time to actually do so.
The first example I would like to highlight is the 303 example by Bit Arts. This is pretty much the perfect case for a modular system, in which many aspects of the sound are shaped by an identical envelope.
Now, from what I can gather Bit Arts is resorting to the same trick I have been using in some of my instruments - that is, to add two faders in order to achieve a steep exponential curve.
I was talking about how I would like to see development focus on improving the existing modulation devices, and perhaps adding one or two new features as well? In this case, the missing ability to control the slope of the curve means that the number of devices are effectively doubled!!
So, I would very much like to see the fader have a seamless control of slope shape (going from almost instant to linear, and every possible shape inbetween) - this would reduce the complexity of the 303 instrument by a large amount.
Next example would be the Drawbar Organ instrument that I made for the factory content - it is a multi-sampled sine-wave instrument with a total of 8 stacked layers, where each layer can be individually controlled (volume only) via macros.
Now imagine such an instrument with 6 layers, instead of 8, and the last two macros would instead control something like attack and release?
With the current system, it would be a question of assigning the attack/release macros to each of the six layers (modulation chains), and a volume macro for each of the chains.
With a modular concept, you would do things a little differently: instead of having six different modulation chains, you would create a single modulation chain that was used for controlling the attack and release, and then you would assign/alias that “master chain” to each of the layers and finally assign each layer’s volume macro to each of the aliased chains. And in order to visually separate the master chain (containing the attack and release assignments) from the aliased ones, you would somehow need a special place in the gui to represent this chain.
So - with an instrument like this, you would introduce conceptual complexity (aliased chains), as well as GUI-wise complexity.
So, essentially I’m standing on the fence. I think each approach has it’s advantages and disadvantages. I have been thinking about different approaches, such as introducing a modulation “send device”, which would basically allow you to specify a target chain within the instrument. I think such a solution could provide much of the flexibility we need, without cluttering the interface. But we need more cases to study, I think.
The bottom line is, that everything you could do with a modular system, you can also do with the current system. In some cases, it would require more work, in some cases, less.
And I think we should focus on improving what we have already got - it’s close to awesome, but not there yet.
I proposed send devices during alpha stage but got response from no one. I think that this would be a fundamental addition, together with hydra Which would allow for multiple sending
Of course, a general modulation chain which modulates all destinations would still be the best solution in addition to the current system.
It could even work as a “virtual layer”: everything you put in the general modulation chain is added after each modulation set, acting as a multiplying modulation set
Bit_Arts:
Btw. maybe u-he would laugh but other synth developers often use one envelope for volume, second for filter and third is for pitch. There is usually mod env that can be assigned (like lfo in renoise) but the modulation matrix is not a rule so i dont see anything embarasing about current setup if i think about it. I often prefere more simple synths like charlatan than beasts like zebra.
If the doubled envelope is dropped, there’s still a redundancy of 300% in the current system. If other params (pitch, pan) were also bound to the same envelope, it’d be 500% redundancy. Of course you know that. You just forgot to point that out, I assume.
You’re either trying to kid people who don’t understand what you’re talking about, or you didn’t understand a proper working concept yourself. Let me say it that way: You made the “worst of all cases” the default solution in the current concept. There is no case, that has to be setup with more effort in a modular concept. No matter what case you make up. In worst case it’s the same.
No. The current system has only disadvantages and not a single advantage. No matter how often you keep telling something else.
There is still NO CASE, in which it would take more work in a proper concept. Seriously, are you lying here by intention to confuse clueless ppl? And if not so, I can only advise you guys even more to let someone setup a system, who’s knowing what to do. The current concept shows, you guys didn’t know what things are about and your suggestions and thoughts I read here do the same. Sorry.
Because you can’t handle complex setups, you want everyone else to give them up. The concepts you’re refering to are from the 70s and in best case early 80s. It’s 2014! A complex system still would allow you to setup simple solutions.
@Bit Arts: what about the alternative solution I proposed? A modulation send device would basically be analogous to how FX chains work, and not require the extra abstraction (the process of assigning generic chains to specific targets), unless needed. You would basically have the same functionality, though (reusability, less redundancy).
A flexible system allows both to setup complex & simple solutions. We know that the most flexible modulation system is a “modular” environnement, based on typical modules, with sources & targets, that you link together with virtual cables. I’ve never found something more flexible. With that paradygm you can get simple schematics used in simple projects, or very dense and hyperstructured multilayered schematics used for very complex signal processings.
The question is : how and what could we “change” in the actual modulations sets to be closer from this kind of modularity ? And are we so far from it ? We must have “realistic ambitions”. I don’t believe that the devs will magically code a new visual modulation core a la flowstone between beta 3 and beta 4.
what about some new meta-modulators ? acting like the dsp’s meta-devices and targetting specifically other modulations in other sets ; you just take the same code but instead of dealing with dsps, it modulates params’ of other modulators somewhere else. For example, a "hydra modulator" could improve the overall flexibility.
-
what about turning the Volume, Panning, Pitch… into “*post modulators” that inherit from what’s before ? We could place some of them (when needed) not at the left side of modulation sets but at the right side.
-
what about adding a “*send” modulator able to route all the previous modulations to another set ?
I think that everything is allready there in terms of portions of code, everything just deed to be adapted to the “modulators” logic.
A send requires a receiver. I assume you suggest to send the modulation meta-data. A receiver bundles things. That’d mean, voice-dependent modulations would get lost and all the same data would be applied on all voices. Doesn’t sound suitable to me. To be honest, I have problems understanding the sense of implementing meta-sends. Maybe I get the idea wrong. First question would be: What sends from where to what? But there are proven and working concepts anyway. Why invent the wheel from scratch?
Still, I’m far away from claiming MY solution would be THE solution. If you don’t like the idea of an extra abstraction, maybe someone else has something to suggest? I’m not discussing here to see you implement my thing. For me the point is also just about ANY solution, that makes sense and fits the needs.
I like the idea of a modulation send device, gets us closer to the flexibility of a modular sort of thing.
I do have a concern about introducing such a device and keeping the current target system as it is. say you’ve got and modulator and a send set up that you want to route to several parameters. would this chain that uses the send device still reside in one of the current modulation targets?
Would my “master” envelope, with the send, be sitting in volume, pan, pich etc. or would we need a generic “modulation chain?”
hope that makes sense…
What are the other possible options, beside modular spaghetti hell or the current way? Modulation matrix?
About the modulary thing in general: talking about modularity in modulations none should be concerned about having to deal with “modular spaghetti”. It becomes that, when you set it up like that. In fact there could be a few synth concepts be saved as default presets and who doesn’t want to deal with modularity wouldn’t have to deal with it and could just work with the presets, applying common parameter routings known from other synths or sample players.
modular spaghetti hell > *
(((:
Bit_Arts: It is not about what i can or can´t handle. I use modular synths (Aalto, Bazzile, Sonigen Modular and Kamiooka). But sometimes i wanna classic layout (look at Monark for example, emulation and nothing more…).
But your suggestion about templates solves this “battle” i suppose 
.
Wel if you want classic …you just use the modules you need …save as template …
+billion for modular approach …yes yes yes yes
I don’t think there can be much argument against the modular approach, it offers the most flexibility. Finding ways to present the architecture as simply as possible is the key.
I would definitely expect the modulation to continue being polyphonic, acting separately on each voice. Anything else would definitely be a serious design flaw!
I thought a bit about this, in the context of my modified Drawbar Organ example (6 layers with individual volume + attack/release). While a rather complex instrument, it is simple in the sense that it’s working with just volume modulation.
Using a send device, the samples would still be assigned to the layer that they belong to, each one consisting of just one operand (macro-assigned, to control volume) and a send device.
Global attack and release (via ADHSR) are then added to a “receiver chain”, shared by all layers via the send device, but not assigned to any specific sample
Modulation system with sends
8 macro assignments, no redundant devices
1: 16 [+Operand][Send]
2: 5 1/3 [+Operand][Send]
3: 8 [+Operand][Send]
4: 4 [+Operand][Send]
5: 2 2/3 [+Operand][Send]
6: 2 [+Operand][Send]
Attack/release [++ADHSR]
Compared with the current system
18 macro assignments, 5 redundant ADHSR devices
1: 16 [+Operand][++ADHSR]
2: 5 1/3 [+Operand][++ADHSR]
3: 8 [+Operand][++ADHSR]
4: 4 [+Operand][++ADHSR]
5: 2 2/3 [+Operand][++ADHSR]
6: 2 [+Operand][++ADHSR]
Of course, this example is limited to a single aspect of the sound, the volume. But I imagine that a send device could send information “sideways”, too (pitch, pan, etc).
The 303 example would be using this approach (I’m not sure exactly how you want the parameters to be mapped, so I added the “+” signs to the fader devices?)
1: 303 envelope [Envelope][++Fader][++Fader][Send][Send]
Here, the send devices are not sending to different sets, but instead “sideways” to the cutoff and resonance aspects of the current set
But again, we are talking about less redundancy while sticking with the current 1:1 representation