>Do they let their own people view the movies on their workstations?
Of course not. Their own people are supposed to be working at their workstations, not watching movies.
And Rhythem & Hues basically paid for the development of FilmGimp, so for those of us who needed something like that (there are a few scientists using it, amoung others), it is very good that they use it.
FilmGimp only loads sequential frames. Like: frame0001.tiff frame0002.tiff frame0003.t iff... And of course, all audio is lost.
I don't know how hard it would be to write a macro to make the task easier once loaded. Do you at least have a macro to let you select two points and have it draw the saber in between?
By the way, there is no company behind FilmGimp. The closest is Rhythem & Hues who have a developer or two on staff. But they don't control the project.
Being pure aqua is unlikely, since FilmGimp is based on GTK. However, things will get significantly faster when GTK gets a good cocoa port. There is some work in progress, but it isn't really ready yet. However, this still doesn't mean that it will look like Aqua.
To port FilmGimp to run natively on Cocoa is an undertaking that it doesn't sound like anyone is trying to take. Heck, nobody is going it for regular gimp either. And the windows ports of both are based on GTK for windows, not native. So, don't expect it anytime soon.
Second, there was rumored to be an internal port of Solaris to the Javastation. It probably wouldn't have been hard.
Third, I'm told that if you want to run Java on a Javastation, you will get better performance by netbooting Linux and running your Java there that you would have on JavaOS. However, I still would have liked to have been able to get a copy of JavaOS to try. It sounded neat.
Anyway, by now there are precompiled Linux's for the Javastation floating around. I just never got around to finishing setting up my boot server (got BOOTP and something else running to boot the OS loader that allows more boot options, but never got the rest of the stuff installed on the server), then, as I said, I needed the cash.
I now have a Sun ELC that I'm trying to get netbooting. However, I'm being held up because I gave away what turned out to be my last spare tranceiver (I thought I had another spare around). Someday.
I love old Sun gear. I have a 3/160, a 3/280, and a 3/80. Plus an IPX, SS Classic, and Ultra1. I used to have a SS2, but I gave it to someone more needing of it. I still want to get a SS10 with the ZX board, which was the setup of the first 3D workstation I ever used. Ahh, good times.
> Sense8 [sense8.com] - The WorldToolKit has the best device driver support that I've seen. > Immersion [immersion.com] - Good starting point for haptics, game controllers, etc.
I've used products from both companies. Let me say that I'm not impressed with either. WorldToolKit (WTK) is fairly easy to use, and it does have a lot of support for things like Polhemus fast tracks, etc, but a lot of these devices aren't that hard to write drivers for, and WTK's abilities are really limited. For instance, there isn't any support that I can see for multipass texturing, let alone vertex or pixel shaders. It does let you drop to OpenGL in places, but that is tricky. I'd recommend either using a free tool kit (Crystal Space looks good, but I haven't had a chance to try it, OpenScenegraph is decent) or roll your own (which really isn't very hard to do). WTK is really expensive by the way.
As to Immersion, well, I'm under NDA for some of it. However, but their APIs suck. For one device, I had to chuck their high level API (the one that allow you to do things like GetPosition) and write my own reading from the low level API (the one that retrieves raw encoder values from the PCI card). On another device, I was able to use the high level API, but the values matrices I got back were wacked out and require much code to fix them. But, maybe Immersion's APIs for joysticks and such is nicer.
CrystalEyes at least I have no problem with. Not as cool as a HMD with Polhemus Fast Track position tracker though.
I had a Javastation. I sold it earlier this year because I needed the money. Both Javastations (the ones known as MrCoffee, and the ones know as Krups) used Sparc processors.
The MrCoffee JavaStation (the one that looked like a Sun 611 drive case) was essentially a diskless SS5 in a smaller case, and a tweaked PROM.
I failed to see any testing of its performance doing DX9 specific tasks. It obviously isn't going to smoke a GeforceFX card, but will it be better than a Geforce3 or Geforce4 at running DX9 and OpenGL 2.0 shaders?
And I would have really liked to have seen them run the tests at 1024x768 anyway despite the lack of AA in the drivers.
Not in games, but I have trouble with Nvidia drivers either crashing XFree or crashing the whole machine. I'm using whatever was current in mid October, and a Geforce3TI200 card.
It sounds like you want a NIC with 2 100mbit links that acts 1 200mbit link. OK, but how is that really a new architecture over using some sort of software channel bonding. It is built into linux, and was developed (in linux at least) for the original beowulf cluster. With it, one can easily use one or two large switches and a couple of quad fast ethernet cards to get 400 or 800 mbits of bandwidth in and out of nodes.
And the idea is also firmly established in the NAS market. I don't think it is in use in the SAN market, but that is probably because most SAN venders are using either GigE or FC-AL. However, once iSCSI is more commonly available (I believe it is in progress for NetBSD, don't know what the linux status might be), I'd imagine running it over channel bonded links would also be no trouble.
Re:Not just better playback
on
Film Gimp
·
· Score: 1
>It's not like the GIMP is extremely well-suited to video editing.
Although it has been mentioned on the mailing lists, I don't think anyone is serious about turning the gimp into a video editor ala Apple's Final Cut Pro. My understanding is that FilmGimp is mainly used as a video paint program to handle tasks like wire removal and dirt clean up in cases where the automatic tools don't cut it, plus any other video paint tasks that might be needed. It isn't even really being positioned against dedicated compositing tools, although it is adding those sorts of features more than it is adding video editing features.
>It's not a downside that it's based on an older code base. It's not an upside either. It's a non-point, it shouldn't even be mentioned.
It is a downside if I want features found only in FilmGimp, and features found only in newer versions of the Gimp at the same time. In particular, the brushes have come a long way since then, although I believe that some features of newer gimps have been selectively merged, I'm not sure about the brushs. I've poked at FilmGimp on my computer, but I don't have an 16bit image sources, and I don't do composite intensively enough to really need 16bits for intermediate operations, so I haven't carefully inspected all the differences. I wish I could afford input sources that supported enough precision to warrant using FilmGimp.
Really, it is fine for the two to be split, except I want 16bit editing for photos (even though I don't need it yet), and I want the latest gimp features. Gimp 2.0 promises to have those things, but as the article points out, it is likely to be some time before they arrive.
Re:Not just better playback
on
Film Gimp
·
· Score: 1
First, not everybody uses square pixels. This is often a problem for making graphics for video, where the computer screen uses square pixels, but NTSC doesn't.
Second, I meant (2^24)^2.
Not just better playback
on
Film Gimp
·
· Score: 5, Informative
Film gimp adds lots of support for superior playback. However, the biggest and most importanted different is that it uses 16 bits per channel instead of only 8 like the regular gimp. That means that instead of roughly 16 million colors, you get 16 million squared colors. This adds much less chance of rounding errors on compositing, and gives you more room to play with when adjusting brightness and color balance over 8 bit images.
The downside is that film gimp is based on an old version of the gimp, and it doesn't really look like that is going to change soon. But at least they are talking about syncing up a bit before 2.0 whereas before they seemed to be planning on waiting for the Gimp 2.0.
SIs are still great for paint, design, and video editing. My ideal would probably be an Octane with dual SI cards, each with TRAM, a digital video option, and an FC-AL XIO card, and FDDI PCI card.
If they included Macs, there were would they stop? Linux has supported multiple heads for quite some time (not as long as the mac did, but only because it isn't as old). And lets not forget Sun. They've supported multiple monitors at least as long as Apple did. And SGI. They've had multiple monitors for quite some time (but perhaps not as long as Apple). And IBM, and HP, and Compaq's Alpha lines under both VMS and Tru64 and Linux and FreeBSD (and the vax line before that). I mean, if you don't keep it really limited, there are far too many possibilities.
Heck, they didn't even include all the MS Windows options out there.
In truetype, each glyph has an outline and a program that will tweak the outlines control points for best appearance at the current size. It is extremely cool, but most typeface designers aren't competant to write these programs, and the available tools aren't really that great, so people tend to use programs, like fontographer, that just supply a generic hinting program for each glyph, and that's that.
There is clearly a lot of work in the software arena that could be done to aid typeface creation but I don't think there is much money in doing so.
While you can get really cheap fonts that look like the expensive ones, the cheap ones usually aren't as good.
The reason is that types change as the resolution and size change through some sort of hinting system. In Postscript fonts, I'm not sure how this is accomplished, but I know it is accomplished and rarely copied properly. In truetype fonts, hinting is accomplished by little programs embeded in each font that rearranges the control vertices and other attributes based on the size and resolution, and perhaps other things.
This of course brings up two of my pet peeves. First is that while truetype fonts are superior to postscript fonts, creating them is also more labor intensive, so there are few really high quality providers of them.
Second, while truetype fonts are clearly better, the postscript language is so darn cool for writing programs, but you get best advantage doing so if you use real postscript fonts rather than one truetype font that has been converted at different sizes to postscript.
But anyway, to get back to the topic, the best way to copy a typeface is to print it at several sizes, and also to screen capture it at several sizes, then trace the main one (say 12pt at 300dpi) into your typeface files, then figure out how to set the hinting to approximate the other samples you took.
There have been public statements to the effect that Maya to Renderman isn't the only tool chain.
For instance, an article in Animation World Magazine (ttp://mag.awn.com/index.php3?ltype=all&sort=date& article_no=1344&page=7) mentions izWare's Mirai product being used. And we all have heard of Massive being used for the crowd animation. I'm guessing that in this case the work flow is modelling and motion data is made in maya, then imported into massive. Massive does it's thing (animating the whole crowds), then exports the data to the renderman renderer of their choice (probably PRMan).
Maya is a very imposing tool. But even with recent price cuts, I can't afford it.
Of course, the ideal setup at that time would have been both a Riva128 and Voodoo card.
Glide games, of course, would use the voodoo. Don't install the 3dFX directx driver and force those games to use the Riva (since the riva, at the time, was faster for directx games), and set opengl to run on the riva (if you use applications, if using games, it's up to you).
On a side note, blender still runs quite nicely on a P166mmx with a riva 128. I can't say the same for anything when the video card is a voodoo.
But I still love my 3 voodoo cards (a voodoo 3 and 2 voodoo 2s for SLI mode).
With 256 megs of ram and a pair of mirrored 9 gig disks, you should still be talking well less than $200. Heck, even a Sun SS10 or SS20 should due the job with capacity to spare, if you go dual processor with something like SM61s or better.
If you have a bit more to spare, some of the older Netras are incredibly nice for low amounts of cash.
You don't want to just chuck out the IDE of doing it by IDE. There may be some tasks where this is the best way to go.
For instance, the internet wayback machine uses IDE drives, as you will find in this (http://www.oreillynet.com/pub/a/webservices/2002/ 01/18/brewster.html) article. I think that google might also use IDE, but I'm not certain.
Now, the trick to using IDE for a task like that is you need software to manage redundantly storing data on several machines. Also, if you need to search the data itself, rather than just highly abbreviated indexs, you will need to have a system to distribute the search across all the machines.
For most people, using IDE in such a manner would be a really back idea. It would cost a huge amount to pay someone to develop the software since there is little off the shelf that would do the job. Also, real backups would be near impossible I think due to the slow connection speed between nodes that would most likely result. You might be able to create an off site mirror over very high speed network connections though.
On a side note, I'd like to see someone create a free software package that allows one NetBSD or Linux machine to serve a file system that is really spread over several netbsd/linux machines loaded with cheap disks. I think a good way to do it would be to keep track of file locations on the server cluster in something like mysql or postgres, and then act like a NFS server to the outside world. If writing NFS servers wasn't so painfull, I'd consider doing it. One day I may do it substituting webdav (inefficient, but easier and increasingly well supported on an OS level) for NFS.
Yes, as you alude to, in PDF (and even plain postscript for that matter), when you embed the fonts, you can embed only the characters used. Not only does this put you on slightly better legal ground (in my non-lawyer opinion), but it makes you document smaller also. Thus it is always a good idea.
It is entirely possible to extract Postscript fonts from a postscript file (assuming that the fonts are embeded, rather than being, say, plain curves or bitmaps). I've never heard of anyone extracting fonts from PDF files, but I think it should be possible. But, if not all characters are included, you are SOL.
Nobody in their right minds would use DVDs instead of Betamax for most tasks that betamax is used for. For starters, where are the cameras that write directly to DVD? And I can't imagine that using 2 DVD players and a DVD burner is a good substitute for a linear editing suite.
On the other hand, I'm not surprised that the end of betamax is near. With standards like digibeta and DVCAM, and all the related ones, most people want to move to SDI or firewire setups rather than analog recording, capture, and playback.
Railing against firewire is saved for another time.
Slashdot Mirror
Err, there isn't really much of a FM for filmgimp. It really isn't that hard though.
>Do they let their own people view the movies on their workstations?
Of course not. Their own people are supposed to be working at their workstations, not watching movies.
And Rhythem & Hues basically paid for the development of FilmGimp, so for those of us who needed something like that (there are a few scientists using it, amoung others), it is very good that they use it.
FilmGimp only loads sequential frames. Like:t iff ...
frame0001.tiff
frame0002.tiff
frame0003.
And of course, all audio is lost.
I don't know how hard it would be to write a macro to make the task easier once loaded. Do you at least have a macro to let you select two points and have it draw the saber in between?
By the way, there is no company behind FilmGimp. The closest is Rhythem & Hues who have a developer or two on staff. But they don't control the project.
Being pure aqua is unlikely, since FilmGimp is based on GTK. However, things will get significantly faster when GTK gets a good cocoa port. There is some work in progress, but it isn't really ready yet. However, this still doesn't mean that it will look like Aqua.
To port FilmGimp to run natively on Cocoa is an undertaking that it doesn't sound like anyone is trying to take. Heck, nobody is going it for regular gimp either. And the windows ports of both are based on GTK for windows, not native. So, don't expect it anytime soon.
First, there is Solaris for Intel.
Second, there was rumored to be an internal port of Solaris to the Javastation. It probably wouldn't have been hard.
Third, I'm told that if you want to run Java on a Javastation, you will get better performance by netbooting Linux and running your Java there that you would have on JavaOS. However, I still would have liked to have been able to get a copy of JavaOS to try. It sounded neat.
Anyway, by now there are precompiled Linux's for the Javastation floating around. I just never got around to finishing setting up my boot server (got BOOTP and something else running to boot the OS loader that allows more boot options, but never got the rest of the stuff installed on the server), then, as I said, I needed the cash.
I now have a Sun ELC that I'm trying to get netbooting. However, I'm being held up because I gave away what turned out to be my last spare tranceiver (I thought I had another spare around). Someday.
I love old Sun gear. I have a 3/160, a 3/280, and a 3/80. Plus an IPX, SS Classic, and Ultra1. I used to have a SS2, but I gave it to someone more needing of it. I still want to get a SS10 with the ZX board, which was the setup of the first 3D workstation I ever used. Ahh, good times.
> Sense8 [sense8.com] - The WorldToolKit has the best device driver support that I've seen.
> Immersion [immersion.com] - Good starting point for haptics, game controllers, etc.
I've used products from both companies. Let me say that I'm not impressed with either. WorldToolKit (WTK) is fairly easy to use, and it does have a lot of support for things like Polhemus fast tracks, etc, but a lot of these devices aren't that hard to write drivers for, and WTK's abilities are really limited. For instance, there isn't any support that I can see for multipass texturing, let alone vertex or pixel shaders. It does let you drop to OpenGL in places, but that is tricky. I'd recommend either using a free tool kit (Crystal Space looks good, but I haven't had a chance to try it, OpenScenegraph is decent) or roll your own (which really isn't very hard to do). WTK is really expensive by the way.
As to Immersion, well, I'm under NDA for some of it. However, but their APIs suck. For one device, I had to chuck their high level API (the one that allow you to do things like GetPosition) and write my own reading from the low level API (the one that retrieves raw encoder values from the PCI card). On another device, I was able to use the high level API, but the values matrices I got back were wacked out and require much code to fix them. But, maybe Immersion's APIs for joysticks and such is nicer.
CrystalEyes at least I have no problem with. Not as cool as a HMD with Polhemus Fast Track position tracker though.
I had a Javastation. I sold it earlier this year because I needed the money. Both Javastations (the ones known as MrCoffee, and the ones know as Krups) used Sparc processors.
The MrCoffee JavaStation (the one that looked like a Sun 611 drive case) was essentially a diskless SS5 in a smaller case, and a tweaked PROM.
I failed to see any testing of its performance doing DX9 specific tasks. It obviously isn't going to smoke a GeforceFX card, but will it be better than a Geforce3 or Geforce4 at running DX9 and OpenGL 2.0 shaders?
And I would have really liked to have seen them run the tests at 1024x768 anyway despite the lack of AA in the drivers.
Not in games, but I have trouble with Nvidia drivers either crashing XFree or crashing the whole machine. I'm using whatever was current in mid October, and a Geforce3TI200 card.
It sounds like you want a NIC with 2 100mbit links that acts 1 200mbit link. OK, but how is that really a new architecture over using some sort of software channel bonding. It is built into linux, and was developed (in linux at least) for the original beowulf cluster. With it, one can easily use one or two large switches and a couple of quad fast ethernet cards to get 400 or 800 mbits of bandwidth in and out of nodes.
And the idea is also firmly established in the NAS market. I don't think it is in use in the SAN market, but that is probably because most SAN venders are using either GigE or FC-AL. However, once iSCSI is more commonly available (I believe it is in progress for NetBSD, don't know what the linux status might be), I'd imagine running it over channel bonded links would also be no trouble.
>It's not like the GIMP is extremely well-suited to video editing.
Although it has been mentioned on the mailing lists, I don't think anyone is serious about turning the gimp into a video editor ala Apple's Final Cut Pro. My understanding is that FilmGimp is mainly used as a video paint program to handle tasks like wire removal and dirt clean up in cases where the automatic tools don't cut it, plus any other video paint tasks that might be needed. It isn't even really being positioned against dedicated compositing tools, although it is adding those sorts of features more than it is adding video editing features.
>It's not a downside that it's based on an older code base. It's not an upside either. It's a non-point, it shouldn't even be mentioned.
It is a downside if I want features found only in FilmGimp, and features found only in newer versions of the Gimp at the same time. In particular, the brushes have come a long way since then, although I believe that some features of newer gimps have been selectively merged, I'm not sure about the brushs. I've poked at FilmGimp on my computer, but I don't have an 16bit image sources, and I don't do composite intensively enough to really need 16bits for intermediate operations, so I haven't carefully inspected all the differences. I wish I could afford input sources that supported enough precision to warrant using FilmGimp.
Really, it is fine for the two to be split, except I want 16bit editing for photos (even though I don't need it yet), and I want the latest gimp features. Gimp 2.0 promises to have those things, but as the article points out, it is likely to be some time before they arrive.
First, not everybody uses square pixels. This is often a problem for making graphics for video, where the computer screen uses square pixels, but NTSC doesn't.
Second, I meant (2^24)^2.
Film gimp adds lots of support for superior playback. However, the biggest and most importanted different is that it uses 16 bits per channel instead of only 8 like the regular gimp. That means that instead of roughly 16 million colors, you get 16 million squared colors. This adds much less chance of rounding errors on compositing, and gives you more room to play with when adjusting brightness and color balance over 8 bit images.
The downside is that film gimp is based on an old version of the gimp, and it doesn't really look like that is going to change soon. But at least they are talking about syncing up a bit before 2.0 whereas before they seemed to be planning on waiting for the Gimp 2.0.
SIs are still great for paint, design, and video editing. My ideal would probably be an Octane with dual SI cards, each with TRAM, a digital video option, and an FC-AL XIO card, and FDDI PCI card.
If they included Macs, there were would they stop? Linux has supported multiple heads for quite some time (not as long as the mac did, but only because it isn't as old). And lets not forget Sun. They've supported multiple monitors at least as long as Apple did. And SGI. They've had multiple monitors for quite some time (but perhaps not as long as Apple). And IBM, and HP, and Compaq's Alpha lines under both VMS and Tru64 and Linux and FreeBSD (and the vax line before that). I mean, if you don't keep it really limited, there are far too many possibilities.
Heck, they didn't even include all the MS Windows options out there.
In truetype, each glyph has an outline and a program that will tweak the outlines control points for best appearance at the current size. It is extremely cool, but most typeface designers aren't competant to write these programs, and the available tools aren't really that great, so people tend to use programs, like fontographer, that just supply a generic hinting program for each glyph, and that's that.
There is clearly a lot of work in the software arena that could be done to aid typeface creation but I don't think there is much money in doing so.
While you can get really cheap fonts that look like the expensive ones, the cheap ones usually aren't as good.
The reason is that types change as the resolution and size change through some sort of hinting system. In Postscript fonts, I'm not sure how this is accomplished, but I know it is accomplished and rarely copied properly. In truetype fonts, hinting is accomplished by little programs embeded in each font that rearranges the control vertices and other attributes based on the size and resolution, and perhaps other things.
This of course brings up two of my pet peeves. First is that while truetype fonts are superior to postscript fonts, creating them is also more labor intensive, so there are few really high quality providers of them.
Second, while truetype fonts are clearly better, the postscript language is so darn cool for writing programs, but you get best advantage doing so if you use real postscript fonts rather than one truetype font that has been converted at different sizes to postscript.
But anyway, to get back to the topic, the best way to copy a typeface is to print it at several sizes, and also to screen capture it at several sizes, then trace the main one (say 12pt at 300dpi) into your typeface files, then figure out how to set the hinting to approximate the other samples you took.
There have been public statements to the effect that Maya to Renderman isn't the only tool chain.
& article_no=1344&page=7) mentions izWare's Mirai product being used. And we all have heard of Massive being used for the crowd animation. I'm guessing that in this case the work flow is modelling and motion data is made in maya, then imported into massive. Massive does it's thing (animating the whole crowds), then exports the data to the renderman renderer of their choice (probably PRMan).
For instance, an article in Animation World Magazine (ttp://mag.awn.com/index.php3?ltype=all&sort=date
Maya is a very imposing tool. But even with recent price cuts, I can't afford it.
Of course, the ideal setup at that time would have been both a Riva128 and Voodoo card.
Glide games, of course, would use the voodoo. Don't install the 3dFX directx driver and force those games to use the Riva (since the riva, at the time, was faster for directx games), and set opengl to run on the riva (if you use applications, if using games, it's up to you).
On a side note, blender still runs quite nicely on a P166mmx with a riva 128. I can't say the same for anything when the video card is a voodoo.
But I still love my 3 voodoo cards (a voodoo 3 and 2 voodoo 2s for SLI mode).
With 256 megs of ram and a pair of mirrored 9 gig disks, you should still be talking well less than $200. Heck, even a Sun SS10 or SS20 should due the job with capacity to spare, if you go dual processor with something like SM61s or better.
If you have a bit more to spare, some of the older Netras are incredibly nice for low amounts of cash.
Game logic could run anywhere you put it. My understanding was that Atari expected people to run it on Tom, but it often ended up on the 68k instead.
You don't want to just chuck out the IDE of doing it by IDE. There may be some tasks where this is the best way to go.
/ 01/18/brewster.html) article. I think that google might also use IDE, but I'm not certain.
For instance, the internet wayback machine uses IDE drives, as you will find in this (http://www.oreillynet.com/pub/a/webservices/2002
Now, the trick to using IDE for a task like that is you need software to manage redundantly storing data on several machines. Also, if you need to search the data itself, rather than just highly abbreviated indexs, you will need to have a system to distribute the search across all the machines.
For most people, using IDE in such a manner would be a really back idea. It would cost a huge amount to pay someone to develop the software since there is little off the shelf that would do the job. Also, real backups would be near impossible I think due to the slow connection speed between nodes that would most likely result. You might be able to create an off site mirror over very high speed network connections though.
On a side note, I'd like to see someone create a free software package that allows one NetBSD or Linux machine to serve a file system that is really spread over several netbsd/linux machines loaded with cheap disks. I think a good way to do it would be to keep track of file locations on the server cluster in something like mysql or postgres, and then act like a NFS server to the outside world. If writing NFS servers wasn't so painfull, I'd consider doing it. One day I may do it substituting webdav (inefficient, but easier and increasingly well supported on an OS level) for NFS.
Yes, as you alude to, in PDF (and even plain postscript for that matter), when you embed the fonts, you can embed only the characters used. Not only does this put you on slightly better legal ground (in my non-lawyer opinion), but it makes you document smaller also. Thus it is always a good idea.
It is entirely possible to extract Postscript fonts from a postscript file (assuming that the fonts are embeded, rather than being, say, plain curves or bitmaps). I've never heard of anyone extracting fonts from PDF files, but I think it should be possible. But, if not all characters are included, you are SOL.
Nobody in their right minds would use DVDs instead of Betamax for most tasks that betamax is used for. For starters, where are the cameras that write directly to DVD? And I can't imagine that using 2 DVD players and a DVD burner is a good substitute for a linear editing suite.
On the other hand, I'm not surprised that the end of betamax is near. With standards like digibeta and DVCAM, and all the related ones, most people want to move to SDI or firewire setups rather than analog recording, capture, and playback.
Railing against firewire is saved for another time.
Or better yet, just use cash for all your transactions. There is nothing as satisfying as thunking down 20s to pay a $1000 bill.