Rant - software industry

[Miket156]

Great thread you guys. Microsoft keeps adding more and more "features" to Windows, and all it does is make it more complicated and I still don't get my work done any faster than what I did 20 years ago. If anything, I got more done (office applications) on my single tasking DOS based PC.

I "tried" using a MAC, sound modules, KB, and drum machine in the late eighties, but the Mac wasn't powerful enough and the more MIDI devices I added, the more latency I got. So I bagged that idea. I've been using workstations ever since. My recording needs are not anywhere at the level of a semi professional studio, but I can get the music I want out of my equipment. I turn it on, play. Press record, play. Add tracks one at a time, make corrections. Mix. MUSIC. Yep, I'll keep my sanity and let other people work on their computers. Its bad enough I have to use one at work.

Have a good weekend everyone.

Mike T.

[Synthoid]

It's all bull{censored}. Until someone can get windows out of the picture entirely and come up with a type of real-time kernel for music apps, it will always be this way.

Just what good old Bill Gates wants to hear.

[wades_keys]

Just what good old Bill Gates wants to hear.

Nah - Gate's goal was to have a computer in every household, running MS software.

He has largely succeeded.

His next goal, as stated in "the road ahead", is to unify telephone, multimedia/tv, and the computer.

Perhaps the XBox will morph into that.

But good luck getting Time Warner/Comcast out of the cable business - oh wait, he has a plan for that too, by creating his own satellite network...

[Synthoid]

Nah - Gate's goal was to have a computer in every household, running MS software. He has largely succeeded.

Yup.

[vanillawafer]

Ummm, hello, the hardware has software in it too.

[wades_keys]

Ummm, hello, the hardware has software in it too.

I guess you didn't get the point of my posts.

Bottom line: The bottleneck and main cause of latency, is the multitasking o/s that makes your PC, a PC.

The software (on hardware) you refer to is classifed as an embedded system - there is no multi-tasking o/s there.

Basically the code on a hardware device would consist of an endless loop and either polling for inputs or responding to inputs in real time by way of an interrupt.

In C/S terms, the behavior of such systems is deterministic - code can be timed and will always execute in that time slice. This is not possible with a multi-tasking o/s, like windows.

This is a big reason why a 4 MHZ ancient embedded cpu can respond to inputs with no latency.

[tim gueguen]

Hardware synth software coders also have the advantage of working with a fixed CPU and so on configuration. Software synth producers have no way of knowing every possible combination of stuff an end user might have their computer and how it will interact. So they have no idea that the new XYZ soundcard will cause their software to crash if its used with an ABC motherboard until it hits the market and a bunch of customers with that configuration start to complain.

[wades_keys]

Hardware synth software coders also have the advantage of working with a fixed CPU and so on configuration. Software synth producers have no way of knowing every possible combination of stuff an end user might have their computer and how it will interact. So they have no idea that the new XYZ soundcard will cause their software to crash if its used with an ABC motherboard until it hits the market and a bunch of customers with that configuration start to complain.

 

 

Good point and very true.

[Awake77]

I guess you didn't get the point of my posts. Bottom line: The bottleneck and main cause of latency, is the multitasking o/s that makes your PC, a PC. The software (on hardware) you refer to is classifed as an embedded system - there is no multi-tasking o/s there. Basically the code on a hardware device would consist of an endless loop and either polling for inputs or responding to inputs in real time by way of an interrupt. In C/S terms, the behavior of such systems is deterministic - code can be timed and will always execute in that time slice. This is not possible with a multi-tasking o/s, like windows. This is a big reason why a 4 MHZ ancient embedded cpu can respond to inputs with no latency.

 

 

I agree with what you're saying, and it would be spiffy if there was a way to allow music software developers direct access to the full power of a PC's hardware. That would come with it a whole other host of problems though - imagine trying to account for every possible hardware configuration, or trying to upgrade your hardware and keeping backwards compatability...

 

With the current state of PC hardware, it's really hard for me to believe that anyone with a modern PC or MacPro is having latency issues under reasonable conditions.

 

Of course, purchasing a nice PC and accompanying quality audio interface will set you back as much as a high-end keyboard based workstation...

[vanillawafer]

I guess you didn't get the point of my posts. Bottom line: The bottleneck and main cause of latency, is the multitasking o/s that makes your PC, a PC. The software (on hardware) you refer to is classifed as an embedded system - there is no multi-tasking o/s there. Basically the code on a hardware device would consist of an endless loop and either polling for inputs or responding to inputs in real time by way of an interrupt. In C/S terms, the behavior of such systems is deterministic - code can be timed and will always execute in that time slice. This is not possible with a multi-tasking o/s, like windows. This is a big reason why a 4 MHZ ancient embedded cpu can respond to inputs with no latency.

This is all just completely inacurate, where did you get this information?

[wades_keys]

This is all just completely inacurate, where did you get this information?

 

 

What specifically is inaccurate?

[MartinHines]

BTW ever wonder why planes aren't falling out of the sky every day despite all the computerized systems on board? Answer: the FAA has very strict rules about software testing, way beyond what the PC industry would be able to tolerate.

 

 

Its the combination of software and hardware that is controlled.

 

Another good example is NASA and the Space Shuttle. I read somewhere that they are still using Intel x386 CPUs on board. Its simply too much of a risk to switch to a new platform.

 

The PC industry IS out of control in terms of stability. Too many new Operating Systems, new hardware, and new software and definitely not enough testing.

[wades_keys]

 

Definition of real-time o/s: A mode of action and reaction by an operating system and application software. It allows priorities to be changed instantly and data to be processed rapidly enough that the results may be used in response to another process taking place at the same time, as in transaction processing. It has the ability to immediately respond, in a predetermined and predictable way, to external events

 

If you need the ability to " immediately respond, in a predetermined and predictable way, to external events", then you need an RTOS.

 

Period, end of story.

[wades_keys]

Its the combination of software and hardware that is controlled. Another good example is NASA and the Space Shuttle. I read somewhere that they are still using Intel x386 CPUs on board. Its simply too much of a risk to switch to a new platform.

 

 

IT's not just that martin - the 386 was the last Intel processor to be truly deterministic wrt to instruction cycle counting.

 

No out of order execution or branch prediction for example.

 

Mike Abrash wrote wonderful books on this - "Zen of code optimization"

 

Intel has never been strong in the embedded space - this is but one of the reasons why...

[ElectricPuppy]

Most all modern RTOS are multi-tasking kernels. As you pointed out, Windows is certainly not a RTOS. Only the most simplistic devices are coded with simple loops, most everything else of any moderate intelligence likely has an RTOS in it, mainly because it solves a lot of problems for the programmer.

If you have a system that requires you to guarantee deterministic cycle counts, then you have a poorly-designed system. Instead of counting cycles, what you want is a minimum latency guarantee for interrupt handling. With modern CPUs, this is almost certainly going to be much faster than necessary to handle the hideously slow MIDI stream. Even for audio, a little bit of extra hardware can help overcome audio latencies and relieve the CPU of constantly servicing interrupts.

Anyway, enough rambling: Multitasking is not the Great Evil of embedded systems, it's the overall system design itself will most impact the responsiveness of a system. Windows is not that system.

Trivia: The Mars Rovers run VxWorks, a multitasking RTOS, on PowerPC CPUs which perform the dreaded branch prediction you mention. They seem to be working fine.

[wades_keys]

 

If you have a system that requires you to guarantee deterministic cycle counts, then you have a poorly-designed system.

 

I did not mean down to the last cycle, such as Atari 2600 (with no video buffer!)

 

But ISR's all have upper bounds on the number of clock cycles that can be stuffed into them; it is highly possible that a very tightly written ISR would in fact be causing the programmer to essentially count clock cycles - at least to establish that the worst case will not exceed the time.

 

Interfacing with I/O devices also has time constraints, again probably not down to the last cycle but the programmer is still very much responsible for writing tight code in ISR's.

[wades_keys]

Trivia: The Mars Rovers run VxWorks, a multitasking RTOS, on PowerPC CPUs which perform the dreaded branch prediction you mention. They seem to be working fine.

I knew that - consider my comments were made in light of bare-bones embedded systems, such as the code that runs my old ESQ-1.

Or old arcade game code, like pacman.

AN o/s is more of a programmer convenience then a technical necessity...

But then, we could say the same about C vs. Assembler as well.

[playstation]

Is the Muse receptor entirely a Microsoft-free zone?

I'm never, ever, ever giving up on softsynths because they, for me are just way more fun.

