View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005100||ardour||features||public||2012-09-10 15:33||2023-06-18 04:06|
|Priority||normal||Severity||major||Reproducibility||have not tried|
|Summary||0005100: MIDI regions are always transparent|
|Description||When two or more MIDI regions overlap, notes from all overlapping regions play, regardless of the opacity of the upper regions. |
I think that:
(a) the opacity of MIDI regions should be choosable
(b) they should be opaque by default
This would make them behave just like audio regions, which I think would be much less confusing.
|Tags||No tags attached.|
||this is a very deep problem.|
I know this is unlikely to be implemented before 3.0.
However, I'd request that for the moment, MIDI regions be explicitly marked as transparent (and maybe not allowed to be made opaque).
That way, if some future version of A3 does allow opaque MIDI regions, sessions containing overlapping MIDI regions will continue to sound the same when loaded.
||This still bugs me, six years later...|
||The problem is still relevant. Without its solution, working with MIDI takes is very unproductive. You have to mute every take except for the active one. This is slow, and it is completely different from recording takes of ordinary non-MIDI sound.|
||I wonder why I said this was so deep.|
Oh, I see why.
The earliest/leftmost boundary of a currently-topmost MIDI region has to act as an "all notes off" for every note currently on.
This is trivial if every region completely covers all the ones below it. But if they are "staggered", then this becomes quite challenging. There is also the question of what happens to notes in a lower region that span the entire length of the upper region.
so yeah, inFlowiaLab, I understand why this is tricky for your workflow. But its quite hard to solve for the general case, and when we don't do that, people will run into those scenarios very often. In your case, since you appear to be completely "covering" one take with another, I would just delete the existing region (it isn't deleted from the session or disk) or switch to a new playlist.
> "There is also the question of what happens to notes in a lower region that span the entire length of the upper region."
It should sound until the upper region begins. Then she must shut up forever.
> "In your case, since you appear to be completely "covering" one take with another, I would just delete the existing region (it isn't deleted from the session or disk) or switch to a new playlist."
But I do not want to delete the recorded duplicates until I decided which one suits me. I record several takes, listen to them several times, choose the best one and leave it. And while I choose with MIDI clips, I have to drown out all the duplicates except one, listen to it, then drown it out, turn on another, listen to it, drown it out to turn on another and so on. With AUDIO thoughts, everything is simpler - I listen to the upper double, then I select another and raise it up - and it already sounds, I do not need to drown out all the doubles. Just pick the one you want and go up.
I'm not sure if using playlists to record takes is a good idea. Is there really a way to record duplicates in a loop, automatically placing each in its own separate playlist, and then quickly switch between playlists when choosing the best take? (As fast as this can be done with layers of AUDIO clips.)
||Looks like this is now implemented in edd78000 (& preceding), though I haven't tried it yet...|
As of Ardour 7.0-pre0-3455-g38c5ae4237 layered obscured MIDI regions is now fully implemented.
At the start of an opaque region above a lower region, pitch-bend and CCs values that were modified by a lower regions are either reset or restored to the the prior state (if available).
The main motivation here is to provide an easy way to loop-record and comp with consistency.
|2012-09-10 15:33||colinf||New Issue|
|2012-09-15 12:14||cth103||cost||=> 0.00|
|2012-09-15 12:14||cth103||Target Version||=> 3.0|
|2012-10-17 22:26||paul||Note Added: 0014081|
|2012-10-18 15:42||paul||Target Version||3.0 => 3.X|
|2012-10-24 20:38||paul||Severity||minor => major|
|2013-01-22 11:58||colinf||Note Added: 0014553|
|2013-07-12 10:14||colinf||Relationship added||related to 0005579|
|2019-03-20 23:14||colinf||Note Added: 0020615|
|2020-05-31 18:17||inFlowiaLab||Note Added: 0024326|
|2020-05-31 18:45||paul||Note Added: 0024327|
|2020-05-31 18:52||paul||Note Added: 0024328|
|2020-05-31 19:20||inFlowiaLab||Note Added: 0024329|
|2022-09-09 22:51||colinf||Note Added: 0026573|
|2022-09-11 00:01||x42||Note Added: 0026574|
|2022-09-11 00:01||x42||Assigned To||=> x42|
|2022-09-11 00:01||x42||Status||new => feedback|
|2022-11-02 11:00||colinf||Relationship added||related to 0009063|
|2023-06-18 04:06||x42||Status||feedback => resolved|
|2023-06-18 04:06||x42||Resolution||open => fixed|