Windows?

65 replies [Last post]
ndiniz
User offline. Last seen 4 years 5 weeks ago. Offline
Joined: 2010-03-12
Posts:

Would it be possible to have a version of this for windows?

seablade
User offline. Last seen 24 min 34 sec ago. Offline
Joined: 2007-01-22
Posts:

Possible yes.

Likely, no.

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.

Seablade

tbonedude
User offline. Last seen 1 year 51 weeks ago. Offline
Joined: 2008-11-08
Posts:

I know John E has some windows programing experience...

seablade
User offline. Last seen 24 min 34 sec ago. Offline
Joined: 2007-01-22
Posts:

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.

Seablade

John E
User offline. Last seen 15 weeks 2 hours ago. Offline
Joined: 2006-10-27
Posts:

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.

forart.it
User offline. Last seen 1 year 39 weeks ago. Offline
Joined: 2006-09-01
Posts:

ndiniz, Ardour is Linux only.

Move way:

http://www.traverso-daw.org/
http://www.experimentalscene.com/software/darkwave-studio/
http://www.koblo.com/ (if resurrects)

paul
paul's picture
User offline. Last seen 9 hours 22 min ago. Offline
Joined: 2006-03-16
Posts:

@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.

forart.it
User offline. Last seen 1 year 39 weeks ago. Offline
Joined: 2006-09-01
Posts:

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 !

paul
paul's picture
User offline. Last seen 9 hours 22 min ago. Offline
Joined: 2006-03-16
Posts:

@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.

interferon
interferon's picture
User offline. Last seen 37 weeks 3 days ago. Offline
Joined: 2009-07-03
Posts:

@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.

John E
User offline. Last seen 15 weeks 2 hours ago. Offline
Joined: 2006-10-27
Posts:

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!!

forart.it
User offline. Last seen 1 year 39 weeks ago. Offline
Joined: 2006-09-01
Posts:

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...)

seablade
User offline. Last seen 24 min 34 sec ago. Offline
Joined: 2007-01-22
Posts:

forart.it

Suggested reading for you...

http://en.wikipedia.org/wiki/POSIX

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.

Seablade

paul
paul's picture
User offline. Last seen 9 hours 22 min ago. Offline
Joined: 2006-03-16
Posts:

@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.

John E
User offline. Last seen 15 weeks 2 hours ago. Offline
Joined: 2006-10-27
Posts:

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.

thorgal
User offline. Last seen 1 year 20 weeks ago. Offline
Joined: 2007-08-03
Posts:

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 ?

seablade
User offline. Last seen 24 min 35 sec ago. Offline
Joined: 2007-01-22
Posts:

@thorgal

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.

Seablade

John E
User offline. Last seen 15 weeks 2 hours ago. Offline
Joined: 2006-10-27
Posts:

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?

paul
paul's picture
User offline. Last seen 9 hours 22 min ago. Offline
Joined: 2006-03-16
Posts:

@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.

John E
User offline. Last seen 15 weeks 2 hours ago. Offline
Joined: 2006-10-27
Posts:

Hi Paul - I'll post this comment here in case you're having an Easter break and you can let me have your reply when you get back to work....

