50% load

[Brent Evans]

Oh, and by the way... how much does a programmer cost these days? $50k per year? $100k? Assuming you need that much too, that's a huge amount of software sales at $500 per customer. And you want me to help you with that by recommending a product that doesn't currently work properly on the hardware and OS I can buy off the shelf (as you like to say), oh, and LEGALLY buy of course... to run it so you can afford to fix it so it will?

Nope... sorry. Not my fault on that one. I was an evangelist for a while... I can't do that now. I have a career and reputation to protect too.

[kylesoundman]

10 years from now its going to be extremely difficult to find new hardware to replace the better functioning older hardware for SAC. Proprietary hardware is the only way to solve that permanently. Unfortunately, extremely time consuming and expensive to develop!
On the plus side of things I am experiencing more and more engineers willing to give SAC a shot so long as they have someone who really knows it to help.
Last engineer to use SAC only had two major complaints. No remote control of mic preamp gains, and no realtime remote control of 31 band eq’s. The first solvable with enough cash to throw at it, but the later is not solvable by anyone other than Bob. For a lot of engineers not having realtime 31 band eq is a huge deal breaker, regardless of the fact parametric eq’s are more surgical.

[mr_es335]

Brent,

I just happen to have quite a number of copies of non-OEM versions of Windows XP...some Home, Some Pro...with un-registered keys.

I bought these a number of years ago and they have just been sitting in my shop.

Just for interest.

[Brent Evans]

Brent,

I just happen to have quite a number of copies of non-OEM versions of Windows XP...some Home, Some Pro...with un-registered keys.

I bought these a number of years ago and they have just been sitting in my shop.

Just for interest.

Not everyone has that.

[Danny O]

I completely agree with you Bob...these people who want the sky(usually out of ignorance) , go into complete denial and most likely have never written a program(even a simple BASIC program) in their life. They have no idea that because of limitations of the language or the OS or both, you may eventually run into a brick wall, or at best have to put up with a significant comprise, or at worst do a complete rewrite. They have absolutely!! no idea how time intensive programing and trouble shooting is. These are NOT!!! excesses, these are the FACTS!!!...JACK!!!

Microsoft doesn't give a 'donkeys hind end' about SAC/SAW programs, or for any other third party programs for the matter. Yes they want you to write programs for their OS and if your program 'falls within the parameters' of their OS they may give you some support, but there are NO GRANTEES!. Their first priority is that their programs work on their new OS. Their clientele is the business and networking community, their clients stare at digital paper all day long. So these people who run down the street shouting Eureka!, Eureka!!.. Windows..8,..9,...10,......14 is here!..now all my programs will run better, faster...etc..etc...are in my opinion(as some one who has used Microsoft OS since the DOS days)...completely delusional. More often than not a new OS brings more headaches!...Look what happened to Windows Vista and Windows ME a decade earlier.

So far SAC/SAW have held their own with Microsoft's new OS, but as the OS's get fatter, more convoluted, Windows based DAW's like Windows Pro-Tools, Sonar, CuBase, REAPER..etc, will most likely have an effect on these programs too(if they haven't already)...Long live WinXP!!!

[Mattseymour]

All of the windows issues are precisely why Bob should have looked at moving his code base to Linux long ago, where a stable kernel that's capable of the realtime scheduling and prioritising the sac process would be possible. I guess the biggest challenge there would be driver support for third party audio interfaces, but at least the OS wouldn't be a moving target in the same way.

[Cary B. Cornett]

All of the windows issues are precisely why Bob should have looked at moving his code base to Linux long ago, where a stable kernel that's capable of the realtime scheduling and prioritising the sac process would be possible.

The use of the phrase "would be possible" tells me that such a "stable kernel" with the "realtime scheduling and prioritising" described does not now exist. This raises the question of who is going to write said kernel? Or are we expecting Bob to do it? Never mind that Bob is a supremely competent programmer, the amount of work involved in coding an OS is simply enormous.

I guess the biggest challenge there would be driver support for third party audio interfaces, but at least the OS wouldn't be a moving target in the same way.

Oh, yeah... that pesky driver thing. I personally have been waiting a long time for something called ReactOS, which has been under development for years, to reach the stage where it can actually be used. If it ever gets there, it might possibly be a viable replacement for Windows (which is the stated goal of the project).

And Linux is just as much a "moving target" as Windows. I know, having tried several versions of it over the years. It has improved with time, but still involves hassles in use that I do not have with Windows. I have bought more than one book to help me understand Linux well enough to configure it in the way I can with Windows, all to no avail. Linux is simply not the "magic bullet" that so many believe it is. It comes with its own special set of hassles, and until its configuration and file handling become MUCH more transparent to the user, I can't really recommend it to anyone for serious use.

I have one Linux box in operation, which is my media machine for the TV. I had some real hassle getting it to work in the first place, and now cannot update it because of drive space issues that will require me to do a "scorched earth" re-install that I am putting off as long as I can.

So, let's not have any more preaching of the Linux Gospel here, OK? Bob has already said he's not going there, and I'm sure I would agree with all of his reasons if I knew them. I have reasons enough of my own.

[cgrafx]

MenuetOS < 2 meg (written in asm)
SawStudio < 9 meg

http://www.menuetos.net/
MenuetOS v1.00 released just 10 days ago.

.

The problem with all the OS alternatives is going to be driver support for the audio interfaces. RME, MOTU, Behringer/Midas, Mackie, etc... all have essentially zero support for anything other than Mac OS and Windows.

As much as I don't like windows, they are at present the only open system.

I'd love to have a Mac alternative, but the hardware is effectively closed. Yes, I could build a Hacintosh, but then I'd be relying on 3rd party support to keep my system working. Additionally I'd be limited to an iMac or Mac Mini form factor with audio connected over Ethernet or Thunderbolt. Ethernet has promise, but is not there yet. Thunderbolt while functionally fantastic as a interconnect from a data standpoint, has no locking connector, so you'd have to manufacture a locking mechanism to ensure your interfaces don't get disconnected.

Yes, USB is also available, but I would NEVER build a live touring rig based on USB.

[Mattseymour]

Cary, distributions of Linux designed and optimised for realtime use already exist. Linux, including the kernel, is open source so you can make it do what you need, subject to the skills required, if creating a distribution designed for live sound there would be no need to update the kernel at all.

Linux is a moving target so long as you make it so, the point is you have a choice, unlike windows.

Given that Bob still considers xp to be the best platform for sac, building a custom Linux distro that is stable and never changes shouldn't be a problem.

When I say stable I mean in the development sense, i.e. code that works and doesn't get fiddled with unless necessary.

[Danny O]

It would be interesting if Bob could modify SAW/SAC to start in Windows SAFE MODE. He would have to rewrite the video and probably add a lot of API's. Then you would use only a sliver of Windows and SAW/SAC would almost be stand alone programs. You might loose a lot of windows convenience...but so what...what you lost, you would gain in speed.