If it is then Ardour is in trouble 
(It’s definitely not btw)
@Dhealey: You are right. However, question marks on licenses aren’t a good thing. One should not need three lawyers to exclude at any time later could pop up an issue. Better to have no questions marks at all.
What if there were twofolded projects ? Imagine, you start an FOSS app project and some code from it should be used in a commercial project ? Also, sponsors of your project, hoping to use something for their own products hesitate because of the twofolded license ?
One way or another, there might come up trouble … an essential thing as a GUi library should be as free as Linux and BSD themselves. Also free of headache.
Oh you mean like Ardour and … Harrison Mixbus … or … Waves Tracks Live … or … (unreleased) … ?
2 Likes
Like the Linux Audio Consortium has been doing since around 2002, also organizing regular Confernces for the various Members?
Anyway, demanding something from a community usually never goes anywhere. Volunteer to do the things. Lead by example,…
3 Likes
I don’t demand. I asked and I proposed.
I try to show that the need increases as more and more companies try to capture realms in the open source world to do their business while thereby often (not always of course) hindering healthy further open source development. I try to show that coding is not the only important work which can be done.
I’m already involved in various voluntary works outside the IT scene. Up to 20 hours a week. Zero payment. Otherwise, yes, I’d offer contributions.
Tom
I don’t make a living as a software developer but I have some basic understanding of what you are talking about because of my technical background. Let me my ideas, of course I could be completely wrong, I am just a user.
1.- If the Ardour core engine (none GUI) can be properly organized and documented to be reused so people can build their own audio production applications then maybe you can get people interested in contributing to the core framework. This is maybe for the people with a background on math/physics/electronics and interested in low level programming. Smaller number of contributors but hopefully very skilled people interested in this kind of challenges and maybe not caring on GUI development.
2.- If the Ardour GUI is built with reusable widgets based on more accessible languages (wasn’t there some XML based GUIs in Qt/KDE and GNOME?) with no performance degradation then hopefully programmers with no skills on audio processing could get involved.
3.- Business partners. I know you have a Mixbux relation, but can it grow to build along with other FOSS? No specific ideas here but maybe you have a better perspective.
EDIT: Maybe I was too focused on the “get more developers involved”. I am not an advanced user but I guess advanced user could benefit from the reusable widget approach so they can create their own customized windows for specific needs of their workflow. I can think of a consolidated dashboard of only necessary controls from plugins of interest when Mixing or Mastering rather tan jumping from track to track, looking for the right pulgin, change the parameter, closing it, go to another track and so on. Or avoid having so many plugin windows opened at the same time. It may be too advanced but look at this video of a guy assembling an HMI application with no code at all, just reusing widgets and linking them to existing variables. https://www.youtube.com/watch?v=acEVFke9R3M
Ardour does not exist to act as a toolkit to build audio applications. That was never its purpose. It is DAW, with a distinct set of assumptions, imagined workflows and priorities. There are several other excellent systems that exist to let you do things like that.
As has been described many times on these forums, discussions about changing the toolkit we use are a non-starter. Wasting 1-2 years to port the 175k lines of GUI code to a new toolkit doesn’t help our users in any way at all, and will not fix any of the actual problems (such as they are) in the GUI.
You do not need “skills in audio processing” to work on the GUI even today. You do need to understand C++ and you need to be comfortable working on a mid-to-large sized application that involves multiple threads, model-view-controller design and several other things that have become less and less common as more and more software development takes place around the browser as a platform.
2 Likes
Thanks for the quick reply Paul. As an end user with no modern programming skills direct access to source code is too much for me. High degree of customization based on parameters, drag and drop and options is what would benefit me as a basic user to be more in control of what I want from a software. This is the approach may companies look when trying to buy software no need to get the sourcode, just a high level and flexible customization. This is just thinking outloud, there is no right or wrong, just better suited for needs/budget.
I was here last in Feb 2020, anything new in Lua scripting and GUI scripting ?
Sadly no. Nobody has been been working on that since.
1.- If the Ardour core engine (none GUI) can be properly organized and documented to be reused so people can build their own audio production applications then maybe you can get people interested in contributing to the core framework. This is maybe for the people with a background on math/physics/electronics and interested in low level programming. Smaller number of contributors but hopefully very skilled people interested in this kind of challenges and maybe not caring on GUI development.
The thing about DAW core engines is that they tend to dissolve into the oblivion.
Ecasound nearly died and is now more like in maintenance mode, as far as I can tell.
Both Audacity’s own core engines, libaudacity and Mezzo, were short-lived projects that never saw any real use.
Tracktion’s engine has been in development since April 2016, and in the 4.5 years of its availability, it only has 4 contributors 3 of which are very definitely Tracktion’s developers, the 4th guy I’m not sure about and he only made 17 commits. The GitHub repo has seen very few commits since June. And if you look at the network, there’s just a handful of developers who did something in their respective forks of the engine and they mostly never contributed back.
Picture me skeptic.
1 Like
I’ve played with Ardour since 2005, when I found it by accident looking for software for Ubuntu. Back then it was clunky.
Now, I’m finishing my first album on it, and its workflows are great - I have used Logic, REAPER, Audacity, and Vegas between then and now, and the only thing that comes close to Ardour is REAPER. The only thing I wish I could do, that scripting GUI things might be able to do, is do things like move the transport bar to the bottom of the screen instead of the top. MOST of what I want as an end-user of Linux pro-audio is better MIDI implementation (in the works, I know), more commercial plugin availability for Linux, and better hardware audio interfaces that have full functionality on Linux. And fucking Pipewire to work so I can get rid of JACK and PulseAudio in one fell swoop. Plugins, audio interfaces, and Pipewire aren’t in the scope of the Ardour project, so I’m gonna keep on supporting the project.
I think that having Paul, Robin and others join their voices in asking for more Linux support in commercial VSTs and hardware would be valuable - if you guys are already doing this, ignore that. My bandmates would all use Linux for pro audio if NeuralDSP, Toontrack (makers of Superior Drummer), and whoever makes Izotope made LinuxVST or LV2 ports of their plugins.
As far as the direction of the project, I think closing the source code is a serious mistake for all the reasons listed above. I’m one of those end users - I know how to do a tiny bit of stuff in Python and C for programming Arduino/Pi boards, but I don’t have the skillset necessary to even do LUA scripts, and I am here, using Ardour to make music because it works better than any other DAW on the market, gets more regular updates, and the devs are responsive to user feedback about their creation.
Keep up the good work Paul and Robin, and I’m super stoked for the next version release. I know from talking to the LSP guys that there’s at least one feature - classifying the LSP Multisampler Plugin as an instrument rather than a plugin - that I am so excited for I’m actually debating about how to build the nightly version from the source code just to have that. Super excited to see what else will be there, when you feel it’s ready for us. In the meantime, don’t worry too much about the GUI until ALL the core functionality you want is there.
2 Likes
You can sort of do that now. Detach the mixer and editor to separate windows and you are left with just the transport. You can then shrink that window and put it on the bottom. Or, use an OSC program like touchOSC on your phone and put the transport controls there. There are some touchOSC layouts out there already that have some of the transport controls on them.
Also see window->transport controls which gives a small transport window you can put anywhere.
That’s cool. I already have been playing with the websockets experimental server a bit and that is way better than TouchOSC or Open Stage Control for what I want. I’d also like to say that being able to move toolbars and stuff around is the smallest shit compared to getting the MIDI implementation fully functional.
I don’t know if Linux has anything like AutoHotKey, as on Win I can make any GUI that will sit “Always On Top” and it will send keystrokes or menu commands to the application:
WinMenuSelectItem, ahk_class TBandWindow, , Play, Stop
This makes no sense to discuss as a “Linux thing”. It’s down to the behavior of a window manager, of which there are dozens, most of them highly configurable.
Just as we speak that’s what I’m making for Band In A Box, as when I go into a few dialogs I can’t access the main window to play/stop so I send it from the AHK GUI to the menu
WinMenuSelectItem, ahk_class TBandWindow, , Play, Play
WinMenuSelectItem, ahk_class TBandWindow, , Play, Stop
linux does have autokey-gtk, but I think your workflow can work better if you adapted to plugins that can use MIDI control messages… I don’t know anything about Windows plugins, because everything I use is rather on the Linux Desktop that imho is very versatile and customizable, so also this bleeds the question as to what it really is about, as you can do ‘Always-on-top’, but I don’t see how that is connecting to largely a non-Linux application.
What Paul is referring to when he says “window manager”, is around the fact that there are many different “types of Desktops” that have their own global keyboard-shortcut system for performing Window-Minimize, Maximize, etc… “window manager” in more technical detail also means more user-customization plumbing – as it really refers to a “component” of the “Linux Desktop” that can do anything from automatic-tiling, 3D cubing effects, wobbly windows, and perform “Always-on-Top” tricks. Since there’s a million ways of doing this on Linux, there is no possible way to have a quick nudging answer on “what” way this can be done than for another user here(longtime user of Linux) to confirm yes…yes Linux can do that too.
You briefly mentioned about Autokey-GTK way back in January 2020 – and to my surprise when reading up about everything you write – it was actually you who brought it up.
I think your problem, is you are overwhelmed with other aspects that are interfering into applying the technology provided to you.
From it looks like you bounce between being a Mac user and a Windows user.
But never have tried Linux… but you bring up about “Autokey” 9 months later for Linux.
** scratches head **
no point in giving any more attention to these types of users imho…
my two cts…
The reply was for “that scripting GUI things might be able to do, is do things like move the transport bar to the bottom of the screen instead of the top.”
AHK was suggested because there is no GUI scripting in Lua.
I remember I tried AutoHotKey to access the menus in Win Ardour, but it’s not a standard menu, and then I found you can only have so many scripts available in the menu choice so that ruled out using AHK.
Going from Win to Lin to Mac is because I wanted port ReaTrak over to not just Win Ardour but Lin & Mac.
“no point in giving any more attention to these types of users imho…”
I’m not charging $$ for ReaTrak, as I have said it will be a real task to do to port over, and that’s what you say, get the hell out of here and don’t come back ? nice…
1 Like