Audio Warp in Ardour

When Reaper is configured to internally behave the way Ardour does - namely, to prioritize constant workload, rather than maximal efficiency, so that you do not get surprises when, for example, unmuting things - the difference in performance is minimal (we’ve measured it).

It’s fine to do what Reaper does by default, it just represents a different preference. For Ardour, we prefer to be able to tell you that given your current track and bus setup (including plugins), the DSP load will vary very little to not at all no matter what you do.

This thread is becoming a bit unproductive. There are as many differences of opinions about people’s preferred DAWs as there are DAW users (or at least 25% as many). We will probably lock the thread in another day or two to avoid further loss of relevance (you are still free to debate the pros and cons of different DAWs, just in some other thread).

The task is not too large for us to undertake. The problems have already been identified by Robin:

  • the main timestretching open source library is not capable of results close to what zplane can do
  • zplane is not open source, and we cannot use it directly

Coupled to that is the question of priority. Since we do, indeed, have resource limitations, we have to identify tasks that we believe provide the greatest good for the greatest number (obviously we sometimes make mistakes with this process). This particular task is not super low priority, but it’s not super high priority either.

Understood. My apologies, sir. I didn’t mean to cause any sort of ruckus. I was merely expressing my own findings.

Thank you so much for all you do in regard to Ardour’s continuing development. :slight_smile:

As an Ardour lover I have to very much agree with this, answers like this are value judgements not technical facts or explanations of technical limitations (I do understand the rubberband dilemma). Same thing goes for prior explanations of why the MIDI velocity drawing and ramping hasn’t been implemented… “we don’t do things just because everyone else does…” etc. It’s great that Ardour has seen such great success, it absolutely deserves it and it’s great to be a maverick or a dark horse or an outlier and still succeed but please enough dumping the reason things are or are not implemented on the User demanding something unreasonable when it exists practically everywhere else in your target competitive field… It’s bad PR and you’re obviously far too talented and intelligent to give such glib answers to reasonable feature requests for a DAW of this class. Ardour is your baby, you can implement or not implement whatever you want based on your available resources but I think people want to hear reasons and not opinions…

1 Like

So a couple of things here:

  1. This reasoning is exactly why public relations departments exist in commercial companies. There is a big difference between knowing the technicalities of something, and explaining it in a way others understand the full reasoning. And the latter part of that takes up a significant amount of time.
  2. I will also say that just because developers (Any) give reasons here they won’t implement something, doesn’t mean it is written off. It tends to get filed (Especially if on the issue tracker) and kept in mind. It may not be a huge priority for time investment, but that doesn’t mean it won’t ever happen either, this has been proven throughout Ardour’s history as well for those that haven’t been around that long.

So yea please keep in mind the nature of open source development, the lack of money spent on things like PR etc. in preference to helping pay the developers, etc.

   Seablade
4 Likes

I don’t want to be disrespectful in any way so please forgive me if I say something stupid.
I noticed that under the Ardour Finance sidebar here every month the goal is overshoot so people contribute more than what you guys decided it’s a fair pay, again sorry if this isn’t correct. Of course those money are yours but have you guys ever thought of letting subscribers / donors decide the prioritization of some wanted features? Maybe just the donations above the monthly limit could be spent on those “extra” features by hiring someone or something like that, so as to not bother Paul and Robin and other main devs with their work priorities.

The sidebar indicator only cover’s Paul’s income (and hosting expenses etc). Currently most of the donations above the $8.1k mark is what makes up a port of my income. Some of it also goes to other persons (Ardour hired a web-dev a while ago, and pays Alex to keep the manual updated).

PS. It is actually quite hard to find someone with the expertise to work on a DAW and it’s not for a lack of trying. Paul asked on Hacker News about that a few months ago.

3 Likes

We’ve also put aside a relatively substantial sum from the excess that has flowed to the project over the last few years. Some of this has been used for the web reimplementation and continues to pay Alex, and as Robin mentioned I have made a few efforts to find an additional developer who would (initially at least) be paid from the money we’ve put aside. So far, that search has not been successful.

2 Likes

The problems with that, that I see, are:

  1. There are a lot of factors impacting software development which users don’t see or understand, which makes prioritisation a lot more complex than just what is seen as most desirable from a user perspective. Examples include lack of available libraries, and internal incompatibilities with data structures, skill-set shortages, etc.

  2. Having a (publicly visible) user-generated priority list is a potential (and probable) PR disaster as it creates unrealistic end-user expectations. Trying to explain why the devs are (for instance) “ignoring” a highly requested item causes constant friction and arguments. In my experience, even most commercial organisations struggle with this sort of PR and user expectation management. The way most companies with well-funded PR departments seem to deal with this is by carefully avoiding having such lists.

  3. In my experience, having such lists turns into an argument itself, between end-users who have competing views, needs, etc. A previous forum I was a moderator for had incessant arguments spanning years over certain feature requests. In practice, trying to come up with a feature list that genuinely represents the desires of the majority of end users is actually pretty hard.

Cheers,

Keith

2 Likes

As a member of Ardour’s community, I will second @Majik’s post here, and could add some things, but I think it is covered somewhat well.

As a moderator, on a different note, I am going to pull us back on topic at this point. Our original topic was about audio warping/stretching in Ardour. If your post is not directly related to this topic I am going to encourage you to create a topic specific to that post instead of taking this topic further off topic.

If this topic continues to go off course, I will just close it. At this point I believe it has run it’s course in terms of the feature request but I am to nice and am giving the opportunity for final thoughts. I will point everyone to my suggestions earlier in the thread for any future posts,

If I feel like these are not considered before a post, I will likely remove it and/or close the thread as well.

Thank you.

 Seablade
4 Likes

The problem with Reaper,Tracktion Waveform and Bitwig is they don’t support LV2 and which support doesn’t show the GUI, the most usable DAW in Linux with its ups and its drawbacks is Ardour, the others are windows software adapted for Linux use. And Qtractor doesn’t have multi-output support for drum mixing.

Reaper does support LV2 since v 6.21 (Feb 2021) on all platforms; around the same time, the most popular plugin framework (JUCE) added LV2 support.

And sfizz has multi-output support, but one may need to tweak one’s sfz file, as I don’t see many sfz libraries being updated. It’s not terribly hard, though.

You’re right, but Calf Plugins doesn’t show GUI on Reaper and loading Calf in Reaper through Carla are buggy.

I believe this is an issue with Calf plugins using GTK for their GUI toolkit, which causes problems when there are version mis-matches between the plugins and the host.
Linux Studio Plugins are well-maintained and not affected by this. Perhaps consider LSP in the place of Calf if they cover your needs.

https://lsp-plug.in/

LV2 LSP plugins have GUI in Tracktion Waveform Pro v12.5.
Calf plugins haven’t.
Yes, I confess, I bought it. Shame on me. :frowning:

Back to the topic. I’ve been playing with Waveform for a few days recording some electric guitar stuff, and man, I’m impressed by ‘warp time’ feature. I play a lot black metal tremolo riffs. To keep the left and right guitars in sync I usually spent a lot of time recording multiple takes in Ardour and then trying to sync them using ripple edit. Very, very time consuming procedure. In Waveform using ‘warp time’ I’m able to do the same thing 10x faster or even more! The more I use this feature the more I cannot imagine how to live without it. Cheers!

Hello, not only Calf, neither the x42 plugins including AVLDrums doesn’t show GUI in Reaper and crashes Waveform 12.5, Calf Studio Gear is irreplaceable, specially Calf Multichorus.

The only 99.5 percent usable DAW in Linux is Ardour, “CLOSED CASE”, and…let’s not get off topic about Audio Warp in Ardour :face_with_monocle:

Ok closing the topic now, as it seems to have run it’s course and is spending more time off topic than on topic.

Seablade
4 Likes