Would it be possible to have a version of this for windows?
Just signed up to add my voice to the call for windows compatibility! We have Protools right now and are not big fans of it; it would be nice to at least be able to try Ardour out.
I have no particular objection to Linux but this is a self-supported environment where I just can’t deal with the extra time and messing about it costs. Or we could completely re-equip with apple macs, I suppose…
At least not any time soon and probably not until there is a concerted effort from windows developers over a long period of time to show an interest in supporting it. None of the current devs are Windows based to my knowledge, and thus supporting Windows would not be worth the headache it would cause.
I know John E has some windows programing experience…
Yes but check the key words there;)
“not until there is a concerted effort from windows developers over a long period of time to show an interest in supporting it”
John does program in Windows and I believe has even done some Ardour hacking in windows, but that doesn’t mean he has shown a concerted effort over a long time to be the sole supporter of Ardour on Windows:) (John can of course correct me if I misunderstood him)
There was a long thread some time back about Ardour being cross platform which goes into great detail that I don’t want to repeat here on why Ardour does not run on Windows. I gave the extremely short summary version.
Here’s a summary of where I’m up to with a Windows port. I first managed to make Ardour run under Windows about 18 months ago although, strictly speaking, it was running under Cygwin and not directly under Windows (for those of you who aren’t familiar with Cygwin it’s a special build environment that aims to provide the POSIX functionality that’s missing from Microsoft’s own development environment. Many projects from a Linux or POSIX background can be built under Cygwin with little or no modification). Once up & running, Ardour-Cygwin runs like a dream - except that I’d had to disable any midi stuff (just through not having enough time to get around to it). Recording, playback, editing and most other functionality worked just like they do under Linux. FWIW, anyone who wants to try building Ardour under Cygwin can have my code, which is roughly at about version 2.6 - but there’s a caveat…
Ardour (in all seriousness) worked great but Cygwin did not. And that was a problem - because Cygwin has one of the most unhelpful development communities that its ever been my misfortune to encounter. It’s little wonder that you rarely (if ever) see Cygwin projects being distributed commercially. As an academic achievement Cygwin is a fantastic technical success but as a reliable runtime environment it doesn’t (quite) work well enough. And the astonishingly unfriendly support team are a major letdown. But lastly (with no disrespect to any Linux “apps” programmers) Cygwin suffers greatly from a problem I’ve noticed often among system programmers - namely the belief that “you should never fix the basic ‘system’ if it’s been fundamentally broken for a long time.” I’d be more than happy to donate my source code to anyone who wants to experiment with Cygwin but I’m not “genned up” enough about Cygwin to support it. And be warned… Cygwin grows and grows. Over two-thirds of my C:\ drive is now taken up, just for Cygwin!
What the exercise taught me though is that Ardour’s dependence on POSIX is, to a large extent, unnecessary. It isn’t totally unnecessary but the POSIX (and C99) dependencies can often be replaced from ANSI or STL. This opens up the possibility of developing a Windows version that can be built using Microsoft’s own development tools and yet still be 100% compatible with gcc. There are significant advantages to doing this - especially so in the area of debugging. gdb is like something from the stone age compared to Microsoft’s VC++ debugger. Having said that, VC++ does present its own set of problems and currently, there are three problem areas in particular which, oddly enough, all begin with the letter ‘p’. Paths, pipes and polling.
Windows paths are a lot different from their Linux style counterparts but I’ve done enough work in that area to know that this problem is easily solvable (time consuming, but easy)… In fact, I can compile, link and launch Ardour (all built with MSVC++) and I’ve even sent a few people some screen shots. The other problems aren’t quite so simple though. ‘pipe()’ under Windows is blocking by default and (frustratingly) can’t be made non-blocking. Polling is a no-no and is heavily discouraged by Microsoft (in fact, ‘poll()’’ isn’t even available as an API call). Currently I’m in the middle of writing my own custom strategy for pipes & polling. I’ll know in about a week whether or not it works. If I can get to the stage of replaying audio, I’ll know that a full, standalone Windows port (without any reliance on Cygwin) is almost certainly possible.
As for future support, Paul has given me a lot of encouragement but Paul is already very busy with the Linux and OS-X stuff. Therefore much will depend on building up a community, just as has happened for the Linux and OS-X versions. Developers with experience of midi and the WinMM system would be especially welcome. As would developers who enjoy working from the command line (which, generally speaking, I don’t). The main reason for this is that there’s currently no consistency in the way the supporting libraries have been built (gtk / boost / cairo / libpthread / libxml etc). For the sake of convenience I’m currently using the official binary distributions but some were built using VC++6, some with VC++8 and some with MinGW. It’s very much a lottery although I’m managing to work around it at the moment. At some stage though, all the supporting libs will need to be rebuilt from scratch using the same compiler.
So there’s a lot of work still to be done before anything could be released. It’s too soon yet to need any testers but if anyone else wants to contribute, feel free to contact me.
ndiniz, Ardour is Linux only.
@forat.it: once again, you are back repeating falsehoods. Ardour runs on Linux, OS X (Tiger, Leopard and SnowLeopard), FreeBSD and Solaris. Some developers have had it running on Windows. If you continue to assert this FUDish material, I’ll be forced to delete your posts, and I would prefer not to do that.
Sorry… Ardour is UNIX only: better ?
We already discussed this and, if i have understood well, Ardour is not that portable 'cause it’s “chained” to UNIX world since its born and now it’s “too late” to unchain it.
So my request is simple: if someone asks for a non-UNIX port, please redirect to other open source projects that may need help to grow.
More competitors, more fun !
@forat.it: do you not even read the threads you participate in? A few replies above yours is a long description from JohnE describing how he has (recently) got Ardour (partially) working on Windows. I’ve also described to you in the past how Tim Mayberry, as a Google Summer of Code project in 2006, also got Ardour running on Windows. More competitors (though I prefer to think of it as choice) is always welcome, but not as the result of the kind of falsehoods that you’ve repeated more than once on this forum.
@forart.it: why do you keep on writing things that, as Paul crearly stated, are simply not true?
Apart from the fact that Traverso is a nice app, but can do 1/100th of what Ardour is capable of, John E, just before your message (supposed that you read what the other members writes), explained that Ardour can run on Windows with just few issues. Is Windows UNIX-based too?
The fact that there is not a Windows port is simply a matter of lack of a community of developers. If you feel the need to post compulsively every time we talk about a Windows port, why don’t you jump in and help John in supporting a Windows version? Here lies the beauty of open source software…
@John E: my programming skills are too weak for the moment to help you with the code (I am currently learning programming in my spare time), but if in the future you need testers or people with minor knowledge of C++, count on me. I am a happy Linux user but I also run Windows (2008R2) to use VST instruments properly.
Thanks, I’ll keep that in mind. It’s about 18:30 here (UK time) and I think I’ve (just) managed to create a custom, pollable pipe for Windows. I’ve got two long days at work now (tomorrow and Friday) so I’ll hopefully be able to test it all at the weekend. Keeping my fingers, toes and everything else firmly crossed!!
To be clear (from http://www.cygwin.com/):
What Is Cygwin?
Cygwin is a Linux-like environment for Windows. […]
What Isn’t Cygwin?
Cygwin is not a way to run native linux apps on Windows. You have to rebuild your application from source if you want it to run on Windows.[…]
Even if i don’t think that UNIX-like platforms are ideal for multimedia purposes, I don’t blame Ardour devs for their choices (it’s THEIR coding work, not mine).
BTW, I strongly believe that nowdays many big open source projects - as Ardour - needs to do a step beyond: platform indipendency.
The “reinvent the wheel” every time seems not a good evolution strategy to me…
In other words I would love to see more intra-collaboration between projects, but how ?
I believe that could be interesting to “detach” functions (such as, just for example, waveform drawing) into standalone/platform-indipendent libraries (C/C++ ?) in order to let any open audio application to use - and, why not, improve - it.
I’m an open source lover, but seems openess is more vertical than horizontal. (…hoping that you can understand what I mean…)
Suggested reading for you…
Namely, POSIX was invented specifically to address platform compatibility. Take a look at the list of platforms that mostly support this already and you will understand exactly why Ardour was built like this. I don’t know enough about John’s research here to be able to comment on his work on using things other than POSIX to accomplish this, Ill leave that to Paul and John to sort out.
So to be clear- There is no ‘reinvent the wheel’ for every OS as you seem to be suggesting, that is why Ardour is coded like it is. Instead Ardour takes advantage of fairly portable libraries(GTK+, Boost, etc.) and fairly standard cross platform OS interfaces (POSIX) in order to specifically avoid this.
I believe that could be interesting to "detach" functions (such as, just for example, waveform drawing) into standalone/platform-indipendent libraries (C/C++ ?) in order to let *any* open audio application to use - and, why not, improve - it.
You have obviously never looked at Ardour’s code. There is an entire directory of ‘libs’ like you describe. In fact many ARE external libs that Ardour makes use of. Things like audio analysis, VST/Wine support, surfaces, MIDI interaction, time stretching, etc. are all ALREADY built as seperate libs that the Ardour binary links against. And the exact examples you give wouldn’t make any sense as things like waveform drawing depend on other libs from GTK which seem to be the basis for half of your complaints, and on top of that are things that are very much tied to how Ardour does its UI in GTK, which most applications wouldn’t deal with as GnomeCanvas is a deprecated lib that even Ardour is looking to replace in the future.
@forart.it: finally, proof that you didn’t even READ JohnE’s post.
He specifically noted that he is NOT using Cygwin, and explained his reasons why not.
Also, your use of waveform drawing reflect exactly my position … before I started working on Ardour. The very early versions of Ardour did indeed use a generic GtkWidget for drawing waveforms. It soon became clear that what we need was so specific that no other program that didn’t make very similar design assumptions would be able to use or provide what we needed.
Finally, this: BTW, I strongly believe that nowdays many big open source projects - as Ardour - needs to do a step beyond: platform indipendency. is just pretty ludicrous, given the evidence in this thread that Ardour runs either completely or is in the progress of working completely on just about any platform you care to name. You continue to claim that Ardour’s code is “not cross-platform” with no actual evidence of this whatsoever.
forart.it - you probably misunderstood this from cygwin.com (their fault, not yours) :-
What Isn't Cygwin?
Cygwin is not a way to run native linux apps on Windows. You have to rebuild your application from source if you want it to run on Windows.[…]
That isn’t strictly true. It isn’t necessary for “you” (as in “every user”) to rebuild everything from source. Obviously, somebody somewhere has to rebuild it but once rebuilt, the binaries can then be distributed to others, just like any regular Windows program.
However, all this is academic. As Paul pointed out, I am NOT building Ardour using Cygwin.
last time I saw, ardour was linking against tons of 3rd party libs, most of them cross-platform.
ardour complies with POSIX, windows does not. Ask MS-Windows devs to fix their OS before asking for a windows port of ardour
on a parallel note, jack2 works on windows … how does the hat taste like, Paul ?
Heh read that link I just put up to the wikipedia article:) Windows has a variety of options to enable POSIX compliance actually. Or what John is looking into is skipping to POSIX apis.
Just a quick update about the “pipes, paths and polling” situation…
I managed to create a cross-platform pipe object which has solved the problem of Windows pipes being permanently blocking (and therefore unpollable). I’ve tested the code with Visual C++ and Cygwin, as well as with gcc, under Linux. It seems to be working fine in all builds and has greatly alleviated the previous problems with my Visual C++ build. Ardour-VC++ is now recording and playing back audio which is hugely encouraging.
I haven’t yet touched the “paths” issue - except to do enough to be able to load a session. Therefore things like waveform generation aren’t working at the moment (and no doubt a lot of other stuff that I’ve yet to encounter).
One immediate problem which Paul might hopefully understand is DSP usage. Ardour displays DSP usage whilst running. Under Linux my DSP figure is typically around 4%-5%. Under Cygwin that figure is more like 18%. But with the VC++ build I’m seeing 100% DSP usage, even with a newly created session with no plugins or automation. Obviously, that can’t be right.
I’m hoping this problem might be related to unfound paths. For example, if waveform drawing affects the DSP calculation, that would probably give erroneous figures because I know it isn’t working yet. Paul, do you know off the top of your head what kind of things affect the displayed DSP figure?
@johne: the DSP load figure is a measurement of how much of the time available to run the JACK process() cycle is actually used to run it. we start measuring as soon as JACK wakes up, and finish when all clients are done and JACK is about to go back to sleep to wait for the next time that audio processing is required.