I want to be part of it

Hi John!
I’m still here! Not giving up so far. I am still to build the last two things you’ve sent me. I am mixing a record this week and the VS project got delayed. I am getting back to it today

1 Like

Kudos for being persistent!

1 Like

Alex… FYI - I’m okay up until Weds (3rd June) but after that I’ll have very limited availability.

1 Like

Fine John, I’m working on the two libraries right now! Thanks once again!

John is amazing! His help has been absolutely fantastic

This is interesting. Is the process you guys are following being documented - or… scripted?

I have successfully built Ardour on WSL1 and built and run on an actual Ubuntu install. It took a couple of hours to get a build going for Linux, but it seems as though it will take a lot longer to create a successful x-compiling build from scratch.

Is the CI/CD script available to ease the pain?

This has been explained above, but just to reiterate: the current Ardour devs do Windows builds via cross-compiling on Linux, and we have a complete set of scripts for this which we don’t really advertise much if at all. That’s not because we’re trying to keep them secret but because we don’t want to support them in any way. We wrote them for our purposes, not as “the right way to build Ardour for Windows”.

In general, the Windows community participation in Ardour development is close to zero. If people did step forwards from that community/platform/environment and cooked up a “supported” sensible way to do stuff for Windows-based development, I’d be happy to make sure that ardour.org was there to support that effort. But we just haven’t see that at any time in the last 20 years.

While it would be fantastic having a documented and automated process for building with VS/MSVC, in the new WSL world cross-compiling is perfectly sensible too. I disagree with your reasoning about support burden since building is not supported already, I am not asking for support of any script and I am not implying that it is perfect or “the right way…”. It is however the current source of truth for Windows binaries.

Seeing precisely what’s built and what’s patched would be extremely helpful. Even if it’s not the actual scripts.

How can I view the repos at git.ardour.org, it requires a login?

git clone git://git.ardour.org/ardour/ardour

or use the github mirror at https://github.com/ardour/ardour

So just to clarify: we run a public git server on git.ardour.org but not a public “git wrapping website” (such as github, gitlab etc.). If you want the “git wrapping website” then the github site is the only option. If you just want the code, then either will do.

1 Like

Groan… I just tried to post a reply here and saw a message saying I’ve posted too many times and it’s time to let someone else have a say !!!

Heh automated systems, gotta love them. Actually truthfully I will say that Discourse has been a great platform for us to move to. In this case I think you are safe ignoring it:)

   Seablade

Yeah, my only criticism is that Discourse only sends me notifications if someone either replies to one of my posts or if they quote me. If they simply reply to a thread that I’m subscribed to, I don’t seem to get a notification (occasionally I do but mostly I don’t). Maybe there’s a setting I need to change somewhere??

Yes, in Discourse there is WATCHING and TRACKING for topics. You can set the default behavior by clicking on your user icon in the top right hand corner, and then clicking on your name, then going to Preferences>Notifications.

WATCHING will notify you for each reply I believe
TRACKING will notify you for direct replies and @mentions only.

This can be set per topic at the bottom of the topic where you have options to share, bookmark, flag, and reply, you should have a dropdown there to set Tracking vs Watching for that topic only.

So obviously I believe you are set to Tracking, you should probably set it and the default for you to Watching.

   Seablade

That was it Seablade - thanks !!

Anyway… I was hoping to make a suggestion to LordAdef (Alexdefaria) and Paul R. Part of the problem here is that there are essentially 2 ‘styles’ of programmer. Linux programmers often seem to prefer command-line tools - whereas Windows programmers (and maybe Mac programmers ?) tend to prefer IDE’s. But even after all these years there’s no cross-platform IDE support in Ardour. And (as Alex found out) there’s really no modern IDE support for any platform. Maybe it’s time to dust off Code::Blocks and give it another look?

Code::Blocks is a cross-platform IDE - but the drawback I guess is that there’s a ‘chicken & egg’ situation. The current build team are all command-line programmers - so they can’t offer much experience about building with an IDE. So until some IDE enthusiast steps forward, Code::Blocks and other IDE’s aren’t likely to get a look-in.

Just my 2 cents

Just because there is no support for an IDE from the team doesn’t mean that one can’t be used. I got Ardour compiling in Eclipse for instance a long time ago, but since then I have stopped using IDEs and frankly haven’t done much/any work on coding/debugging in Ardour lately due to time constraints.

While I believe you are correct in your assessment, having learned with IDEs to begin with what I find is it is more that IDE developers don’t understand command line approaches as that is often the only option taught on Windows and OS X, use an IDE – VS Code or XCode. But often times it can be easier when you learn hwo to utilize the command line to your benefit, to navigate/seach/etc. the code on the command line.

My own personal opinion, What I would think might make the most sense would be for people that want to work in an IDE to use the built in tools in git (Submodule or fork as appropriate, I suspect submodle might be bestfor this idea) to set up their own repo that they can maintain that would include the environment for that IDE and reference the current code of Ardour.

         Seablade

I would describe this a little differently.

The “command line tools” are actually the fundamental tools used in a build process. The compiler is … the compiler (modulo systems with more than one). No matter what your OS does in the GUI to hide or show this fact, the compiler is not a GUI-based application, even though it may be wrapped in one. The same is true of all the other tools we use as part of the build process. The linker, various text-processing facilities etc.

We know that people have different preferences for their toolsets, so our build system is designed to leave as many of those choices open as possible. If we create the build system around an IDE, then nobody can use any other IDE (or not use an IDE at all). We want people to be able to use an IDE, but also another IDE, and also no iDE.

So our build system (and general workflow) targets the most common denominator across anyone’s choices. There’s going to be a compiler, and a linker, and ways to invoke them. There’s going to be tools like python and/or perl, and a way to invoke them. However, by themselves, that’s not enough for a build system: we also need a way to describe the build process and dependencies. Again, if we do this using something built into an IDE, we’re shutting down choices. So we do this with a tool (currently waf) that shuts down as few choices as possible. Does it provide the same level of “integration” that us directly using an IDE does? No, it doesn’t. Does it leave the door open to people using different IDEs, or no IDE at all? Yes, it does.

This is not about “preferring not to use an IDE”. It’s about “we’re not going to tell you what IDE to use, given that an IDE is an optional choice and a compiler is not (or is much less so)”.

3 Likes

Just to be clear… I wasn’t suggesting that Ardour should move away from command-line development. Only that some programmers don’t like working that way - so if there was a cross-platform IDE available (in addition) maybe that’d help in attracting new programmers. You’re right though - once you start offering one IDE, devs will inevitably complain and start clamouring for some different one… :frowning: