LinuxMusicians

https://nightly.ardour.org/list.php@teh ~/moment $ Git: 6.0-pre0-34-g7d559de

Status: Failed Date: 2017-09-20 06:00:23 UTC Build Log
File: N/A
Git: 6.0-pre0-34-g7d559de 7d559de..

\o/

Not yet

D'oh!

5.12 was released just before this: https://community.ardour.org/node/15298

The correct subject is "Development on Ardour 6 commenced"

6.0-pre0 tag was made early on in the 6.x development process because Ardour is undergoing a substantial rework. During the "-pre" phase of development there are no guarantees about session compatibility or stability, heck, git/master may not even compile. For good measure, there's also a warning if you launch a -pre* tagged version.

Do not use Ardour 6.0-pre* unless you understand that you are testing a development version that is undergoing substantial, deep code redesign.

The first parts have already hit: support for cue-monitoring, latch-automation and log-scale interpolation. All of which are new features that save state in the session-file and that state-format is not yet frozen. If you create or load+save sessions with Ardour 6.0-pre they may or may not load again at a later time.
Once it's out of the woods, there will be backwards compatibility and a release-candidate tag.

Mentioning backward compatibility and session file format changes/additions, this has been problematic with properly released versions of ardour. The renaming of 3 series session files by 4 and 5 series ardour was at least a way to acknowledge that migration might mean working with different ardour versions at the same time for a while, but since then the only move guaranteed to work was forward.
Desired behavior would be, imo, newer ardour opens older ardour session file - does nothing on open, much less unprompted renaming - on session save the user is given the option to save in the original (old) format, loosing some settings, or to save in the format of the ardour version running. Implementing this would most probably mean/have meant changing the file extension for each new version of the session file that cannot be parsed by older versions. This, in turn, would lead to wanting to introduce innovations in a more grouped fashion, rather than one by one.

A non ideal example would be how microsoft have introduced the .docx format rather than renaming .doc to .old.doc .

forestandgarden wrote: Desired behavior would be, imo, newer ardour opens older ardour session file - does nothing on open, much less unprompted renaming on session save the user is given the option to save in the original (old) format, loosing some settings, or to save in the format of the ardour version running.

There are no plans to maintain forward compatibility. Ardour 6 won't be able to save Ardour5 sessions [*]. Also keep in mind that many operations in Ardour implicitly save the session (the most obvious being recording), and that Ardour does periodic backup saves (by default every 2 mins).

Branching the session to just another snapshot is the cleanest and by far safest way.


[*] the MS Office approach of saving old version and "you will loose some information that older versions cannot support", won't fly here. The casual user won't even know what those are and why things may sound different. It'd also need a team for quality assurance, some dedicated persons to maintain it and in reality just be a source of bugs.

x42 wrote:saving old version and "you will loose some information that older versions cannot support", won't fly here.

Sad, but what to do. It would be helpful then to have the structure of the ardour session file properly documented, including its evolution over versions - it is to some degree self-explanatory, but that doesn't replace a concise description. Having it all in one place would be nice, but an assortment of links will do. Writing scripts to manipulate session files - at my own risk - would then be a challenge that could just so match my skill level. Of course, if standalone tools for seesion file manipulation are in existence, and be it utilities written for personal use, I'd be glad about a copy, again to use at my own risk. There could be more manipulations than adapting to different versions, e.g. standalone session clean up, to name but one.

The casual user won't even know what those are and why things may sound different.

That is what some might call an assumption And if you stress the word 'casual', great things must in no case be expected from using software of ardour's complexity 'casually'. To stay with the ms word analogy, the chances that a user has no idea what formatting he will loose and why the document is looking different, should be about the same, yet still the user can make an informed enough decision if he understands that he will loose something but gain that the file stays in the original format and can be opened by the older app. And if he doesn't even see that, there is such a thing as a recommended default. Two extra arguments: the author of Non-Timeline has gone out of his way to implement ardourt3 session import - Linux audio would benefit greatly from such gestures being seen more frequently, and: fatal confusion has not resulted from the fact that mixbus sessions open in ardour with the mixbus specific plugins missing - and there is just as much or more reason to believe that the user is aware why that happens than that he isn't.

Also keep in mind that many operations in Ardour implicitly save the session (the most obvious being recording), and that Ardour does periodic backup saves

Implementing this would most probably mean/have meant changing the file extension for each new version of the session file that cannot be parsed by older versions

then the newer ardour could save in its own format and extension without conflict, but on a user prompted session save, or when attempting to quit w/o saving, options could be given. Of course, I did get you: it won't fly. I'm only hypothetically adressing an obstacle you mentioned.

In more general terms, if you change any file format definition without changing the extension or whatever serves to identify the file type, what you effectively do is obsoleting the previous definition.

forestandgarden wrote:In more general terms, if you change any file format definition without changing the extension or whatever serves to identify the file type, what you effectively do is obsoleting the previous definition.

