Windows?

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?

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

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

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 … :frowning:

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

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… :frowning:

… 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 … :wink:
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

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

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

@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

PhilR: if you read thorgal’s posts above, you’ll find you can try the Linux version of Ardour on Windows. As has been mentioned before, our existing developer community has no experience with Windows nor any desire to gain it. If you read the whole thread, and the other 2 or 3 on the forum on the same topic, you will also find that we (or perhaps its just me) have serious concerns about what a Windows version would do to (a) the existing community (an existing quite technical and proud of it group overrun by a 10:1 ratio of mostly very non-technical (and assertively so) users) and (b) our ability to provide support. Doesn’t mean it won’t happen, just that its really not on our core roadmap. The benefits to us would be limited to possibly enhanced revenue and the tradeoff would be a massive increase in support efforts for a system that none of us use.

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 … :wink:

Thanks,
Peter

@NickNameX

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

   Seablade

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

Has anyone tried running it under AndLinux? http://www.andlinux.org/ Like a virtual machine, but a bit more native (and doesn’t support 64-bit yet.)

hi, just read a little about andLinux. It runs ALL linux apps in ONE windows process. Not sure this would provide a stellar performance … but I did not know about andLinux and I can certainly try to use it for other purposes! thanks for the tip :slight_smile:

actually, it works :slight_smile:

I used jack2 svn on andLinux, using the net driver, and jack2 for windows on winXP pro, using the portaudio driver, and the netmanager loaded at startup. I recorded some rubbish from my laptop mic. I ran jack2 at p1024, n3, r48000. No prob. My laptop being limited in resources, I did not try to get very far :slight_smile:

Not sure what you can really do like this. andLinux remains linux, so you’d better have a real linux machine for running ardour optimally but with this setup you can add some windows jack clients to the graph and record in the “virtual” ardour. Get a powerful PC though :slight_smile:

Yes, that’s more or less what I was intending to encapsulate in my shorthand above. You can bang on about C/U ratios all you want, but that’s just a wordier way of expressing the legendary standoffishness of Linux people towards - well - anyone who isn’t a software engineering graduate. It’s preposterous, of course, and denies the entire purpose of computers, but it’s richly ironic to produce something like a DAW and then complain that non-technical people want to use it. Of course they do, they’re audio production people, who are by and large not software engineers. I suspect, conversely, that you are not an audio production person, but I also suspect you would not accept that as a legitimate profession because it isn’t software engineering. It’s been said a million times, but I’ll restate it here: attention, Linux world. Not everyone is a software engineer, nor will it ever be so, nor is it desirable that it is so. Your dogged persistence on this is the reason the platform has failed and continues to fail to be widely used as a desktop OS.

But really, Paul, if you want people to stop using Windows, forget Ardour, and start fixing some of the myriad problems that prevent people from using Linux. That would be a much more productive and useful application of your time. One of the last things that would stop me moving to Ubuntu would be the lack of a Protools clone, and this typifies the problem. Linux people need to stop writing DAWs and 3D effects for the window compositor, and fix the package manager, for instance. Priorities, people.

I simply don’t understand. You spend weeks and months and years writing this stuff, then you behave in a deliberately prohibitive manner when it comes to letting people use it. This isn’t an unusual attitude; almost all opensource projects seem to treat finished software as a sort of object d’art as opposed to a means to an end, and I find it completely unfathomable. What do you think computers are for?!

P

Well, that’s the first time I’ve ever heard an opensource developer openly admit that he wants to exclude anyone who isn’t a software engineer.

I suppose I should be grateful for the honesty, really.

@PhilR: that's a completely unfair characterization of what I said. Most of the users of Ardour on Linux and OS X are not software engineers. The Linux community is generally much more technical in their orientation - one can argue about why that is, but it remains a fact one way or another; the OS X community tends to share an approach of "if it works, I use it, otherwise I toss it away and never mention it again". The Windows community doesn't fit either of these characteristics.

If you'd like more background on the issues with Windows support, I suggest you read this post by the lead developer of Inkscape (a program quite a lot like Adobe Illustrator): http://www2.bryceharrington.org:8080/drupal6/node/41