The problem with the high DSP count is now solved. When I first replaced the various pipes with my custom pipe object, I managed to miss one out (the user interface has its own pipe called 'signal_pipe' which I hadn't spotted). signal_pipe was still using the original strategy (in other words, under Windows it was still blocking) and that's what was eating up my available time. I've now replaced that one too and my DSP count has dropped from 100% down to around 8% which probably isn't too bad for Windows.

Currently there's still one obvious problem left though (i.e. one visibly obvious problem).

From John E:
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

When I wrote that a week ago, nothing relating to peak files was working at all. I wasn't even getting any peak files being generated - which I expected because I hadn't yet rationalised the appropriate paths.

Peak files are now working (at least in the sense of being generated) but strangely, I don't see any peak waveforms superimposed on my timeline regions. I'm assuming (perhaps wrongly) that if a peak file exists for a particular region, it must get opened along with the session and its data will get analysed to produce the visible waveform. And as an educated guess, I'm assuming that the read path must still be wrong and all I'll need to do is find it and correct it. The problem is that I can't see where the peak file ever gets opened. I can see how it gets created if it doesn't already exist and I can see where it gets modified if the audio data changes. But I can't see what opens an existing peak file so that a visible waveform can be generated from it. Can you let me know where the 'open()' functionality resides?

paul
paul's picture
User offline. Last seen 9 hours 22 min ago. Offline
Joined: 2006-03-16
Posts:

@johne: i don't do easter or breaks ... it would be much easier to continue this via email i think ...

John E
User offline. Last seen 15 weeks 2 hours ago. Offline
Joined: 2006-10-27
Posts:

No problem Paul. I've just re-posted on the Ardour Dev mailing list.

NickNameX
User offline. Last seen 2 years 28 weeks ago. Offline
Joined: 2010-04-07
Posts:

Hello John E,

I'm very interested in seeing You having success
porting Ardour to Windows. I have the problem that
my firewire audio interface from ALESIS is still
not supported under Linux. And I don't want to wait
"forever" until ALESIS helps on the development of
the linux firewire driver .. :-(

I can't help that much on development as I speak "pascal" ..
If You have success one day then I would be very happy !

Thanks for Your good work !

Peter

John E
User offline. Last seen 15 weeks 2 hours ago. Offline
Joined: 2006-10-27
Posts:

Thanks for the vote of confidence, Peter. Ardour-2 is now up and running as a standalone Windows program. I've had to disable Midi (just because it isn't necessary for Ardour to launch) and I haven't yet looked at the issue of plug-ins (really, for the same reason). My approach so far has simply been to arrive at something that will record and play audio. That basic functionality mostly works but I'm only at the start of rudimentary testing and there's plenty of stuff that doesn't work! 'Undo' for example is currently crashing and waveforms weren't working, up until yesterday. Each day it's becoming more robust though and I'm very pleased with how easily I managed to build Ardour under Visual C++. There's still a long road ahead of me though.... :-(

NickNameX
User offline. Last seen 2 years 28 weeks ago. Offline
Joined: 2010-04-07
Posts:

>> .. I managed to build Ardour under Visual C++ ..

Oh .. just two weeks ago I deleted Visual C++ (a free, personal version from 2008 as far as I remember)
from my hardisk - I tried to rebuild parts of code from another OpenSource project .. and failed.

Well, will the ARDOUR webside offer the source code You've created one day ?
(In C language I'm far away from being able to help You on development,
probably some debugging, yes, but not more ..)

I have some experience in raw reading file structures, eg WAV, BWF, old Dbase3 .. ;-)
a little bit MIDI knowledge (rawreading file format MID, low level windows midi interface IO),
but all this is not what You're fighting with atm ..

Cheers,
Peter

John E
User offline. Last seen 15 weeks 2 hours ago. Offline
Joined: 2006-10-27
Posts:

Well, will the ARDOUR webside offer the source code You've created one day ?

Absolutely. If I arrive at something that I can release, it's a condition of the GPL that I release the source code too and Paul has indicated that he'd prefer to keep my changes within the main Ardour code base.

Of course, even though that's the ultimate plan, I can't say exactly when it will happen because a lot depends on me being able to get the code into a releasable state (and I'm still quite some way away from that...!)

tbonedude
User offline. Last seen 1 year 51 weeks ago. Offline
Joined: 2008-11-08
Posts:

But at least you made it work! Maybe we can even get NATIVE Vst support for ardour under a windows port (though it would be cool, I like the linux/ardour combo too much to switch back to windowz and its horrible firewire latencies...)

low-level
User offline. Last seen 4 years 5 days ago. Offline
Joined: 2010-04-09
Posts:

@JohnE: thanks for your good work and for your detailed reports.
In the past i read with interest some other thread regards the Ardour Windows port and leave these where slowly "sliping" about some kind of Windows vs. Linux war. Today discover this recent thread and i'm happy to read about the real possibility of extending the Ardout platform portability.
Thanks for all.

Low-level

NickNameX
User offline. Last seen 2 years 28 weeks ago. Offline
Joined: 2010-04-07
Posts:

Hello,

just 5 weeks ago when I asked but .. did You get forward with the windows version ?
Main issue is that my alesis ASIO device is not supported under linux
and I like it so much that I don't want to throw it away .. ;-)

Thanks,
Peter

seablade
User offline. Last seen 24 min 35 sec ago. Offline
Joined: 2007-01-22
Posts:

@NickNameX

It will be quite some time before anything is released for Windows most likely, I wouldn't hold your breath.

Seablade

paul
paul's picture
User offline. Last seen 9 hours 22 min ago. Offline
Joined: 2006-03-16
Posts:

@NickNameX: to reinforce what seablade said, any windows version is months if not years away, and even then its not clear that there will definitely be one. There is one person working on it as a side-project. None of the "core" ardour developers are involved in it directly, and none of us have anyreal motivation to get Ardour working on Windows. I hope this is clear enough.