upcoming ardour development plans

--===============1988407010==
Content-Type: multipart/alternative; boundary="001a1144d62ca15d400555a8ecc4"

--001a1144d62ca15d400555a8ecc4
Content-Type: text/plain; charset="UTF-8"

There are several changes coming down the pipeline that will soon lead to
version of Ardour that creates forward compatibility issues for the 5.x and
earlier releases. Most notable is the impending merge of the
"split-disk-io" branch, which sees the end of special-caseing disk I/O and
the work instead being done by derivatives of the Processor object.

There are some useful fixes in the 5.x codebase, so the plan is to release
5.11 in the next few days to clear the decks for bigger changes, and a new
tag: 6.0-pre1

The "sdio" branch is relatively non-invasive as far as unrelated code goes,
but soon after that, another change will be made: all "framepos_t",
"framecnt_t" and "frameoffset_t" types will be changed to "samplepos_t"
etc.  After Robin added video to Ardour, the original decision to use
"frame" to refer to the set of samples happening across N channels at the
same time became a clear mistake, even if it is technically correct. I
committed the script that will be used for this a couple of weeks ago, in
tools/f2s. It will damage comments in some key files (libs/ltc and other
timecode related files - these will need manual fixups. This was written as
a mostly automated script so that we can merge any outstanding development
branches and PRs and then run the script at the right time, rather than do
a commit at some point in time and face horrendous merge issues.

If you have an outstanding development (topic) branch that you hope to see
merged, speak up so that we can plan the timing. Merging after the
frame->sample conversion will often be problematic.

Once this work is done, another major infrastructure change is almost
certainly - the introduction of a super-high resolution clock (on the order
of 2^-36 seconds) that will make conversions between sample and musical
time always reversible. This will require changing the way that region and
note starts and positions are stored.

--001a1144d62ca15d400555a8ecc4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>There are several changes coming down the p=
ipeline that will soon lead to version of Ardour that creates forward compa=
tibility issues for the 5.x and earlier releases. Most notable is the impen=
ding merge of the &quot;split-disk-io&quot; branch, which sees the end of s=
pecial-caseing disk I/O and the work instead being done by derivatives of t=
he Processor object.<br><br></div>There are some useful fixes in the 5.x co=
debase, so the plan is to release 5.11 in the next few days to clear the de=
cks for bigger changes, and a new tag: 6.0-pre1<br><br></div>The &quot;sdio=
&quot; branch is relatively non-invasive as far as unrelated code goes, but=
 soon after that, another change will be made: all &quot;framepos_t&quot;, =
&quot;framecnt_t&quot; and &quot;frameoffset_t&quot; types will be changed =
to &quot;samplepos_t&quot; etc.=C2=A0 After Robin added video to Ardour, th=
e original decision to use &quot;frame&quot; to refer to the set of samples=
 happening across N channels at the same time became a clear mistake, even =
if it is technically correct. I committed the script that will be used for =
this a couple of weeks ago, in tools/f2s. It will damage comments in some k=
ey files (libs/ltc and other timecode related files - these will need manua=
l fixups. This was written as a mostly automated script so that we can merg=
e any outstanding development branches and PRs and then run the script at t=
he right time, rather than do a commit at some point in time and face horre=
ndous merge issues.<br><br></div><div>If you have an outstanding developmen=
t (topic) branch that you hope to see merged, speak up so that we can plan =
the timing. Merging after the frame-&gt;sample conversion will often be pro=
blematic.<br><br></div><div>Once this work is done, another major infrastru=
cture change is almost certainly - the introduction of a super-high resolut=
ion clock (on the order of 2^-36 seconds) that will make conversions betwee=
n sample and musical time always reversible. This will require changing the=
 way that region and note starts and positions are stored.<br></div></div>

--001a1144d62ca15d400555a8ecc4--

--===============1988407010==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ardour-dev mailing list
[email protected]
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

--===============1988407010==--