I personally find it quite strange when people who use Windows appear to "expect" developers of software to make it work on their chosen platform. I'm not sure why its hard to grasp the idea that rather than deliberately choosing to exclude Windows, we're actually just trying to develop software for the computing platform that we feel to be more appropriate to our needs. Ardour wasn't written to be "the DAW for everyone". It was written to be the DAW for people who use Linux; it turned out to be easy to port to OS X, and so we did, and thus were able to provide a hopefully-useful tool to a second community. Maybe one day, someone will finish grappling with all the difficulties of porting it to Windows, and then it can provide the same to that community as well. But in not doing this, we are not criticizing or seeking to exclude Windows, but rather are just focusing on the actual goal of providing a really good DAW for platforms that we want to use ourselves.

@PhilR

I can tell you, you are completely off base, and completely misrepresenting what was said.

You can bang on about C/U ratios all you want, but that's just a wordier way of expressing the legendary standoffishness of Linux people towards - well - anyone who isn't a software engineering graduate. It's preposterous, of course, and denies the entire purpose of computers, but it's richly ironic to produce something like a DAW and then complain that non-technical people want to use it.

That isn’t it at all, and you are completely misunderstanding open source or intentionally misrepresenting it in this statement.

The point Paul has brought up, and I think is a valid point, though John’s work may work to disprove it somewhat, is that no current developer other than John runs Windows, and the major contributors do not(Not attempting to downplay John’s contributions here, more recognizing the massive contributions by others at given points in times). As such releasing a windows version to start with requires major work, work that John is doing at the moment. But then going through and SUPPORTING Ardour on Windows requires even more work. Not only must you develop and test on windows, which triples the testing required for every patch, not to mention the amount of work spent doing the actual coding, but you must also discern reports of all qualities. The latter part exists on all systems, but is exactly what the numbers Paul mentioned provide, an indication of the ratio of quality of bug reports and testing on all platforms.

...but I also suspect you would not accept that as a legitimate profession because it isn't software engineering.

Knowing Paul you are flat out wrong. I will let him speak to the former accusation in that sentence if he chooses to. The latter I know from conversations with him. I am a professional audio engineer, I work on many different scales, and in many different areas of the field. For the record, I am a sound designer that has worked in theater and animations, done work for commercials to pay the bills, recorded and released CDs, and consult on system design. I am also someone that has contributed code back to Ardour on occasion when I had time to do it myself, but can also tell you that Paul has been amazing in his support of Ardour at times, providing me with versions of Ardour that fix issues I have had within a matter of days to allow me to complete projects. Me being someone that understands or submits code has little to do with that, but instead is the willingness that I had to let him work with me to troubleshoot an issue in many cases, and compile a new test version, and test, rinse and repeat till we found the cause.

But really, Paul, if you want people to stop using Windows, forget Ardour, and start fixing some of the myriad problems that prevent people from using Linux. That would be a much more productive and useful application of your time. One of the last things that would stop me moving to Ubuntu would be the lack of a Protools clone, and this typifies the problem. Linux people need to stop writing DAWs and 3D effects for the window compositor, and fix the package manager, for instance. Priorities, people.

This statement is a strawman in this conversation that has little to do with Ardour or Paul. However that being said, I can tell you flat out that if tools were not available for me to do my work on Linux, I wouldn’t use it. If Ardour didn’t exist, I likely would never have used Linux as an full time audio production platform, nor would I be looking at returning to it full time again here in the near future(Currently on OS X). If the tools don’t exist to do the work that is needed on Linux, then people should rightly not try to switch to Linux, period. It won’t help them get the work done.

I simply don't understand. You spend weeks and months and years writing this stuff, then you behave in a deliberately prohibitive manner when it comes to letting people use it.

Hardly, he has not said that people that want to can’t work on getting it to work on Windows, John’s work is evidence of this enough. He has said he won’t support it at this time, which is understandable since he doesn’t run Windows to be able to support it first off, and secondly requires a significant investment in time that takes away from the primary development of the tool.

Seablade