That there is a right and wrong answer does not matter. It is the choice of steps that take you there.
Mathematics possesses not only truth, but supreme beauty - a beauty cold and austere, like that of sculpture, without appeal to any part of our weaker nature... sublimely pure, and capable of stern perfection such as only the greatest art can show.
It's lawyerspeak. The terms "technical effect" and "normal physical interactions" are left undefined. I read somewhere that, for example, image enhancement using computers produces a technical effect. Basically the software has to solve a technical problem to be patentable. The technical problem "improve computation efficiency and resource consumption" might even work for an algorithm patent. Then again, I'm not a lawyer.
The most likely reason Xiph started video work on Tarkin with wavelets first is that wavlets are completely patent free.
Hehe. ROTFLMAO. I have done data compression research and there are very few mathematical ideas as patent encumbered as wavelets. A quick naive search of USPTO patents with wavelet and data compression brings up about 250 patents and just wavelets about 10x as much and that's not even looking very closely.
TimoT
Re:Using the right tool for the job
on
OpenGL in PHP
·
· Score: 1
You, sir, clearly do not know lisp. Take a look at the ALU site and the Common Lisp wiki for starters and please do not perpetuate these urban myths any further. About OO: the Common Lisp Object System (CLOS) was the first standardized OO language. Common Lisp is also far from purely functional. It's a multiparadigm language, just like C++, though in my opinion, much more elegant. It's also fast enough for most purposes, e.g. CMUCL, which compiles to native code, gets close to GCC in execution speed. Sometimes the generated code is even faster than code produced by GCC.
Best regards,
TimoT
Re:Yet another OpenGL binding
on
OpenGL in PHP
·
· Score: 2, Informative
Blatant plug: OpenGL and SDL bindings for Common Lisp:
CL-SDL.
And yes, I'm one of the authors. Most Common Lisps are compiled to native code; the performance is fairly good with the added benefit of having a high-level language to program with. There are also bindings to Haskell and OCaml AFAIK.
I don't know about the industry, but there is a lot of multidisciplinary research going on in research institutions. Scientists and engineers working on healthcare systems, such as hospital information systems, telemedicine, e-learning, medical imaging, etc., could probably benefit quite a lot from a physician somewhat well-versed in science or engineering. You could check out the medical informatics conferences to get a broad glimpse of the field.
Of course research doesn't usually pay as much, but nothing stops you from practicing medicine on the side; quite a few people in research do that. Besides, I don't think you need a whole degree in science to work on the field, since you'd be working with engineers, physicists, etc.
... for researching the effects of visual-vestibular conflict on human balance. It's basically as good as it gets for researching vision; all the affordable (not to say CAVE isn't expensive) head-mounted displays have too narrow field of view and tend to be cumbersome.
Another application I can think of is exploratory data analysis (or data mining if you prefer). You can have multiple visualizations of a large data set floating around and even go into the data. The thing is that humans are very good a pattern recogniction (though sometimes even when there are none) and CAVE could be used to exploit this in science.
A convex set is a set where the joining line segment between any two points in the set is also in the set ("no dents in the boundary"). It's easy to see that the intersection of two convex sets is also convex.
In a binary space partitioning tree (BSP) each node splits the space into two halfspaces (halfspace is convex) using a (hyper)plane (the other half is in front of the plane the other behind.) In case of computer graphics the plane used is typically one spanned by a polygon in the scene (a polygon is a planar figure and thus lies on some plane). The resulting halfspaces are recursively split again giving a binary tree. Polygons may have to be cut in half if they intersect the dividing plane on each division and the halves put on different sides of the plane.
To draw the scene properly see which side of the dividing plane the viewer is, draw the polygons on the other side first (recursively), then the polygons on the dividing plane (there might be multiple polygons on the plane) and the the polygons on the same side as the viewer. Why this works is that the polygons on the other side of the plane are behind the ones on the same side as the viewer from the viewer's point of view.
If you're using modern hardware do the exact opposite and hope that the polygons already rendered save some cycles on shaders which are not run on pixels that are not visible by the Z-test.
Yep. Crippleware is damn annoying. Anyway for the work I do (VR gfx on a HMD) it's possible to implement stereo by making one large window span two monitors and draw the image for the left eye in one half and right eye in the other (using glViewport).
We used Intense Wildcat 4000 for VR stuff at the university VR lab. Only workstation cards costing $$$ supported multiple monitors at that time. I'm happy to say that now we "upgraded" from I3D WC4000/WinNT workstation to Linux/nVidia GeForce4 on commodity hw and I can say the latter works much better. It seems that the "workstation" cards do antialiased lines faster but suck at game gfx. Since the gaming cards are moving at a really forward at a really fast pace; I wouldn't waste money on workstation gfx cards unless there's some feature you really must have (like OpenGL stereo buffers).
This is pretty much why after getting my master's in CS (not from UW) I started to study pure math almost exclusively as the graduate studies for my CS PhD (math will be my 2nd major). Math still has some integrity and class left and in my opinion it has been much more useful (and also more challenging, you have to work really hard at graduate-level math) than most CS courses.
The reason is of course that my interests lie in signal processing, data compression, virtual reality and the like (i.e. math-heavy CS).
Knowing math will make getting through CS theory much easier and you can bet that math skills will be noted (math = pure problem solving). The added bonus is that the skills won't age as fast as the what-ever-is-in-fashion-in-the-industry-type CS skills they teach you nowadays. I know a lot of CS-types who would rather ditch math, but imo most math courses are flunked because of laziness not inability. Seems that hobbyist coders pass CS too easily because they've practised before and don't have the patience to really study math because it requires more work. You can also see this effect when trying to teach self-taught C/C++ programmers in scheme. Yes, you may really have to spend two whole days going through the week's homework excercises in math (as opposed to the usual 15-45 minutes in CS).
If I'd start my studies again, I'd choose math as major and do a lot of CS studies. Seems the general trend is that the requirements (and amount of theory) in CS courses have gone way down after the number of students admitted has sky-rocketed in the last few years and the focus of the courses has become much more industry oriented. I also hear that a lot of math graduates get work in the IT sector, and I'm not surprised. They used to become math teachers, but now there's a shortage of teachers, because almost everyone goes to work in the IT sector.
The VST plugin standard has some design flaws. Basically it wasn't designed to do the things it's currently doing (whole app as plugin) and many plugins use the native windows api calls for the guis, so the only option would be to use wine for emulation. Personally I'd prefer a new API designed from the ground up correcting the mistakes of VST/VST2. IIRC Yamaha actually proposed something that uses Microsoft's COM. In the linux world something based on CORBA or even shared libraries might work, but the design is tedious, because you never know what new ideas people come up with. For instance there are plugins with thousands of parameters and the parameters are all different types and plugins that load other plugins (meta-plugins).
Morally? By whose set of morals? Yours? What makes you so special that the morals you hold are the morals everyone else should hold as well? Morality has no place in business, politics, or education. Leave morality to religion. (note that "morals" != "ethics".)
Just stating my opinion, feel free to disagree. I don't believe that breaking the law is a good solution and also I don't believe that having companies keeping a stranglehold of media production by controlling the means of distribution and production is a good thing. Free (or cheap) alternatives would promote independent media production and enable more people to create and distribute digital art than the current situation.
As for patents, my opinion is that the time of protection for the invention is too long and the standards for granting protection are too low. The particular case of compression algorithms (and many other algorithms); I consider them mathematics, which shouldn't be patentable.
It seems that patents don't protect individual inventors btw, but only those who have the resources to use the patents in court (i.e. large companies).
Another problem with ip laws is that they are in my opinion trying to create artificial scarcity of resources, where there exist none naturally, so that ip can be created, sold and bought like any other physical good. It's surprisingly conservative that when technology is about to make certain business models obsolete then laws are enacted to protect those models. I.e. "We've made lots of money doing this in the past, we have the right to make money doing this in the future." Strikes me as lack of faith in the adaptability of the capitalist economy - there will be new markets, when old ones are made obsolete.
If we want linux to be taken seriously in multimedia production then we need some way to get around the proprietary format/codec problem for media. This is actually one of the key reasons why I'm opposed to DMCA-like laws (and patenting of compression algorithms), since they create barriers to entry for free software. Free software authors can't pay the licencing fees.
Morally the right thing to do would be to create free alternatives, but this is probably not a feasible option (lawsuits for patent infringement, consumer acceptance of alternate formats, etc.). As it stands now even watching DVDs on linux is illegal (afaik css is being automatically descrambled by a non-licenced program). Clearly some solution for this is needed.
As for the infrastructure, linux audio is doing pretty well (ALSA+lowlatency works wonders). All that's missing is the production apps... a good sequencer (cubase/cakewalk-workalike) would do wonders. All of the GUI audio apps I've seen for linux are crap compared to professional windows apps. It's about time to do something about it, but is the community of linux-using music-making dsp-coding geeks too small ?
I'd argue that depth-first search is even more fundamental (topological sort is based on it). You can also compute strongly connected components using 2 DFS passes. Another fundamental graph algorithm would be the breadth-first search. I guess it depends on how you define fundamental, but I'd say a simple algorithm that is used to build simple algorithms.
Gouraud will look like Phong if you have a dense enough polygon mesh. Therefore Phong shading isn't absolutely essential. Gouraud = interpolate lighting at vertices to polygon, phong = interpolate surface normals at vertices and compute lighting at each point, iirc.
I'm sorry to that afaiuc your piece of code is faulty.
friend coord& operator+ (const coord& a, const coord& b) { return coord(a.x+b.x, a.y+b.y); }
In this case operator+ is returning a reference to a coord-type variable, which is built on stack and destroyed at the moment the stack-frame of operator+ is overwritten. It may work on p1 = p2 + p3 -type of expressions, where p1 has a copy-constructor. Consider void foo(coord&); foo (a+b); (this won't catch the bug if + is inlined since the returned coord variable is allocated on the stack frame of the function calling +) or a case where the coord type has a destructor e.g. make the destructor set x = y = 0, and see if you program still works... This is error is a bit like returning a pointer to a variable in stack.
On Lisp(great book on lisp macros among other things)
you probably knew these but I put them there for the benefit of people looking to learn lisp. With ilisp you get an emacs mode, where you can look stuff up hyperspec while you write.
As for programming sound and games, I've done some stuff on sound programming, but the biggest problem is access to platform dependent libraries (i.e you have to write the bindings yourself) and the other problem is that the garbage collector is not real time (at least in CMUCL) so you may get clicks in the sound, if the GC starts doing its thing while playing. But you can get around that using a C-library running in another thread doing the playing. It's too complicated for my tastes though. I'd imagine game programming has similar problems. So to sum up: Multimedia in lisp sucks mostly due to lack of libraries and realtime support. Also trying to avoid consing in realtime code is painful at times (code all littered with declare, the and coerce), because the memory allocation is implicit (e.g. imagine boxing and type-checking x*44100 floats per second when doing realtime audio calculations).
Realtime audio processing with realtime modification via a GUI. Virtual Synthesizers ? Playing really sucks if you get a click once every few seconds because the audio process was swapped in a few ms too late and you can't use buffering to counter this because it adds latency. If the latency is more than about 5-10 ms then the "feel" of playing will start to degrade.
I've also heard good things about the M-Audio Delta Audiophile 2496, and it's cheaper than Audigy Platinum Ex. Does 24/96 on 2 stereo channels (2xIn, 2xOut) and has a 16 bit/44.1 kHz SPDIF and MIDI connectors as well. Future Music gave it 8/10 on a review and recommended that music people get something else than the Audigy. Of course for playing games I think Creative cards will receive the most support. But if you're into making music seriously I'd consider something different. Many softsynths can beat hardware synths (at least in terms of flexibility) and this situation is only going to get better with faster processors (i.e. you might not need the MIDI synth in Audigy) or you might want to hook up two different instruments (e.g. synth/electric guitar) to your audio card and have good quality inputs.
Well, this is partially true. At least the MLP neural network is just a non-linear function approximator, that can, in theory, learn any mapping from the inputs to the outputs. The network is trained using points from the input space together with the desired output. Statisticians would probably call MLP non-linear regression. I also know some statistics profs who have a rather high regard for neural networks. The name has a lot of hype, but the methodology works. About correct extrapolations: I would like to see anything correctly extrapolate in a general case given only a few random observed points and desired output. The performance of these methods depends on how well the assumptions of the method correspond to the way the observed data really behaves and you cannot tell that with
certainty from a few random points.
The training is usually done using two separate sets of data: a training set and a test set. The training set is used to train the network and the test set is used to test the performance. When the performance of the network starts to degrade instead of improving, then the network is starting to overfit and loses it's ability to generalize.
Basically you can just think of the MLP neural network as a classifier (when your goal is to classify, which is usually the case with neural network) that draws arbitrary boundaries in n dimensional space. Somehow I always think of those blobby objects in computer graphics, when I think of the classification boundaries, but this is of course not strictly correct. I guess it still helps.
To build a MIDI-controllable programmable modular software synthesizer (for sound, you know) on consumer boxes ? You need very low latency to have it behave like a real instrument. Computers are getting fast enough for all kinds of funky media experiments.
How about running a virtual reality system on a PC box ? I'd say that qualifies as a time-critical app, especially if you're doing measurements at the same time. I'd like to have graphics that can be _guaranteed_ not to skip frames under any circumstances. If not for any other reason, science requires reproducible results.
Slashdot Mirror
It's lawyerspeak. The terms "technical effect" and "normal physical interactions" are left undefined. I read somewhere that, for example, image enhancement using computers produces a technical effect. Basically the software has to solve a technical problem to be patentable. The technical problem "improve computation efficiency and resource consumption" might even work for an algorithm patent. Then again, I'm not a lawyer.
TimoT
You, sir, clearly do not know lisp. Take a look at the ALU site and the Common Lisp wiki for starters and please do not perpetuate these urban myths any further. About OO: the Common Lisp Object System (CLOS) was the first standardized OO language. Common Lisp is also far from purely functional. It's a multiparadigm language, just like C++, though in my opinion, much more elegant. It's also fast enough for most purposes, e.g. CMUCL, which compiles to native code, gets close to GCC in execution speed. Sometimes the generated code is even faster than code produced by GCC.
Best regards,
TimoT
Blatant plug: OpenGL and SDL bindings for Common Lisp: CL-SDL. And yes, I'm one of the authors. Most Common Lisps are compiled to native code; the performance is fairly good with the added benefit of having a high-level language to program with. There are also bindings to Haskell and OCaml AFAIK.
TimoT
I don't know about the industry, but there is a lot of multidisciplinary research going on in research institutions. Scientists and engineers working on healthcare systems, such as hospital information systems, telemedicine, e-learning, medical imaging, etc., could probably benefit quite a lot from a physician somewhat well-versed in science or engineering. You could check out the medical informatics conferences to get a broad glimpse of the field.
Of course research doesn't usually pay as much, but nothing stops you from practicing medicine on the side; quite a few people in research do that. Besides, I don't think you need a whole degree in science to work on the field, since you'd be working with engineers, physicists, etc.
Another application I can think of is exploratory data analysis (or data mining if you prefer). You can have multiple visualizations of a large data set floating around and even go into the data. The thing is that humans are very good a pattern recogniction (though sometimes even when there are none) and CAVE could be used to exploit this in science.
I know this is nitpicking, but I couldn't resist.
A convex set is a set where the joining line segment between any two points in the set is also in the set ("no dents in the boundary"). It's easy to see that the intersection of two convex sets is also convex.
In a binary space partitioning tree (BSP) each node splits the space into two halfspaces (halfspace is convex) using a (hyper)plane (the other half is in front of the plane the other behind.) In case of computer graphics the plane used is typically one spanned by a polygon in the scene (a polygon is a planar figure and thus lies on some plane). The resulting halfspaces are recursively split again giving a binary tree. Polygons may have to be cut in half if they intersect the dividing plane on each division and the halves put on different sides of the plane.
To draw the scene properly see which side of the dividing plane the viewer is, draw the polygons on the other side first (recursively), then the polygons on the dividing plane (there might be multiple polygons on the plane) and the the polygons on the same side as the viewer. Why this works is that the polygons on the other side of the plane are behind the ones on the same side as the viewer from the viewer's point of view.
If you're using modern hardware do the exact opposite and hope that the polygons already rendered save some cycles on shaders which are not run on pixels that are not visible by the Z-test.
-Timo
Yep. Crippleware is damn annoying. Anyway for the work I do (VR gfx on a HMD) it's possible to implement stereo by making one large window span two monitors and draw the image for the left eye in one half and right eye in the other (using glViewport).
We used Intense Wildcat 4000 for VR stuff at the university VR lab. Only workstation cards costing $$$ supported multiple monitors at that time. I'm happy to say that now we "upgraded" from I3D WC4000/WinNT workstation to Linux/nVidia GeForce4 on commodity hw and I can say the latter works much better. It seems that the "workstation" cards do antialiased lines faster but suck at game gfx. Since the gaming cards are moving at a really forward at a really fast pace; I wouldn't waste money on workstation gfx cards unless there's some feature you really must have (like OpenGL stereo buffers).
The original paper on Lisp by John McCarthy could be considered an important part of CS history: Recursive Functions of Symbolic Expressions and Their Computation by Machine (Part I)
Claude Shannon's A Mathematical Theory of Communication is good to know as well.
Richard Gabriels' Worse Is Better paper is also on the web, but I don't know if that qualifies. It's somewhat new to be folklore.I don't know if any of the original papers by Turing, Church and von Neumann have been put online so post some links if you find them.
"A wavelet tour of signal processing" by Stephane Mallat is good, though heavy on the math...
This is pretty much why after getting my master's in CS (not from UW) I started to study pure math almost exclusively as the graduate studies for my CS PhD (math will be my 2nd major). Math still has some integrity and class left and in my opinion it has been much more useful (and also more challenging, you have to work really hard at graduate-level math) than most CS courses.
The reason is of course that my interests lie in signal processing, data compression, virtual reality and the like (i.e. math-heavy CS). Knowing math will make getting through CS theory much easier and you can bet that math skills will be noted (math = pure problem solving). The added bonus is that the skills won't age as fast as the what-ever-is-in-fashion-in-the-industry-type CS skills they teach you nowadays. I know a lot of CS-types who would rather ditch math, but imo most math courses are flunked because of laziness not inability. Seems that hobbyist coders pass CS too easily because they've practised before and don't have the patience to really study math because it requires more work. You can also see this effect when trying to teach self-taught C/C++ programmers in scheme. Yes, you may really have to spend two whole days going through the week's homework excercises in math (as opposed to the usual 15-45 minutes in CS).
If I'd start my studies again, I'd choose math as major and do a lot of CS studies. Seems the general trend is that the requirements (and amount of theory) in CS courses have gone way down after the number of students admitted has sky-rocketed in the last few years and the focus of the courses has become much more industry oriented. I also hear that a lot of math graduates get work in the IT sector, and I'm not surprised. They used to become math teachers, but now there's a shortage of teachers, because almost everyone goes to work in the IT sector.
The VST plugin standard has some design flaws. Basically it wasn't designed to do the things it's currently doing (whole app as plugin) and many plugins use the native windows api calls for the guis, so the only option would be to use wine for emulation. Personally I'd prefer a new API designed from the ground up correcting the mistakes of VST/VST2. IIRC Yamaha actually proposed something that uses Microsoft's COM. In the linux world something based on CORBA or even shared libraries might work, but the design is tedious, because you never know what new ideas people come up with. For instance there are plugins with thousands of parameters and the parameters are all different types and plugins that load other plugins (meta-plugins).
Just stating my opinion, feel free to disagree. I don't believe that breaking the law is a good solution and also I don't believe that having companies keeping a stranglehold of media production by controlling the means of distribution and production is a good thing. Free (or cheap) alternatives would promote independent media production and enable more people to create and distribute digital art than the current situation.
As for patents, my opinion is that the time of protection for the invention is too long and the standards for granting protection are too low. The particular case of compression algorithms (and many other algorithms); I consider them mathematics, which shouldn't be patentable. It seems that patents don't protect individual inventors btw, but only those who have the resources to use the patents in court (i.e. large companies).
Another problem with ip laws is that they are in my opinion trying to create artificial scarcity of resources, where there exist none naturally, so that ip can be created, sold and bought like any other physical good. It's surprisingly conservative that when technology is about to make certain business models obsolete then laws are enacted to protect those models. I.e. "We've made lots of money doing this in the past, we have the right to make money doing this in the future." Strikes me as lack of faith in the adaptability of the capitalist economy - there will be new markets, when old ones are made obsolete.
If we want linux to be taken seriously in multimedia production then we need some way to get around the proprietary format/codec problem for media. This is actually one of the key reasons why I'm opposed to DMCA-like laws (and patenting of compression algorithms), since they create barriers to entry for free software. Free software authors can't pay the licencing fees.
Morally the right thing to do would be to create free alternatives, but this is probably not a feasible option (lawsuits for patent infringement, consumer acceptance of alternate formats, etc.). As it stands now even watching DVDs on linux is illegal (afaik css is being automatically descrambled by a non-licenced program). Clearly some solution for this is needed.
As for the infrastructure, linux audio is doing pretty well (ALSA+lowlatency works wonders). All that's missing is the production apps... a good sequencer (cubase/cakewalk-workalike) would do wonders. All of the GUI audio apps I've seen for linux are crap compared to professional windows apps. It's about time to do something about it, but is the community of linux-using music-making dsp-coding geeks too small ?
I'd argue that depth-first search is even more fundamental (topological sort is based on it). You can also compute strongly connected components using 2 DFS passes. Another fundamental graph algorithm would be the breadth-first search. I guess it depends on how you define fundamental, but I'd say a simple algorithm that is used to build simple algorithms.
Gouraud will look like Phong if you have a dense enough polygon mesh. Therefore Phong shading isn't absolutely essential. Gouraud = interpolate lighting at vertices to polygon, phong = interpolate surface normals at vertices and compute lighting at each point, iirc.
you probably knew these but I put them there for the benefit of people looking to learn lisp. With ilisp you get an emacs mode, where you can look stuff up hyperspec while you write.
As for programming sound and games, I've done some stuff on sound programming, but the biggest problem is access to platform dependent libraries (i.e you have to write the bindings yourself) and the other problem is that the garbage collector is not real time (at least in CMUCL) so you may get clicks in the sound, if the GC starts doing its thing while playing. But you can get around that using a C-library running in another thread doing the playing. It's too complicated for my tastes though. I'd imagine game programming has similar problems. So to sum up: Multimedia in lisp sucks mostly due to lack of libraries and realtime support. Also trying to avoid consing in realtime code is painful at times (code all littered with declare, the and coerce), because the memory allocation is implicit (e.g. imagine boxing and type-checking x*44100 floats per second when doing realtime audio calculations).
Realtime audio processing with realtime modification via a GUI. Virtual Synthesizers ? Playing really sucks if you get a click once every few seconds because the audio process was swapped in a few ms too late and you can't use buffering to counter this because it adds latency. If the latency is more than about 5-10 ms then the "feel" of playing will start to degrade.
I've also heard good things about the M-Audio Delta Audiophile 2496, and it's cheaper than Audigy Platinum Ex. Does 24/96 on 2 stereo channels (2xIn, 2xOut) and has a 16 bit/44.1 kHz SPDIF and MIDI connectors as well. Future Music gave it 8/10 on a review and recommended that music people get something else than the Audigy. Of course for playing games I think Creative cards will receive the most support. But if you're into making music seriously I'd consider something different. Many softsynths can beat hardware synths (at least in terms of flexibility) and this situation is only going to get better with faster processors (i.e. you might not need the MIDI synth in Audigy) or you might want to hook up two different instruments (e.g. synth/electric guitar) to your audio card and have good quality inputs.
J.W. Cooley and J.W.Tukey and the Fast Fourier Transform, ring a bell yet ?
Well, this is partially true. At least the MLP neural network is just a non-linear function approximator, that can, in theory, learn any mapping from the inputs to the outputs. The network is trained using points from the input space together with the desired output. Statisticians would probably call MLP non-linear regression. I also know some statistics profs who have a rather high regard for neural networks. The name has a lot of hype, but the methodology works. About correct extrapolations: I would like to see anything correctly extrapolate in a general case given only a few random observed points and desired output. The performance of these methods depends on how well the assumptions of the method correspond to the way the observed data really behaves and you cannot tell that with certainty from a few random points.
The training is usually done using two separate sets of data: a training set and a test set. The training set is used to train the network and the test set is used to test the performance. When the performance of the network starts to degrade instead of improving, then the network is starting to overfit and loses it's ability to generalize.
Basically you can just think of the MLP neural network as a classifier (when your goal is to classify, which is usually the case with neural network) that draws arbitrary boundaries in n dimensional space. Somehow I always think of those blobby objects in computer graphics, when I think of the classification boundaries, but this is of course not strictly correct. I guess it still helps.
To build a MIDI-controllable programmable modular software synthesizer (for sound, you know) on consumer boxes ? You need very low latency to have it behave like a real instrument. Computers are getting fast enough for all kinds of funky media experiments.
How about running a virtual reality system on a PC box ? I'd say that qualifies as a time-critical app, especially if you're doing measurements at the same time. I'd like to have graphics that can be _guaranteed_ not to skip frames under any circumstances. If not for any other reason, science requires reproducible results.