Generally speaking, a chorus effect usually has a maximum delay size of around 30-40ms, maybe 50ms at most. This is the average useful musical range of the effect. Beyond this range it simply becomes a delay.
Is it really necessary for the chorus delay parameter to go all the way up to 1000ms? My argument against it is that a lot of automatable range (via pattern commands) is being totally lost because of the extreme 1000ms size.
When setting the delay via pattern commands, you end up with:
The gaps between these settings are simply “huge” when it comes to an effect like chorus. I can already think of situations where I would -love- to create interesting effects by automating the delay size within a range of 0ms - 20ms, for example, but the fine control I would need in these situations simply isn’t available via pattern commands.
I think a maximum size of 100ms (to match the flanger) would be -much- more useful for this effect, so that 0ms - 100ms is mapped to the full range 00 - FF.
Hopefully since this is just a beta there is still some room to tweak this.
I was the one arguing to increase that parameter up to 1000ms… simply because you can make awesome chorused delays this way (something I find more useful then typing pattern commands in a better resolution for that specific parameter).
Of course the best thing would be to have a chorus and filters in the delaydevice itself. This was also planned, but had to be skipped as there can only be 15 parameters per device (pattern command limitation).
Is that really a huge problem?
We will miss those chorused and filtered delays then… and as you know, we can type accurate values in the automation…
This is another general problem of the low pattern resolution in Renoise, and is a problem for many other parameters as well.
Well, I personally would like to keep the 1000ms. I find those chorused/filtered delays wicked.
But I fully respect other opinions about this.
The first thing I thought of when I saw 1000ms + filter was “dub delay”. And I agree, it sounds really nice. But in my opinion it’s more of a happy side-effect of the chorus on extreme settings, rather than the proper intended use. I feel like the usability of the chorus is being sacrificed just because it can also do this other gimmick when pushed really far. I realise that more accurate things can be done with the automation envelopes but I think that’s a little bit beside the point here.
My argument would simply be that you should add a filter to the actual delay effect itself… this should have been done a long time ago perhaps? Then we can have the best of both worlds. A nice, controllable chorus which works within its normal intended range, and a kickass delay with filtered delay lines for special fx there.
What do you think?
( Edit )
Ah, I just re-read that and noticed you said:
“This was also planned, but had to be skipped as there can only be 15 parameters per device (pattern command limitation).”
That’s a pity, hmm. The delay has really already used the max number of parameters? Bit of a tricky situation really. I really feel like the usability of the chorus is being affected a bit heavily by this.
( Edit 2)
Ah yes… I see now that some of the delay parameters get a new ID when switched into line sync mode. Meh.
Well, I dunno what else to say on this one really. I just think that the chorus should be a chorus, and should do its intended job well. If Renoise is to have a solid set of well-rounded native effects, then the user should have the proper control over these effects within their actual intended use/design.
A filtered delay would be really awesome to have, but my personal opinion is that it should be the job of a dedicated filtered delay, not the side-effect of something else.
I hear you. And feel pretty much the same.
The chorus has at the moment stepped back a tiny bit in order to also work as a special delay.
Of course both ways do have workarounds (using automation, or setting up send tracks). But they are both a hassle to do.
The root of the problem is the limitation in the pattern editor. There has been a lot of discussion about that as well, and quite a lot of planning and problems/solutions for a better command resolution has already been made for a future update.
When this will happen, then there won’t be any problems no matter what we choose to have for now.
If there is a big demand to reverse this behavior then I will gladly step back and start using send channels again
EDIT:
hmm…
How about changing the scaling of that parameter drastically?
Let only the last few % av the slider range go from 100 to 1000ms?
I’m just checking out the chorus and it sounds wicked on higher delay settings, instant dub. I can see dblue’s point on using patterncommands to control it. I’d say use the automation editor for the finetuning and keep the higher delay intact.
How about a few ranging sliders to set a specific (threshold) range for the delay amount, just like with the min/max dest. in the Velocity device?
Then you can set the range from 0 to 40ms as max and also use pattern commands to be more specific
Sure, that actually sounds very nice as well. Changing the max range based on what you are doing in each song.
The only thing I was concerned about is that the chorus is able to behave within the normal limits you’d expect from a chorus effect (and be fully/easily automatable within those limits). Whichever method is used to achieve this is ok by me.
