Call me crazy but wouldn't it be possible for apple to rewrite FCP solely using cocoa? It seems logical to me. They haven't really released any OS 9 compatible software since 10.2 came out. They want more people moving to OSX and this would be a way to get video editors who haven;t made the switch to switch. I've had FCP crash on me many times so hopefully rewriting in cocoa could fix this. Maybe i'm missing something but it seems pretty logical to me.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Final Cut Pro 4
- Thread starter MacRumors
- Start date
- Sort by reaction score
Re: Hassle Free Render Farming
The bottleneck there is the massive amounts of data that would be sent across the "Net". 60 Min's of MiniDV/DVCAM (DV25) footage takes up approx 12GB you know.
This is my POV on render farms...
IMO (for what it's worth), I would think that filmmakers using FCP1.x-3.x are probably finding that the render issue is one major issue.
From what I've learned from many helpful people here on the site, a render farm service probably will emerge to help editors get over this rendering hurdle once FCP allows the rendering work to be distributed across a network of computers. However, we still don't have that option and until we do, FCP is has a long way to grow.
I would think in the future most independent film companies will have several FCP workstations (and/or laptops) connected to a network of XServers to do real time editing of Hi-Def footage for both theatrical as well as cable/television. But until that happens, I wonder if XServers will be as appealing as Linux boxes in the film industry.
Anyway, those are my thoughts. Let me know what you think. Thanks!
IMO (for what it's worth), I would think that filmmakers using FCP1.x-3.x are probably finding that the render issue is one major issue.
From what I've learned from many helpful people here on the site, a render farm service probably will emerge to help editors get over this rendering hurdle once FCP allows the rendering work to be distributed across a network of computers. However, we still don't have that option and until we do, FCP is has a long way to grow.
I would think in the future most independent film companies will have several FCP workstations (and/or laptops) connected to a network of XServers to do real time editing of Hi-Def footage for both theatrical as well as cable/television. But until that happens, I wonder if XServers will be as appealing as Linux boxes in the film industry.
Anyway, those are my thoughts. Let me know what you think. Thanks!
Re: Re: Hassle Free Render Farming
I agree somewhat. The net's probably not going to be the way to go for most filmmakers for the foreseeable future (unless you've got the hookup like those guys at New Line who are doing The Lord of the Rings trilogy, and then that's another story!)
However, it probably WILL be the way in the future as more people gain higher access speeds and find themselves outsourcing a greater amount of duties and film footage to third party/independent contractors and service bureaus. Even (I would think) the new Airport Extreme standard will have to grow beyond 56MB to accommodate.
Eventually, an entire production company will be more actively controlled from a single laptop. Most editing work will be able to be done by the editor on one, then zipped across the network to a bank of rendering machines. I think we're already seeing that in some circles. However, I believe the tools are still being developed and the way we're now doing business in the industry are changing at an incredible rate.
And if FCP is going to be a cornerstone of this digital movement, I think we need these capabilities integrated into FCP's future versions.
Anyway, I welcome your thoughts on this... Thanks!
I agree somewhat. The net's probably not going to be the way to go for most filmmakers for the foreseeable future (unless you've got the hookup like those guys at New Line who are doing The Lord of the Rings trilogy, and then that's another story!)
However, it probably WILL be the way in the future as more people gain higher access speeds and find themselves outsourcing a greater amount of duties and film footage to third party/independent contractors and service bureaus. Even (I would think) the new Airport Extreme standard will have to grow beyond 56MB to accommodate.
Eventually, an entire production company will be more actively controlled from a single laptop. Most editing work will be able to be done by the editor on one, then zipped across the network to a bank of rendering machines. I think we're already seeing that in some circles. However, I believe the tools are still being developed and the way we're now doing business in the industry are changing at an incredible rate.
And if FCP is going to be a cornerstone of this digital movement, I think we need these capabilities integrated into FCP's future versions.
Anyway, I welcome your thoughts on this... Thanks!
Re: Idiots Rule
HAHAHAHA! I go to work every day and edit and compostite Uncompressed HD and uncompressed SDI on 2 terabytes of SCSI storage. We also have an uncompressed Digital Voodo system and 15 offline (DV) final cut stations. I put together both online and most of the offline systems. So. sorry. I think I am familiar with video.
SDI is a cable and connection interface. What does that have to do with compression? I can send compressed video over SDI. It does not make it uncompressed.
Listen. If you are going to be rude, get your facts straight. A codec is a compression. The compression contains the video like a glass contains water. It holds it. DV is a codec/compression.
If you capture "uncompressed" the card is encoding and compressing the video. Even if it is imperceptible. Even if it is called 1:1. It is not an absolute science, it is perception. At some point it must limit the colorspace and pixels. At some point. If this is far beyond 720x480 then it is "losless" but is is still encoded and still contained in a digital medium.
If you have a FW800 Raid that is acting as a fast and wide and that was my point: for now you need "special" ie. non-stock drives to play uncompressed. FW800 wont change this.
exactly. people were suggesting that you would be able to capture "live" "uncompressed" video. I am merely saying that you need something to do the conversion. (camera, deck or digital to analog)
Why dont you go back and read the post.
By the way, dont come here and be rude or you will turn this site into another Powerpage.org where it is just a bunch of loud lonely geeks bashing eachother. Not to mention that you seem to know just enough about the topic to get you into trouble.
HAHAHAHA! I go to work every day and edit and compostite Uncompressed HD and uncompressed SDI on 2 terabytes of SCSI storage. We also have an uncompressed Digital Voodo system and 15 offline (DV) final cut stations. I put together both online and most of the offline systems. So. sorry. I think I am familiar with video.
SDI is a cable and connection interface. What does that have to do with compression? I can send compressed video over SDI. It does not make it uncompressed.
Listen. If you are going to be rude, get your facts straight. A codec is a compression. The compression contains the video like a glass contains water. It holds it. DV is a codec/compression.
If you capture "uncompressed" the card is encoding and compressing the video. Even if it is imperceptible. Even if it is called 1:1. It is not an absolute science, it is perception. At some point it must limit the colorspace and pixels. At some point. If this is far beyond 720x480 then it is "losless" but is is still encoded and still contained in a digital medium.
If you have a FW800 Raid that is acting as a fast and wide and that was my point: for now you need "special" ie. non-stock drives to play uncompressed. FW800 wont change this.
exactly. people were suggesting that you would be able to capture "live" "uncompressed" video. I am merely saying that you need something to do the conversion. (camera, deck or digital to analog)
Why dont you go back and read the post.
By the way, dont come here and be rude or you will turn this site into another Powerpage.org where it is just a bunch of loud lonely geeks bashing eachother. Not to mention that you seem to know just enough about the topic to get you into trouble.
Re: Re: Idiots Rule
To me, as a programmer by trade, a 1:1 CODEC is, by it's very nature, not compressing anything - so I simply call it a CODEC or a converter, not compression.
So am I right in what I'm saying, that compression is used differently in your industry?
It sounds like some terms are being used differently by different people. A CODEC, as you probably know, stands for "enCODE, DECode". It is software (implemented in hardware or by the CPU) that takes data and either encodes it or decodes it from one form to another. Apparently, some people also call this process, "compression" even if the CODEC results in 1:1 size ratios. I've heard the term used in audio circles for other meaning too.
To me, as a programmer by trade, a 1:1 CODEC is, by it's very nature, not compressing anything - so I simply call it a CODEC or a converter, not compression.
So am I right in what I'm saying, that compression is used differently in your industry?
Are you talking about DV25 or Digital Video in general?
Ah, so I think what I would call "Digitizing" (the digital aproximation of an analog signal), whether done in the camera by the CCD's or by the capture card, might also be called compression here, eh? Since even a 1:1 ratio compression will lose some fidelidy as is enters the digital domain.
Although not written to me, it probably applies to me too!
Codecs and render farms
Everything you ever wanted to know about codecs (with picture comparisons) can be found here:
http://www.onerivermedia.com/codecs/main.htm
As for renderfarms for DV or almost any video,
FCP running on a late model models machine is plenty fast for rendering most video edits. Most edits consist of cuts, dissolves, some color correction and maybe some titles.
The long render times are usually a result of multi-layered composites which need to be rendered regardless of your setup.
Just my My 2 cents.
Everything you ever wanted to know about codecs (with picture comparisons) can be found here:
http://www.onerivermedia.com/codecs/main.htm
As for renderfarms for DV or almost any video,
FCP running on a late model models machine is plenty fast for rendering most video edits. Most edits consist of cuts, dissolves, some color correction and maybe some titles.
The long render times are usually a result of multi-layered composites which need to be rendered regardless of your setup.
Just my My 2 cents.
Re: Codecs and render farms
Um... I think a lot of people (myself included) use a heck of a lot of multi-layered composites, hence the mention about the render farms. I guess I also disagree about the rendering most video edits, but since I tend to lean towards more multi-layered tricks, that in itself could be the answer. Still as video goes to Hi-Def, again I think we've got another issue about rendering...
My 2 cents too...
Um... I think a lot of people (myself included) use a heck of a lot of multi-layered composites, hence the mention about the render farms. I guess I also disagree about the rendering most video edits, but since I tend to lean towards more multi-layered tricks, that in itself could be the answer. Still as video goes to Hi-Def, again I think we've got another issue about rendering...
My 2 cents too...
Multy layers and renderfarms
Point taken, Gene.
I also do a lot of layered compositing, mainly in AE and find that I have never used the watch folder feature. Watch folders in AE are essentially a render farm setup. The reason is that, I don't have multiple machines to render to.
My comment was based on the observation that many of those involved in the discussion claimed to be hobbyists or "not pros". I don't believe many hobbiests (non I know of) are going to go out and buy a couple more macs so they can render faster. Also, my experience with image sequences from renderfarms (supplied from outside sources), still need some sort of rendering or encoding to play in real-time anyway.
Hey, we all have different workflows and needs. Personally, I would rather see better media managment than renderfarm style rendering.
That makes 4 cents now, doesn't it?
Point taken, Gene.
I also do a lot of layered compositing, mainly in AE and find that I have never used the watch folder feature. Watch folders in AE are essentially a render farm setup. The reason is that, I don't have multiple machines to render to.
My comment was based on the observation that many of those involved in the discussion claimed to be hobbyists or "not pros". I don't believe many hobbiests (non I know of) are going to go out and buy a couple more macs so they can render faster. Also, my experience with image sequences from renderfarms (supplied from outside sources), still need some sort of rendering or encoding to play in real-time anyway.
Hey, we all have different workflows and needs. Personally, I would rather see better media managment than renderfarm style rendering.
That makes 4 cents now, doesn't it?
It seems we have multiple definitions here. A google search turns at least 3 sites (in the first 2 pages) supporting Coding/Decoding and 1 saying Compress/Decompress.
Added: Apple's FCP support pages use the Compress/Decompress terminology so I will shut up now
http://docs.info.apple.com/article....howSurvey=false&sessionID=anonymous|165178460
Information Rules
You are probably right. Maybe it is semantics.
Here is my point in a nutshell. If I capture "uncompressed" video and output and capture again on some other "uncompressed" system and repeat, bit by bit (pun intended) this will be lost in the interpretation. Maybe _never_ _ever_ perceptible. But stuff is going on. Thats why I use compress interchangibly with encode. Not because I am crazy. Just because that is how _I_ think of it. Uncompressed video is great! And better than anyone will ever see on their home TV.
Now if it is a totally _digital_ transfer (like DV or if there was a Uncompressed "wrapper" like DV..that just transfered ones and zeros ..i _knowDV is compressed...i am just talking about digitzing onto a computer) then of course I wouldnt call that compression.
If you are capturing via SDI to computer the inerpretation is still going on _somewhere_. Thats why different codecs _look_ different. And that is why I think of encoding as compressing in some way. I am not saying it is encoding _then_ compressing. I just think of it as a process that includes both.
SDI to SDI (no computer involved) obviously would remain truly "uncompressed" in my book.
I have always understood CODEC to be compress/decompress. But again, we all learn our own way.
I guess it is about language.
That being said, I am glad to know there are so many FCP users here.
Good luck to you guys.
You are probably right. Maybe it is semantics.
Here is my point in a nutshell. If I capture "uncompressed" video and output and capture again on some other "uncompressed" system and repeat, bit by bit (pun intended) this will be lost in the interpretation. Maybe _never_ _ever_ perceptible. But stuff is going on. Thats why I use compress interchangibly with encode. Not because I am crazy. Just because that is how _I_ think of it. Uncompressed video is great! And better than anyone will ever see on their home TV.
Now if it is a totally _digital_ transfer (like DV or if there was a Uncompressed "wrapper" like DV..that just transfered ones and zeros ..i _knowDV is compressed...i am just talking about digitzing onto a computer) then of course I wouldnt call that compression.
If you are capturing via SDI to computer the inerpretation is still going on _somewhere_. Thats why different codecs _look_ different. And that is why I think of encoding as compressing in some way. I am not saying it is encoding _then_ compressing. I just think of it as a process that includes both.
SDI to SDI (no computer involved) obviously would remain truly "uncompressed" in my book.
I have always understood CODEC to be compress/decompress. But again, we all learn our own way.
I guess it is about language.
That being said, I am glad to know there are so many FCP users here.
Good luck to you guys.
1. For the love of freaking Christ can the Media Manager be over hauled and made robust<sp?> enough to work as
2. RE native 24p & HD. Does this means Cinema Tools will go away?
3. RE render farm: If you are doing that much "vertical editing" you should be using a stand alone compositing/FX program to begin with. Seriously though, render farm abilities would be useful, but I think it's farther down the list.
Personally, I'm hopping that FCP 4 refines FCP's editing ability and doesn't just add a bunch of features that only a fraction of the FCP community needs or wants. Oh, and better EDL and OMF importing and exporting would be nice too.
Lethal
2. RE native 24p & HD. Does this means Cinema Tools will go away?
3. RE render farm: If you are doing that much "vertical editing" you should be using a stand alone compositing/FX program to begin with.
Seriously though, render farm abilities would be useful, but I think it's farther down the list.Personally, I'm hopping that FCP 4 refines FCP's editing ability and doesn't just add a bunch of features that only a fraction of the FCP community needs or wants. Oh, and better EDL and OMF importing and exporting would be nice too.
Lethal
Re: Information Rules
Unfortunately whoever taught you, taught you incorrectly. CODECs stand for COding/DECoding not COmpress/DECompress. The original telephony CODECs were simply algorithms to digitize sound. The concept of compression did not apply. Adding compression to CODECs came along later.
In my mind it is kind of like DVD. Many people insist that DVD stands for Digital Video Disk when it stands for Digital Versatile Disk. Just because you can find lots of references calling it Digital Video Disk does not mean it is correct.
Unfortunately whoever taught you, taught you incorrectly. CODECs stand for COding/DECoding not COmpress/DECompress. The original telephony CODECs were simply algorithms to digitize sound. The concept of compression did not apply. Adding compression to CODECs came along later.
In my mind it is kind of like DVD. Many people insist that DVD stands for Digital Video Disk when it stands for Digital Versatile Disk. Just because you can find lots of references calling it Digital Video Disk does not mean it is correct.
hhhmm
First, I would like to apologize to michaelyoung and others for coming off as an a## in my first post.
I started working with digital video back when most of our work was shot on BetaSP. I used a Media100 Vincent 601 card. Back then we had 3:1 compression was about the best. And yes we needed alot of fast drives to run things at that high of a data rate. Nowadays a RAID on FW400 could handle that system for projects that aren't too graphic intensive. I used that setup with a B&W G3 for awhile.
When I referred to SDI, and uncompressed cards, I meant that you get what ever format you send to the computer, into the computer, is mostly unaffected. I always referred to CODECS myself, as compress/decompress. I never consider 1:1 codecs that are used with uncompressed boards, as compression, because they barely affect the data in comparison to the analog to digital converstors and 3:1 compression rates of my old media100.
If I send DV25 which is 4:1:1 sampling rate and a 5:1 compression ratio rfrom a deck over SDI to an Uncompressed SDI card. I am going to end up with DV25,4:1:1,5:1, in the cpu, barely affected by the "codec"
If I have a similar set up with DV50 or DigiBeta, that is what I am going to get in the cpu. From the deck to the uncompressed card, over SDI, the "codec" encodes the video in a format the the card can use. This encoding process has very little effect on the video, 1:1, and it is not compressing it in the same sense as the media100 card.
This is why I don't consider 1:1 codecs as compression.
maybe I am am technically wrong, but most people would be hard pressed to tell the difference in the footage.
peace
First, I would like to apologize to michaelyoung and others for coming off as an a## in my first post.
I started working with digital video back when most of our work was shot on BetaSP. I used a Media100 Vincent 601 card. Back then we had 3:1 compression was about the best. And yes we needed alot of fast drives to run things at that high of a data rate. Nowadays a RAID on FW400 could handle that system for projects that aren't too graphic intensive. I used that setup with a B&W G3 for awhile.
When I referred to SDI, and uncompressed cards, I meant that you get what ever format you send to the computer, into the computer, is mostly unaffected. I always referred to CODECS myself, as compress/decompress. I never consider 1:1 codecs that are used with uncompressed boards, as compression, because they barely affect the data in comparison to the analog to digital converstors and 3:1 compression rates of my old media100.
If I send DV25 which is 4:1:1 sampling rate and a 5:1 compression ratio rfrom a deck over SDI to an Uncompressed SDI card. I am going to end up with DV25,4:1:1,5:1, in the cpu, barely affected by the "codec"
If I have a similar set up with DV50 or DigiBeta, that is what I am going to get in the cpu. From the deck to the uncompressed card, over SDI, the "codec" encodes the video in a format the the card can use. This encoding process has very little effect on the video, 1:1, and it is not compressing it in the same sense as the media100 card.
This is why I don't consider 1:1 codecs as compression.
maybe I am am technically wrong, but most people would be hard pressed to tell the difference in the footage.
peace
Actually, you'll end up with a 4:1:1 DV signal embedded into a 4:2:2 lossless codec.
Now, for most people that ain't no big thang.
But for those of us who need to do lots of rendering, compositing, and effects - it's a world of difference. I won't go into it here because it's beyond the scope of this thread (which was responding to that totally ametuerish prediction of FCP 4 feature set), but there are plenty of sites to ask questions and learn more about why you would want to capture DV into an 'uncompressed' codec.
For the record: Decklink and its big brother Kona are SDI capture and output cards that also happen to do live SDI->DV and DV->SDI bridging - among a host of other things... including supporting realtime SDI 8bit and 10bit effects and color correction.
Re: Re: Information Rules
CODEC can stand for either COder/DECoder or COmpressor/DECompressor. But honestly you are the first that I've ever seen use "COder/DECoder" (but I didn manage to find that at acronymfinder.com so I know yer not just making things up.
Lethal
CODEC can stand for either COder/DECoder or COmpressor/DECompressor. But honestly you are the first that I've ever seen use "COder/DECoder" (but I didn manage to find that at acronymfinder.com so I know yer not just making things up.
Lethal
Re: hhhmm
Thanks. I am trying to make an effort to be more civil too. Like I said. This site is great and the forums are good here too. I would hate to see it slip into a powerpage.org kind of situation.
It is interesting to see what peoples' priorities here are. I work in a film and braodcast world so we have a lot of pro features we need that dont look great on a press release...
It is really cool to see so many FCPers here.
Thanks. I am trying to make an effort to be more civil too. Like I said. This site is great and the forums are good here too. I would hate to see it slip into a powerpage.org kind of situation.
It is interesting to see what peoples' priorities here are. I work in a film and braodcast world so we have a lot of pro features we need that dont look great on a press release...
It is really cool to see so many FCPers here.
Internet computing...
The problem is that network rendering (compositing) is largely IO bound. Once the data has made it to the machine, it doesn't matter how fast the render box is. Rendering over the internet, as a result, is impractical. Even if you had 100 super-fast boxes available on the other side of a $1000/month T1, a single lowly ghz machine on a local (hopefully gigabit) LAN will beat them mercilessly.
Likewise, this is why distributed computing, while popular, has a long ways to go before it can become profitable. It only makes sense if the CPU cycles/bandwidth on both ends are free. (i.e. academic projects)
3D rendering, while CPU intensive, falls to the same problem. This is why you won't be helping render Toy Story 3 any time soon.
Anyways, to return to the topic, NAB is April 7-10. FCP4 will be released. (It should have come out six months ago).
My predictions: Film/HD timecode/editing will now be integrated. Cinema Tools will no longer be a stand-alone project.
Hopefully Apple will fix the subclip bug issue plus the other major bugs.
Background rendering is a possibility I'd like to see.
Moving to the Cocoa toolkit would be nice, but probabally impractical at this stage in development.
Network rendering is an interesting possibility. Coupled with a couple of xServes and a xRaid, Apple could begin attacking the mid-range Avid market. (http://avid.com/products/ds/)
This would be an interesting response to XpressDV that would be in the best interest of us Joe Users. Avid's gone too long without any real competition.
The problem is that network rendering (compositing) is largely IO bound. Once the data has made it to the machine, it doesn't matter how fast the render box is. Rendering over the internet, as a result, is impractical. Even if you had 100 super-fast boxes available on the other side of a $1000/month T1, a single lowly ghz machine on a local (hopefully gigabit) LAN will beat them mercilessly.
Likewise, this is why distributed computing, while popular, has a long ways to go before it can become profitable. It only makes sense if the CPU cycles/bandwidth on both ends are free. (i.e. academic projects)
3D rendering, while CPU intensive, falls to the same problem. This is why you won't be helping render Toy Story 3 any time soon.
Anyways, to return to the topic, NAB is April 7-10. FCP4 will be released. (It should have come out six months ago).
My predictions: Film/HD timecode/editing will now be integrated. Cinema Tools will no longer be a stand-alone project.
Hopefully Apple will fix the subclip bug issue plus the other major bugs.
Background rendering is a possibility I'd like to see.
Moving to the Cocoa toolkit would be nice, but probabally impractical at this stage in development.
Network rendering is an interesting possibility. Coupled with a couple of xServes and a xRaid, Apple could begin attacking the mid-range Avid market. (http://avid.com/products/ds/)
This would be an interesting response to XpressDV that would be in the best interest of us Joe Users. Avid's gone too long without any real competition.
It's coming
Final Cut Pro 4 is coming.
I am 100% positive.
It's going to have mad-sexy love with Shake 3 (includes: warper, morpher, audio, swamp -- see xserves, a new curve editor, and much more).
It's going to have more pro audio support, realtime EVERYTHING, revamped titles, super high quality rendering (coltrain), and will be based on XML for the unix nuts.
It's funny... I was poking around and I came across this very informative email... I probably said too much, but there is much more to say
- RMG
--> Poking around in all the wrong places
Final Cut Pro 4 is coming.
I am 100% positive.
It's going to have mad-sexy love with Shake 3 (includes: warper, morpher, audio, swamp -- see xserves
, a new curve editor, and much more).It's going to have more pro audio support, realtime EVERYTHING, revamped titles, super high quality rendering (coltrain), and will be based on XML for the unix nuts.
It's funny... I was poking around and I came across this very informative email... I probably said too much, but there is much more to say
- RMG
--> Poking around in all the wrong places
FCP4 to support new Panasonic VTR
Perhaps the most important aspect of FCP 4 will be its support for a new Panasonic DV VTR that works in the 4:2:2 color space.
All DV currently operates in the 4:1:1 colorspace, which means that a lot of information in the video is thrown out to allow for smaller files and lower transfer speeds.
With Firewire 800 and a decent amount of drive space, the new deck will allow for less compression and put DV on scale with standard broadcast edit set ups.
Pinnacle Cinewave and a few others will feel the pain as they are left with what amounts to overpriced Real Time cards. The whole PCI capture card industry's advantage, the 4:2:2 color space, will dissipate.
Translation: we can work in DV and have sharp, crisp text and graphics that look as good as a million dollar production. DV will become fully professional and not just a low budget cable TV commercial alternative.
Perhaps the most important aspect of FCP 4 will be its support for a new Panasonic DV VTR that works in the 4:2:2 color space.
All DV currently operates in the 4:1:1 colorspace, which means that a lot of information in the video is thrown out to allow for smaller files and lower transfer speeds.
With Firewire 800 and a decent amount of drive space, the new deck will allow for less compression and put DV on scale with standard broadcast edit set ups.
Pinnacle Cinewave and a few others will feel the pain as they are left with what amounts to overpriced Real Time cards. The whole PCI capture card industry's advantage, the 4:2:2 color space, will dissipate.
Translation: we can work in DV and have sharp, crisp text and graphics that look as good as a million dollar production. DV will become fully professional and not just a low budget cable TV commercial alternative.
Re: Re: 1st with FW800
Too true, here's a good QT based card for OSX that might interest peolple looking for Serial Digital Interface (SDI) i/o options without the heavy cost of real-time rendering cards
definately, intergrated into both high end pro-tools rigs to consumor devices such as the iPod - mobile HD recording with 17" Powerbook and 40G iPod
Whatever happened to Yamaha's mLan??
Too true, here's a good QT based card for OSX that might interest peolple looking for Serial Digital Interface (SDI) i/o options without the heavy cost of real-time rendering cards
definately, intergrated into both high end pro-tools rigs to consumor devices such as the iPod - mobile HD recording with 17" Powerbook and 40G iPod
Whatever happened to Yamaha's mLan??