<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;" dir="ltr">
<p></p>
<p>One idea would be that every "empty" midi track gets a default, undeletable background region that is infinite in length (or at least, spans the whole session, time-wise,and resizes itself when the start/end markers are moved).</p>
<p><br>
</p>
<p>That would:</p>
<p>1) make midi editing less disturbing for new users (no need to create a region first)</p>
<p>2) keep all the good aspects of region editing (linked regions, etc...) as new regions could still be overlaid over the "background" region</p>
<p><br>
</p>
<p>Recording while on "edit" mode could rewrite the content of the active region, and create a new region outside edit mode. Or, the MIDI tracks could have (like audio ones) their record mode set to Normal/Tape/Non layered. Or simply (but disruptively) create
a switch in the track header "destroy/overlay". Or create a secondary rec-arm that is a "rec destructively".</p>
<p><br>
</p>
<p>It may solve the cons you mentionned, but not the illegal overlapping notes... But we keep the consistency between audio and midi AND full compatibility with previous Ardour versions.</p>
<p><br>
</p>
<p>Regards,</p>
<p>Headwar<br>
</p>
<br>
<br>
<hr tabindex="-1" style="display:inline-block; width:98%">
<br>
<p></p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" color="#000000" face="Calibri, sans-serif"><b>De :</b> Ardour-Dev <ardour-dev-bounces@lists.ardour.org> de la part de Robin Gareus <robin@gareus.org><br>
<b>Envoyé :</b> vendredi 3 mars 2017 16:31<br>
<b>À :</b> ardour-dev mailing list<br>
<b>Objet :</b> Re: [Ardour-Dev] let's talk about MIDI regions</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">[re-arranged to avoid top-posting]<br>
<br>
On 03/03/2017 04:17 PM, nick mainsbridge wrote:<br>
> <br>
> On 3 March 2017 at 21:02, Paul Davis <paul@linuxaudiosystems.com> wrote:<br>
> <br>
>> one idea that is in the air for Ardour 6.0 is to move away from the idea<br>
>> of MIDI regions entirely. in the simplest terms:<br>
>><br>
>> pro-regions:<br>
>> makes editing MIDI more like editing audio<br>
>> allows easy copying of motifs, themes, drum fills etc. without having<br>
>> to select stuff<br>
>><br>
>> anti-regions:<br>
>> greatly complicates the basic nature of MIDI tracks<br>
>> hard to overdub MIDI - does this create a new region, or edit an<br>
>> existing one<br>
>> MIDI CC data ("automation") always needs a region, somewhat<br>
>> counterintuitively<br>
>> MIDI data is much more discrete than audio, and can be easily<br>
>> selected, then<br>
>> copied, moved, pasted etc.<br>
>><br>
>> without regions, a MIDI track would just be a single context for MIDI<br>
>> data. each new overdub would add more MIDI data to that context (possibly<br>
>> replacing or altering existing notes in the case of MIDI-illegal note<br>
>> overlaps). edits would be done via cut-n-paste. MIDI CC data ("automation")<br>
>> could be added to a track at any point.<br>
>><br>
>> discuss.<br>
<br>
Making this even more destructive strikes me as backwards. Now it's not<br>
only regions that are edited destructively but whole tracks.<br>
<br>
It would really be nice if midi editing would be non-destructive. One<br>
possible way: write a new .mid for every change-set (or on every<br>
session-save).<br>
<br>
<br>
> i would like to add:<br>
><br>
> pro-regions:<br>
> - the audio/midi similarity extends to recording also<br>
> e.g. ad hoc take management is simple (mute the last take of<br>
simultaneous<br>
> audio + midi recording and go again)<br>
> - lock to audio / music is al least partially possible<br>
> - regions may be positioned at sample resolution<br>
> - most anti-region arguments look like decisions that are yet to be made.<br>
> - solving 'MIDI CC data ("automation") always needs a region' seems<br>
easier<br>
> than removing complexity (are we overwhelmed by this?).<br>
><br>
> anti-regions<br>
> - regions are difficult to get right.<br>
<br>
and<br>
- quantization<br>
<br>
select 2 linked regions. one starting at 1|0|0, one at 3|2|123. quantize<br>
to grid. It's ambiguous what should happen and it gets worse if there's<br>
a tempo/meter change in between.<br>
<br>
ciao,<br>
robin<br>
<br>
</div>
</span></font></div>
</div>
</body>
</html>