I have a question about advanced edit modifications on the delay column.
reason: the volume and and pan values both have logical minimums and maximums for their corresponding line (silent/loudest and left/right respectively) and stop at their limits when advanced edit modifications exceed them, but delay values (being tick related) can potentially exceed the boundaries of the line limit, shifting the position of the note if necessary (and creating a new note column in case of overlap).
scenario (humanizing pan):
Consider the panning column. If no pan value is set for the notes-to-be-humanized, the pan values are considered 40 (center) before being humanized. This allows for negative modifications to pan left, and positive modifications to pan right. In other words, pan addresses the mean value (40) of the range (00-80), and applies “humanization” according to the range of the modify value, stopping at the min (00) or max (80) if the modification exceeds them.
scenario (humanizing delay)
If no delay values are set on the to-be-delayed notes via humanize (i.e. all delays are 00/left blank), the pre-humanized values are considered 00, and humanize only applies the positive modifications. Currently the delay column is limited to the tick range (00-ff) of the particular line.
Have negative/positive modifications that exceed the line’s tick limit been considered?
it hasn’t been properly addressed in the linked thread as of yet. in response to the linked thread: if one wanted the occasional early note, it would only take a few seconds to do so manually. the polar example, a global delay, could be done just as quick with a track delay. where we really loose some important utility is in the advanced edit modify operations. the functioning variables (pan and volume) all work great: you can’t go louder than loudest, quieter than mute, more left than the leftest, or more right than the rightest. so these features all respond appropriately to advanced edit modifications. on the other hand, delay is handicapped in advanced edit.
I have a solution however, and I’ll post it in the the beta forum right now. I’ll edit and post a link here when done.
This solution would allow “negative delays” (and more) via advanced edit, without any changes to current delay behavior.