The only thing stated there is, there’s nothing layering, when you don’t detach anything. There is nowhere written, it’d be comfortable because of that. It’d be a really good idea to stop reading things, that none wrote. You’re starting to leave some strange impression.
Yeah, but… any somewhat specific ideas on how to improve the modulation scheme?
make it les arcane
1( or more ) envelopes( or any modulator) that can be routed to multiple destinations ,as shown in mock up on the first page .
That probably needs a lot of recoding .
But I also think this is the best method
lol
I’ve fiddled with a few modulation concepts, and this is one I think would match the requirements pretty well:
Sample -> Modulation Set -> Modulation Source -> Modulation -> Target
Relations:
- Sample -> Modulation Set: 1 -> 1
- Modulation Set -> Source: 1 -> x
- Source -> Modulation: 1 -> x
- Modulation -> Target: x -> x (Multiple Modulations triggering the same Target are summed up, before applied. That’d make something like planned bracket devices obsolete.)
Components:
Modulation Set:
Each Modulation Set holds a list of Modulation sources, each type allowed multiple times.
Modulation Source:
- AHDSR
- Envelope
- Fader
- Key Tracking
- LFO
- Operand
- Velocity Tracking
Required parameters (beside source individual parameters):
None. Each Source provides the full range.
Each Modulation Source holds a list of performed modulations.
Modulation:
Required parameters:
- polarization
- min value
- max value
- operator
- operand
- self modulation (on/off)
- Target
Each Modulation holds a list of targets, as target including parameters of other Modulations from all Modulation Sources.
Target:
- Volume
- Pan
- Pitch
- Cutoff
- Resonance
Required parameters:
- Input
Other Targets:
- Modulation min value
- Modulation max value
- Modulation Operand
Sounds on the first look probably way more complicated, than it has to look like in practice. I think, that’d provide everything necessary to modulate the hell out of it in a very comfortable way.
I really like the changes being proposed just above. Still, it won’t make the system perfect, but I believe in constructive discussion
Oh, and I do paint. It’s not mandatory for alpha testers, though 
I hope we get around to actually implement a revised modulation section, now that we have finally reached beta time.
Well, I pointed out the weak points of the current system. I actually think it’d be appropriate to do the same, when you state, my concept wouldn’t make the system perfect. I’d really be curious and I’m always willing to learn. 
I actually meant, it should be “either… or…”.
Seriously, how? By keeping this one, despite it’s exponential redundant and turns usability upside down? As much as I understand none wants to change it anymore - and I really do -, I doubt there’s a way around this, when you’re going to release something proper.
Well, the way it is visually represented does not mean it is hard to change it code-wise.
Well when 3.0 goes gold …a few months later they will announce Renoise 3.1 with a revised modulation section
…
I hope …
In this case it absolutely does. Specially the concept makes it redundant. Keeping the visual concept in this case also means keeping the redudant code concept behind it. Otherwise the GUI wouldn’t make any sense anymore. Sad fact.
In some way perhaps, but i have programmed stuff that required a load of gui changes but programming technically only swapping of a few variables in the loop and condition spaces, however, we both don’t know what is in the source code of Renoise exactly, so this remains pure speculation on both sides .
It’s not speculation, but pure logics without any need for knowledge of the code.
Anyway, it appears like pointing out obvious malconceptions turns me into the guy understanding everything wrong or not at all. 
Trying to help make this software work in a more proper way is like fighting windmills. Really, if I wouldn’t see this myself, I’d think this has to be some kinda comedy.
“Yeah, people. It’s Beta-Phase! Pls help us finding bugs and mistakes. Oh, you found a really huge mistake? Crap, fixing that would mean serious work! ^^ Oh, well… erm… it’s not a bug. It’s supposed to be that way!” 
Well, I pointed out the weak points of the current system. I actually think it’d be appropriate to do the same, when you state, my concept wouldn’t make the system perfect. I’d really be curious and I’m always willing to learn.
No, that’s not it. I’d say that it looks completely reasonable. It’s just that I personally have created lots of instruments in Renoise 3.0 (factory content), and I have only been missing something like this on a few occasions.
More often than not, it has been other things, like the free-wheeling LFO that I have missed, because it actually affects the sound that comes out of the speaker. Call me masochistic, or whatever, but I don’t mind using copy and paste, as long as I can achieve the desired result.
Also, with an abstracted system like the one you suggest, many instrument types would need a heck of lot of freely floating modulations that are then assigned to individual sample aspects. You basically would end up with two large lists instead of one. For example, I’d like you to imagine a complex drumkit with individual modulation for each type of drum? - Here, it seems to be the current system which has the advantage, at least from a GUI point of view
Thanks for the heads up, haven’t checked out the factory content yet 
There is no scenario (not a single one!), in which my concept would require to setup more modulators/modulation sources, than in the current one. In the absolutely worst case it’d use the same number as the current concept does. That case would still be the absolute exception.
That goes for any instrument and the same goes for drum setups. Your argumentation in fact has no point. Could you setup an example that proves what you’re claiming? I still intend to move to FL, if the current concept is kept. If you can bring a single example, where my concept needs to setup more, than in the current system, I’m gonna order 3.0/renew my license! Good luck!
Oh, and… as currently there are no “free floating LFOs” in Renoise, if you make up a case like that, please don’t forget to add the same LFOs as Modulation Source in my concept.
Bit arts ,slow down and don’t get to emotional about this ( you can use fl studio and renoise together )., I am with you on this one ,but you can not expect the developers to change everything because some of us experience it as arcane ( I do to ) .
I know you like to delve deep into modulation sets , and the way ren.3.0 handles this is indeed illogical , but it won’t stop me from making music .
Giving ultimatums to the dev’s is also not an option , don’t forget they build this system and rebuilding it because some of us find it arcane is like asking a developer to admit the whole mod.sysytem is a bad joke .
How about Bit_Arts actually finishing a piece of music before he is allowed to post in this thread?
Well, it IS a joke. Show this concept to someone like Urs Heckmann (U-he) or Bülent Bıyıkoğlu (KV331 Audio). These guys would laugh their asses off. You still don’t see ME laughing, because I was looking forward to use this stuff and now can’t. At least not in a way, that’s not a pure waste of time. I’d totally understand, when fixing this and releasing the final would take a while. But it’s beyond my understanding of sanity to seriously intend to put something like this into a final release.
Beside that I’m absolutely not emotional right now. I simply know, he can’t bring a single case, that proves his claim. I’ve done my homework.
Pretty good and somewhat z3ta-like (an awesome system), Bit Arts is got there, if I understand what he’s getting at.
But slew/inertia modifier is missing from bit art’s implementation (and current one)? Portamento, smoothing sudden value changes on envelopes (when sustain isn’t reached before decay stage starts and when envelope resets before decay reaches zero), also maybe help emulate moog style envelopes. And smooth random lfos, much more. Very valuable stuff?
Hmm, and a quantize modifier for value picking, and cool steppy stuff.
And of course the sample position target.