Exactly, just as new releases of ardour obsolete old ones. There is data in the session to know which version of ardour it was made with and modified with, so they easily manage older sessions and maintain backward compatibility. With the free licensing and generous terms of purchasing official updates (many of us here don't pay a dime for ardour), I don't know what you expect more of ardour to do. They don't have the development resources to maintain old versions, and they make every new version to be better than the previous. They have nothing to gain by the userbase being fragmented across old versions and hitting old bugs over and over that have been fixed in more recent versions.

Anyway, I guess I'm ranting a bit, sorry. Have you looked at the .ardour files? IMHO they are as readable as xml can be. It shouldn't be too difficult to script some converters just a little tedious.

ssj71 wrote:With the free licensing and generous terms of purchasing official updates (many of us here don't pay a dime for ardour), I don't know what you expect more of ardour to do.

Personally, I expect them to do less, in perfect keeping with the 'less is more'-paradigm.
irresistible remark: how can you expect to polish an elephant while you are racing it?

No hard feelings, and if there is one prone to ranting, it's me , if I am taking up this point out of a few I could answer to, it's because this is a recurring theme, and a problematic statement, a sword that cuts both ways - with the risk of leaving goodwill a casualty -, and yet maybe a debate it were high time to have, in the best interest of FLOSS, what do you think?

Why should or shouldn't claims made by users of FLOSS be related to what they paid for it? The 100 best reasons - I'm talking to the journalist (and opensource enthousiast) in you

If I wanted to give it a provocative starter (that well illustrates the problematic aspect), I could just as well ask what ardour have paid for the wealth of FLOSS libraries & algorithms in use, or if they are in a habit of donating to other FLOSaudioS projects before criticizing their 'design flaws', and judge the weight of their word by that.

This is an intentionally black and white version of the debate, but if you mentally continue it, it should be possible to discover that, as you add colour and shades, it can point a constructive direction, too.

forestandgarden wrote:'less is more'-paradigm

I don't think that paradigm is what ardour is going for at all. Perhaps you would like non-daw. Ardour on the other hand is going for a more comprehensive DAW, allowing a large variety of workflows.

forestandgarden wrote:Why should or shouldn't claims made by users of FLOSS be related to what they paid for it? The 100 best reasons

?
umm
For the most part, linux audio projects come from developers. Thats just the way it is. Watch perhaps Louigi's lecture if you haven't https://www.youtube.com/watch?v=LwNXn7OKVzY&t=182s
Thats just how it is.

If you value a project, take interest in its well being and help the developer stay motivated. That may require paying for it, but not always and it will be different all the time.

If you don't like what a developer is doing, go ahead and have a discussion, but realize most often it is the develpers project they're going to do what they please. They may not really be set on that direction and they like what you suggest. Even if they don't if you can get them motivated one way or anther to do what you want, it will go in, but if you think that nagging and criticizing will motivate you are more likely to find that they just abandon the project.

Once money is involved its a little more complicated. Since the funding is from the community is the community the boss? Not really. A true donation is different from a purchase. It doesn't really give you right or claim to anything. A subscription? Even a purchase? What are you REALLY purchasing? Typically its not control of a project. For ardour, since we are discussing it, you really just get an officially supported binary, so you get some support, but that has little to do with the future.

You can always ask for a refund. You can always threaten to remove your future funding (I hope its clear I'm always in favor of clear, honest communication), but in the end, if its the developers' project (which FLOSS pretty well always is) its going to go their way, and if your ideas don't fit in they don't need you. Sure you are a customer, and if they are really striving to succeed as a business they have to keep the customers happy. Some are more polite and accommodating than others, but invariably projects go in the direction that the developers are motivated to take it, and money is rarely the motivation around here.

Notice also that ardour is now working on clip launching which is a feature long requested and long resisted, but now Paul has changed his mind and decided that it is valuable. So its going in. So with patience developers/projects may change directions, but it may or may not be in a direction you like. And it might take years.

Thats all I've got.
When did I turn into a cynical, grumpy old man?

ssj71 wrote:IMHO they are as readable as xml can be. It shouldn't be too difficult to script some converters just a little tedious.

If you had taken the time to take a look at the thread, you'd have noticed that I had touched on exactly that. Alas, while I agree on general readability, I believe actual work on them may be less than trivial, more so without the specs at hand - why else was I answered that having to maintain its quality was a hindrance to introducing a management proper of previous session file formats? - and I thought I was at trying to elicit them from x42 when you jumped in.

I'd actually love to see

x42 wrote:^ fake quote for highlighting, but isn't he a great fellow?

here more often - there is no day when I don't see him giving valuable information, worthy of being kept for better ardour documentation - on irc where it is gone quickly; like, take, the arguments the cli standalone export tool accepts.

I'm sorry, there is nothing to debate here, which is why I was not responding.


If you have a quick look at Ardour's session format you will realize that it's basically just serialized C++ class state. It is not an interchange format nor was it ever designed to be one. It changes whenever C++ class internals (not to be confused with APIs) change. There is intentionally no XML DTD and no plans whatsoever to standardize it. It really does not lend itself to standardization. There's only a general goal to provide backwards compatibility.

You could criticize that Ardour does not use an abstract description of the session or an open standardized DAW format (which one, again?), but that's a whole different story.

..or whatever serves to identify the file type

It's an XML file and the first two lines (xml tag, root-node) define the format and version. Current is "3002".


PS. It's free software and it just takes one dedicated volunteer... and perhaps a research-team, a standards-committee and a few years but we've seen major contributions coming seemingly out of nowhere before.

Interview with Paul Davis of Ardour about Ardour 6.0 and more
http://admiralbumblebee.com/music/2018/ ... -more.html