-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
send amount should be 0 by default #178
Comments
64 = 0.0, 0 = -1.0 and 128 = 1.0f. You mean the default should be 64 (0.0) or 128 (1.0f)? |
default should be 0 effect, 128 is +64 |
I think it's a bit gotcha to not get any effect whatsoever, would 96 (0.5) be a good compromise? So you can here that something is happening, but it's not as over the top as 128? I'm a bit worried that users first time trying out send will try targeting something and nothing happens if the amount is set to 64 (0.0f) by default. |
is that your target group? |
I went through Ronny's song and Ronny used send amount values of 65, 112, 75, 72, 75, 128, 23, 122, 65, 128, 99, 101, 81, 91. Meanwhile, Virgill's latest song used send amount values of 80, 128, 58, 128, 128, 74, 72, 80, 128, 128. The median of all those comes down as 86. But 80 (16+64) or 96 (32+64) should compress better. So defaulting to either 80 or 96 makes far more sense to me than 64 which is a value that is never used. |
i'm thinking about this from the musician's perspective. no send will end up at 64 because that does nothing, but it's a good starting point because it allows us to dial in the effect of it from zero. this is how it works in the big vst synths like massive, serum, etc as well. |
I'm thinking this from a project maintainers perspective. If I make send default to 64, there will be people opening issues why the send does nothing, even though they have defined a target for the modulation. I could a) make it smaller, but not 64 = 0.0, e.g. 80; and b) make the unit defaults user-configurable so everyone can adjust them how they please |
The key here is that many don't realize 64 means 0; they think it's 0.5. I've already had to explain this to new users. So they might think with 64 they have 0.5 as the send gain and then just wonder why nothing happens |
I was thinking, a button for "reset parameter to default value" would be a nice thing in general. could that help solve the confusion here, too? as in, if I press the "default" button on "amount", as a musician I also would expect that whatever value it now has, it means "no send" |
There was a way to "reset to default value" but I broke it when refactoring (rewriting the GUI). But I am still not convinced that user expects the default of send to have no effect (amount = 64); I think that sounds like what you would expect to happen when you delete the send unit altogether. |
i find myself setting the send value to 64 (0) before i assign it every time i use a send. first of all, when selecting a target, the send inevitably, because of the way the assignment works, sends to a couple of places it isn't meant to go (the first op of the instrument you chose, and then the ports in the selected op that you pass before getting to the one you want) - where it may actually wreak havoc, especially with extreme settings like 128. even on the correct target, it may do that, or create noise bursts (filter frequency > 150 or so, etc). after a few very annoying instances of this i now turn the send amount down before i assign the send. edited to add: the annoyance of having to do that every time is what made me raise this issue in the first place. |
maybe then change the GUI to say "0 (raw value: 64/ 0x40)" |
I agree that the way the port is selected could be improved, as suggested by distance in #51. If the GUI was the way distance suggested, you would least you would not be sending to random ports on the way finding the correct port. [Just a clarification: I think distance meant that port would be selected with a drop-down, not a slider, like it is now] |
yeah that would be a good change, i think. in addition to default to 0 effect (raw value 64) on the send! |
way too many parameters can create very undesirable effects if 64 are suddenly added to them :)
The text was updated successfully, but these errors were encountered: