I want to be part of it

hello everyone, hello developers,

I am a professional music producer and an amateur programmer. I can program in Assembly and C, although I am more comfortable with Asm at the moment.

I think Ardour is a fantastic project, congratulations to Paul and his co-developers.

I don’t know exactly how, but I wished to contribute to the project. With the Corona thing, I intent to give the code some nice study and taste the waters.

The thing is, I’m on Windows and I’ve read that compiling it on Win is a big hassle. Should I set up a Linux box for this? Or should I be fine compiling it with Visual Studio?

regards Alex

1 Like

Hi Alex,

Thanks for you interest and enthusiasm.

For which CPU architecture do you write asm? Intel? Arm?

Most of Ardour is C++, since Ardour runs on many different CPU architectures (ARM 32/64, PPC 32/64, SPARC, …) there is very little, and only optional asm code in Ardour’s codebase.

Since I have no first hand experience with Windows, I cannot answer this question.

@John_E compiles Ardour with MSVC and maintains Ardour’s MSVC project, he also maintains MSVC projects of some of the built dependencies on his github account.

We use mingw to cross-compiler Ardour windows binaries on GNU/Linux.
I hazard a guess that getting started with Linux will be a lot faster. It could be under 20 mins to install Debian or Ubuntu in a Virtual Machine and get going:

sudo apt-get build-dep ardour
git clone https://github.com/Ardour/ardour.git
cd ardour
./waf configure --strict --cxx11 --with-backends=jack,alsa,pulseaudio,dummy

done. Run from source-tree without install as cd gtk2_ardour; ./ardev

PS. most devs are online on #ardour IRC.

1 Like

Hi Robin,

For which CPU architecture do you write asm? Intel? Arm?

I write Asm for Intel architeture. I’m fluent in Masm, but used in fact UASM, which has the Masm syntax. As far as I know, UASM builds to Linux too. I am going to check this, never tried anything related to Linux.

Most of Ardour is C++, since Ardour runs on many different CPU architectures (ARM 32/64, PPC 32/64, SPARC, …) there is very little, and only optional asm code in Ardour’s codebase.

I see… But I could also be useful in some other areas, “I think”. It is worth trying anyway.

@John_E compiles Ardour with MSVC and maintains Ardour’s MSVC project, he also maintains MSVC projects of some of the built dependencies on his github account.

Hopefully John chimes in! Although I do have Visual Studio installed, I program in Sublime or Visual Code.

I hazard a guess that getting started with Linux will be a lot faster. It could be under 20 mins to install Debian or Ubuntu in a Virtual Machine and get going:

That’s really tempting… but scary… I’m used to my debugging tools and environment. But in the long run this would make more sense I guess

PS. most devs are online on #ardour IRC .

I know, but I thought it would be better to to have this intro chat here before

Robin, Thank you very much for your reply!

Possibly. Ardour itself doesn’t do a lot of DSP. It’s mainly just summing and metering. For those methods there is existing SSE and AVX code, with a fallback C/C++ implementation. Ssearch for *.s in libs/ardour. The current methods are bound in globals.cc

You may be able to identify cases that could benefit from a custom asm code (RMS meters perhaps).

As for building on windows, it would be great if we could ship something like a docker image that has all the dependencies ready for VS/MSVC. Any ideas how we could provide this?

Our cross-compile stack is also mostly useless, since mingw and VC are not compatible. While it does allow to compile Arodur on Windows with mingw, it’s not very useful since it doesn’t integrate nicely with user-habits (“debugging tools and environment”)…

1 Like

Hi LordAdef - I first got involved with Ardour around 14 years ago when Harrison asked if I’d help them run Mixbus on Windows. My first approach was to use a product called Cygwin (essentially, a way to run Linux apps on Windows). Cygwin was pretty successful although support for it was quite poor so it was a steep learning curve (and I wouldn’t recommend it). A big plus at the time was that most of the dependent libraries were offering ready-made projects for building with MSVC (Visual Studio 2005 at that time). So I switched to that approach and managed to make it all work. I still maintain the old VS2005 projects although nobody really uses VS2005 these days (not even me!)

A few years later a company called izCorp managed to build Ardour using VS2012 but AFAIK nobody’s managed to build with anything more recent. Part of the problem is the library dependencies. MSVC isn’t cross-platform so very few of them support MSVC any more. If you go down the MSVC route you’ll be in for a hard time (especially if you’re inexperienced with C++). As a first move I’d recommend you should check with each library and ask if they even have pre-built modules and header files available for MSVC. And keep in mind that Ardour doesn’t necessarily use the latest library versions (for example, it’s still running GTK version 2).

Currently though, gcc will be a whole lot easier. That’s what the developers themselves use so there’s a good chance of being able to get support and assistance along the way. Then (if you decide to switch to MSVC at a later stage) you’ll at least have some experience under your belt. I’m secretly hoping that one day Ardour will switch to Clang. AFAIK Clang is compatible with waf - and on Linux and Windows it’s now compatible with Visual Studio (though not for OS-X just yet). Using Clang + Visual Studio I’ve even managed to build some of the support libraries and it worked like a charm!! So one day in the future, Clang might offer us the best of both worlds!! And whatever route you choose… good luck!!


Windows Subsystem for Linux might be something worth looking into. You may still be able to use some of the Windows tools you’re familiar with whilst using a GNU/Linux build chain. I don’t know for sure though as I don’t work with Windows. I hear WSL is getting pretty good nowadays.

1 Like

We won’t switch. It’s just another compiler option. Ardour does and should build with most C++ compilers. Clang is already used for the complete build-stack and Arodur itself on MacOS, as well as for static analysis on Linux. For Ardour itself it should be possible to directly generate a VC project using ardour’s waf build system again.

From my perspective it looks like build systems of the build-dependencies are the problem.

In particular autotools which is used by most libs doesn’t directly work and needs msys on Windows. Mid/long term meson will hopefully sort that out. Many of the libs that Ardour depends on have already migrated to meson. That way only 2 or 3 projects (like gtk2) will need to be ported manually.

Is there an established container/image, chroot environment that could provide a build-system (pre-compiled libs, headers, SDKs)? Something we could prepare (once), and provide to get windows devs started.


1 Like

I remember Todd started work on this many years ago. I could be wrong but for some reason I thought it had gotten abandoned?

Not for VC++ - one of the problems (historically) was that you couldn’t link modules written in a particular VC++ version with modules written in some previous version. It’d work okay for ordinary ‘C’ but not for C++ (because each version had a different name mangling scheme).

However… I just compiled libpbd with VS2019 to see if that’s still the case and I was surprised to find that it isn’t. I didn’t manage to link successfully but there were only 2 x unresolved externals. So (unless Microsoft is fooling me…) it looks like they’ve maybe done some work to consolidate all this stuff. And if that’s the case it might be feasible now to create a container with pre-compiled libs and header files. It might be worth asking some of the glib/gtk devs as they’re likely to know what the current situation is.

1 Like

We have recently (January 2020) updated waf to version 2.0.19 (from 1.6.11) due allow building with both python 2 and 3. – The version that we use now, apparently works for fine to create VC projects for LV2kit. It may need some work to tweak Ardour’s wscripts, but it’s probably easier than it was 8 years ago

Anyway for Ardour itself, it’s probably not a big deal to maintain a separate VS project.

That’d be great!

1 Like

Hi Robin and John!

Nice conversation, by the way.

I know the strains and the in house position on this already. But maybe, a group force could be gathered to get a native Windows compilation ready. Although I would be the least useful man, I’d like to join in.

Hopefully John gets excited about it.

By the way #1: just for the kicks, I tried to build the MixBus3 solution in the source, with VS2017. I thought I would get more errors. I wouldn’t mind posting the error monitor for you guys.

By the way #2: I found an inconsistency in the Mackie MCU pro interface behaviour (I own a MCU Pro + MCU XT). I might try to fix that myself, somehow (once I manage to compile the thing)

If you’re building from my solution file you’d need to be building against my specific versions of the support libraries:- https://github.com/johne53?tab=repositories

The first one to get built is MB3Proxy-libintl - maybe try building that one and see how you get on. The others all have a page of build instructions (which that one doesn’t have for some reason) but IIRC it’s quite a simple build.

[Edit…] BTW… it’ll probably go easier if you use the same directory layout as me:-

your drive:\+GTK-SOURCES\gnu-windows\src\MB3Proxy-libintl

1 Like

