Two things are mixed up here. Velocity to filter etc is a completely different issue than the “column volume” issue. That is an issue of improving the RNI format, not what kind of columns we have.
How to interpret velocity/volume in one column is simple: The value next to a note is the velocity of that note. Values without a note by it’s side is "aftertouch ", or note volume. (This is indeed a planned MIDI/VSTi feature). The only extra thing two columns would allow is using both at a time, which is rather useless and at least definitely not worth an extra column.
90% agree with martinal, but forget about the option: no way the
present behaviour could be considered useful
Even if it’s not useful, it’s necressary for backwards compability.
Either as an option in the instrument, or as a config option.
(I hate backwards compability, it complicates everything… )
Yes it’s kind of a confusing dual discussion… guess my ideas started to trip away …
Well… kind of. I agree that the solution you described sounds good and would virtually solve everything for now. But looking in to the future and a possible feature to control other parameters than volume from velocity… how should it be handled then? Should velocity -> filter be entered in the volume column? Or should you not be able to use note volume and velocity at the same time then? When discussing a third column this seemed like a necessary thing to think about as well.
And it’s not only about improving the RNI format. It’s also about better MIDI keyboard support and a more intuitive user interface. But that’s only how what you choose to call it of course.
And it’s not only about improving the RNI format. It’s also about better MIDI
keyboard support and a more intuitive user interface. But that’s only how
what you choose to call it of course.
Velocity -> RNI parameters like filter is only about the RNI format, not MIDI, not GUI. And where did better MIDI keyboard support enter this discussion???
First, a little clarification here: “velocity” means “speed”, and is in MIDI used to describe how fast a note is struck on a keyboard. On a piano/keyboard this is the only parameter needed to describe how the note is played. (MIDI is very keyboard oriented). Velocity is a noteon only parameter, not a parameter that can be changed continuously afterwards. Therefore a “velocity column” doesn’t make sense at all IMHO…
Velocity -> filter means that when a note is struck with a different velocity (or force) the filter parameters are also affected. How those parameters are affected by velocity is a property of the instrument. It does not mean that the filter parameter can be continuously changed, thus it does not need a separate column. If continuously changing filter parameters per note is what you want, say so. But “velocity” is not the word you’re looking for then. Aftertouch to filter can of course also be done.
Sorry if I sound a bit hard on you here, don’t take it personally
Martin, we’re mostly talking about the same things but in different perspectives I believe
As a user one don’t care about the technicals like the RNI format (that I’m interest in the tech stuff is another issue… ), but obviously you still might want to map the velocity to a parameter. How? With a GUI. I seriously can’t see how you see a feature beeing implemented without a GUI. So discussing it is not entirely OT I think.
If I were able to control a filter in Renoise with my MIDI keyboard it would mean a new cool way of using the MIDI keyboard. That is better keyboard support imho. This is a feature you can write in the new feature list that would attract people more than “RNI format extended by 10 bytes” if you get my point.
I agree a velocity column seems kind of awkward as well but I can’t see another solution right now… this late perhaps?. Present another solution that allows for different velocity AND volume for each note in a multi-note-column track and I’m convinced!
Well, parameters can already be changed continuously so that’s not a problem. Simply put the velocity value just needs to multiplied with the other controllers affecting the parameters. I realize the velocity is a fixed value got at the note on event.
I agree, there is no real need for another column as such - however, my main argument stands: putting two different kinds of information in one slot is bad practice; it’s just going to be confusing - depending on context (note or no note) it will have two different functions … bad, bad, bad.
I don’t see what harm an extra column can do? like you said, not that many people need to both change the column volume and set the note volume at the same time, so if you need one or the other, you can simply turn them on/off. Also, as said, having velocity separated from the volume would give you the opportunity to add velocity routing features, e.g. velocity amount to filter envelope.
I’m quite sure this is the best solution. Having an extra column won’t be a waste of space, because you’ll most likely never have both columns switched on at the same time. When you have one of them switched on, you’ll be able to see in the track info on the right whether it’s velocity or volume, instead of trying to guess it from looking at the context.
Keep velocity switched on by default, column volume switched off - for VSTi’s and for normal composition with the internal sample player, you need control over the note velocity, not the column volume.
For aftertouch like you’re planning for VSTi’s, it would make sense to use the new volume column for that - then you avoid making the same mistake again of mapping two different functions to one column, AND you solve the problem of having a “dud” column with no functionality when using VSTi’s.
Now if that’s not killing two birds with one stone, I don’t know what it is
As it is now I’d actually prefer using the same column, but that’s maybe because I’m used to it. I consider an extra column useful if velocity could be used for more than volume though.
If introducing velocity -> parameter mapping in RenoiseRNS this would also mean introducing the MIDI limitation of not having per note volume (only per note velocity). But then again maybe I should stop buggin’ about features that don’t exist yet and be happy of how it works now. Because I am! Fixing the points that It-alien said would take care of the problems IMO too.
I decided to move this topic on the Ideas & Suggestions because it’s nomore about questions, rather it is an idea source.
So, on the same flow…
Midplay also has written about velocity controlled filters.
These reminds me about an idea I had some months ago:
the ability to hook devices parameters together, like in a LFO device where you don’t have an oscillator: a source parameter from a device controls a destination parameter from another device, with a destination range and a low and high source treshold.
This feature would reach its full potential when every parameter could be associated with an automation control, but still it would be GREAT for stuff like volume-controlled-filters and similar.