PC does have issues, but so far it hasn't really been bad. I would really like to go for receptor , though someday.

[ElectricPuppy]

I knew that - consider my comments were made in light of bare-bones embedded systems, such as the code that runs my old ESQ-1. Or old arcade game code, like pacman. AN o/s is more of a programmer convenience then a technical necessity... But then, we could say the same about C vs. Assembler as well.

True, all of it.

At one time, I owned a Tempest that I thought would be cool to reprogram with a game of my own design. Tempest runs on a 6502 with a custom-made 16-bit "mathbox" for handling the vector engine. To figure out how to run the mathbox, I spent a LONG time dissaembling the 6502 and the PROMs in the mathbox itself. Very educational.

There, though, is an EXCELLENT case of designing hardware to overcome the limitations of the CPU. There was no way that little 6502 was going to be able to do the vector math necessary and present the player with a lightening-fast response. Unfortunately, I never finished that project and sold the game.

More rambling. Anyway, I'm all for small embedded systems. I recognize the PC for what it is, which is simply a general-purpose computer.

[wades_keys]

True, all of it. At one time, I owned a Tempest that I thought would be cool to reprogram with a game of my own design. Tempest runs on a 6502 with a custom-made 16-bit "mathbox" for handling the vector engine. To figure out how to run the mathbox, I spent a LONG time dissaembling the 6502 and the PROMs in the mathbox itself. Very educational. There, though, is an EXCELLENT case of designing hardware to overcome the limitations of the CPU. There was no way that little 6502 was going to be able to do the vector math necessary and present the player with a lightening-fast response. Unfortunately, I never finished that project and sold the game.

 

Battlezone I think was the first game from Atari to use the "mathbox".

 

3d vector computations in 1980 on commodity hardware!

 

IIRC they were a bunch of discrete ALU's wired together.

 

Or look at Cinematronics, they actually built their own cpu out of discrete components like adders and such (Larry Rosenthal).

[wades_keys]

Is the Muse receptor entirely a Microsoft-free zone? I'm never, ever, ever giving up on softsynths because they, for me are just way more fun. PC does have issues, but so far it hasn't really been bad. I would really like to go for receptor , though someday.

 

 

I believe the receptor uses a customized linux kernel...

[ElectricPuppy]

I believe you're right, Battlezone was first to use the mathbox. Next to Tempest, it's also one of my faves.

The mathbox was made with 4 AMD (yes, "that" AMD) "bitslice" ALUs. There was a set of PROMS with what was essentially microcode that controlled the ALUs. Studying the schematic and reverse-engineering the ALU code was super-geeky fun.

I've read about the Cinematronics CPU... wacky stuff!

So, are you volunteering to design and program a decent sequencer/DAW box?

[wades_keys]

I believe you're right, Battlezone was first to use the mathbox. Next to Tempest, it's also one of my faves. The mathbox was made with 4 AMD (yes, "that" AMD) "bitslice" ALUs. There was a set of PROMS with what was essentially microcode that controlled the ALUs. Studying the schematic and reverse-engineering the ALU code was super-geeky fun. I've read about the Cinematronics CPU... wacky stuff! So, are you volunteering to design and program a decent sequencer/DAW box?

If only....

 

Maybe, just maybe - Linux will make enough inroads to make this possible.

 

Linux apparently has RTOS extensions, and a swappable task scheduler.

 

So all that would have to happen, is more market penetration and more maturity in the RTOS code, and perhaps co's like Steinberg will step up to the plate and deliver solutions that go to the metal to get the job done.

 

Actually, the Korg Oasys is using a linux based RTOS. Latency is undetectable. So the first step has been taken, but in a proprietary way that unfortunately does not benefit pc users.

 

BUt at least they have demonstrated that it is possible - the OASYS hardware is commodity pc hardware.

[ElectricPuppy]

If you write something for a PC to talk to the metal, then the PC's no longer a Windows PC. You cannot run Windows AND run a real-time system, too.

I wouldn't trust Linux to be real-time, either, even with its extensions. Give me an ARM and ThreadX and now we're talking.

[Yoozer]

 

Another good example is NASA and the Space Shuttle. I read somewhere that they are still using Intel x386 CPUs on board. Its simply too much of a risk to switch to a new platform.

 

It's tried and tested, but the size of the thing also handles radiation better.