LordAdef - I’ve pushed some small changes to Ardour git which might help you compile with VS2017. This is only a small test so I’ve only updated the pbd branch. You should start by building the target that’s called Release 32 with Debugging Capability. Of course, it might not compile if you’ve installed someone else’s version of the support libs so in the longer term (assuming you want something that’ll eventually link and run) you’d need to build my support libraries like I mentioned yesterday.

gcc and waf would almost certainly be a simpler way to start though… :slightly_smiling_face:

1 Like

thanks John! I’ll try that.

please allow me some noob questions:

Cygwin or MinGW (it’s all new to me)?

Lastly, is your Mixbus3 solution equivalent to Ardour 5?

My projects can work with the current version of Ardour but they don’t use the current version of Visual C++. Here’s a bit of background information…

Many years ago, I created my projects (along with my customised dependency libs) to build an early version of Mixbus with a much earlier version of Visual C++. But VC++ isn’t cross-platform - so eventually it got superceded in favour of gcc and waf. VC++ no longer forms part of Ardour’s development strategy (and in fact I’m not part of the core development team any more - I’m really just a peripheral contributer).

As for Cygwin and minGW - I don’t think either of them gets used in Ardour development. I’ve a feeling that the current Windows stuff gets built in Linux using some kind of cross-compilation system. It might involve a related technology (such as ‘Wine’) but I don’t know for certain. Robin and Paul will have more info about this.

If you’re keen to get involved quickly with Ardour, Visual C++ really isn’t a simple route. You should consider cross-compiling with gcc and waf because that’s how the current development works. Later (once you’re more experienced with Ardour and C++) that’d be a much better time to experiment with VC++ and maybe bring my old projects up to date.

1 Like

nice John! And thanks for tour patience.
I will do my homework and see what I can achieve.

Yes. mingw is used to cross-compile Ardour. The compiler runs directly on GNU/Linux, and produces windows binaries. The NSIS installer also has a Linux version that can create windows installers.

Wine would be needed to run Windows applications on Linux. It is not required to build and package Ardour, although we have used it to run unit-tests.

The nice part of this is that it works reliably, can be scripted for CI/CD and provide nightly builds.

It’s not impossible to build Ardour on windows using a similar toolchain: https://guysherman.com/2015/08/16/building-ardour-on-windows-with-msys2/ but for the case at hand that’s likely not helpful.

1 Like

FWIW these are the lines causing the unresolved externals (in StandardTimer::connect() and BlinkTimer::Connect() respectively) -

return m_signal.connect(slot); - and...
return m_blink_signal.connect(slot);

I don’t know if it’s because ‘slot’ in each case is const (haven’t had time to investigate too deeply). But linking VS2019 code to C++ libs from a previous version does at least seem ‘do-able’ now… :raising_hand_man:

1 Like

Hi John!

your drive:+GTK-SOURCES\gnu-windows\src\MB3Proxy-libintl

The first one to get built is MB3Proxy-libintl - maybe try building that one and see how you get on.

On this (VS 2017, on Win 10):

issue 1: VS complaint there were no “intl.props” file. There was a “intl.props.in”, so I made a copy of the 2 “props.in” in there and removed the “.in”. Seemed to work

Here is where I am:

1>------ Build started: Project: intl, Configuration: Debug Win32 ------
1>cl : Command line warning D9035: option ‘Gm’ has been deprecated and will be removed in a future release
1>c:+gtk-sources\gnu-windows\src\mb3proxy-libintl\libintl.c : fatal error C1083: Cannot open include file: ‘@TargetSxSFolder@\targetsxs.h’: No such file or directory
1>Done building project “intl.vcxproj” – FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

ps: I just realized you have some extra files at your Github. Going to search there

Oops - there’s a few preliminary stages I forgot about:-

Before doing anything else you need to edit the file called local-paths.lib which you’ll find in the top level folder. IIRC you just need to change F: to your own install drive - so if you installed my code on D: - change F: to D:

Now open a DOS Command Prompt and navigate to the folder where you installed my code:-

and now run the following command (which requires you to have perl installed)-

Then (like I mentioned earlier) be sure to build the target called Release 32 with Debugging Capability before attempting the others. You’ll also need to have python installed for some of the later stages.

There’ll probably be quite a few drawbacks like this at first :grinning:

1 Like


Python on my computer… argh hahaha