Avid has identified an incompatibility with the early 2011 17" MacBook Pro (model MC725LL/A with Thunderbolt port) when used with a Magma ExpressBox1 expansion chassis and a Pro Tools HD Native Card. The following error message, "Unable to find an Audio Interface attached to the first HD card", is seen when launching Pro Tools HD 9 with an Apple MacBook Pro (early 2011 model) and Pro Tools HD Native hardware. For additional details, see Knowledge Base article 396031 Please Note This is only with HD Native core cards in the specific configuration listed above. Other qualified MacBook Pro models do not have this incompatibility: Pro Tools HD 9.0 Qualified Apple Computers

In a post back in November I said.... I saw a picture recently in all the Pro Tools v9 frenzy of a setup with what looked like some very compact control surface in front of a screen with an Apple keyboard, all of which didn’t take up too much work surface real estate so I did some digging around and found that it was Euphonix MC Control ethernet connect control surface that now works with Pro Tools. Well having done some more research I bought one and have set it up on my desktop... However although I have a similar configuration to the top picture I am not sure it is the best one. This set off a set of questions..... Which hand to use to operate the touch screen? Should I angle up the MC Control so I can see the touch screen better? Should I move the MC Control off to one side? Left or right? - I am right handed. I am also aware that my mouse is closer to the desktop edge and so I am suffering potential RSI problems more easily. It is currently set up centrally on my desktop and the photograph is slightly misleading as there isn't as much space in front of the keyboard as the picture suggests. I would really value any comments or suggestions of how to get the best out of my MC Control. Thanks.

Following my posts on the problems with Canopus boxes and Pro Tools 8.0.3 here, here, here and here as well as the jerky video problems I have posted on and the video compendium I posted about here and here, there has been another interesting post on the Pro Tools 8.0.3 jerky video thread on the Digidesign User Conference. 'DigiTech Supt' has posted.... There are several fixes in 8.0.4 and 10.6.4, but at least one outstanding issue when playing video on a 2nd monitor that appears to be OS related, which we're working with Apple to implement a fix. Can anyone on 8.0.4 and 10.6.4 who is seeing jerky/stuttering playback when using a Mojo or Canopus device let us know the specifics of your configuration and the size/codec being used for the video? Also 'Anibal' has posted.... using Canopus, DV and different sizes, very smooth playback but eventually crashing when opening sessions with video in firewire

Had a scary problem earlier this week at BBC North with a Pro Tools system appearing not to write session files to the disk, either normal Saves or Save Session As or even Session File Backups. Audio files, AudioSuite processed files and Fade Files all have been written to the drive so it doesn't appear to be a permissions issue or a drive failing. I did a search for all files created or modified yesterday and no session files came up, just the audio and fade files. It is as if Pro Tools was appearing to save but not actually writing the files to the disk. I did a Deleted files scan of the drive with Data Resue 3, having taught it what ptf files look like, and found no recent copies of the session in question. System is a G4 1.25 Mac Mini running Mac OS 10.4.x and Pro Tools 7.4LE with a 002R interface and all drives have Oxford Chipsets. In researching the problem on the DUC I came across this post... We're investigating this and see a few other web reports of this happening with other apps, so we're looking at possible causes, including OS services that may play a part. __________________ Avid Audio Tech Support I have subsequently done a full deep scan with Data Rescue 3, and having taught it .ptf session files, it found over 1000 session files on the drive. I opened the 500 sessions that were larger than the latest session on the drive (300k) and although I found about 10 session files from the project in question, they all preceded the latest session on the drive.  This to me confirms that Pro Tools never wrote the files to the drive during that last day. Having satisfied myself I couldn't retrieve anything from the drive, I then ran a benchmark test on the drive, which is a Seagate 2.5" Momentus IDE drive in a MacPower case with Oxford chipset. I benchmarked it to a recent Seagate SATA 2.5" drive and it compared very well. Then I used the Integrity Test in Drive Genius II, set to write 16M files in random write for 30 minutes, and it proved to be very reliable. Finally I completed a full surface scan with Drive Genius II and it found no bad blocks so I believe the drive to be in A1 condition.

Following my posts on the problems with Canopus boxes and Pro Tools 8.0.3 here, here and here as well as the jerky video problems I have posted on and the video compendium I posted about here and here, there has been another interesting post on the Pro Tools 8.0.3 Big Bug thread on the Digidesign User Conference 'redj' posted after the 8.0.4 release... Thanks Avid for the update ! But thereʼs already a mistake... For me, this bug happened by two ways : The first one is now resolved (opening a session). But the second one is not : when I remove video from firewire (deselect Video Out Firewire) PT crash ! But only if video track is offline. If video track is online, it works. Strange. Does anyone can confirm this bug ? 'TommyT' confirmed it... Damn,,, you're right, Bug confirmed here... Guess we should change the Thread name to 8.03 Big Bug & 8.04 Smaller Bug :) .... DigiTechSupt officially confirmed the 'small bug' and the work round... Ok, thanks for the report - we've been able to repro this and are looking into a fix. Not sure whose end it's on yet - us or Apple, but we should be able to determine that shortly and I'll reply when I know more. For now make sure to keep the video online when enabling/disabling video out FireWire (stating the obvious, yes..!). Avid Audio Tech Support

Some folk have had trouble finding the Release Notes for the 8.0.4 update, so here are some URLs... Release notes... Read me file!! (Known issues list)... Mac leopard 10.5.8 and snow leopard 10.6.2 & 10.6.3 download page... Also a new bug has already surfaced in Pro Tools HD 8.0.4. You read the full thread on the Digidesign User Conference. 'Mark the amazing guy' posted... Apologies if this has been posted already- I couldn't find anything about it. When working with Timeline and Edit selection unlinked, if you -select an area with edit selection, then -move your timeline marker, your edit selection gets wiped every time. Can anyone else confirm this, or know of a workaround? 'laki' added.... Well Mark, I saw this just today. Oddly enough, it's not the selection that gets wiped (the markers are still where they were in the timecode track). PT is actually deselecting the tracks that were selected. If you have track selection follows edit selection enabled, you can reselect the tracks and you'll see that your selection has not been lost. And, not to be a stickler for the rules, but you might get some more responses if you specify your system specs. See the "Help us help you" sticky in the PTHD Mac OSX forum. Good luck. I usually don't work in unlinked. 'DigiTechSupt' quickly chipped in and confirmed... Mark - Thanks for the report. We've been able to verify this and will get it in the queue for a fix asap. The best work around we can find (and it’s not really a valid workaround) is activating “Link Track and Edit Selection” and then when your edit selection has been blown away from the timeline just selecting the track again remakes the selection (it’s still stored in the timeline, just not in the edit). __________________ Avid Audio Tech Support

'MX582' posted this question recently on the Digidesign User Conference having experienced some problems when copying Pro Tools sessions from one drive to another... So we did a session the other day on our internal drive in our mac pro running pro tools 8 and some how it saved all but a few of the audio files created during that session into a separate external hard drive that was hooked up to the computer. It created a session folder in that external drive with the session name but the only thing that was in it was the audio files folder with just the new files we recorded. I'm completely puzzled how this would happen. We didn't have round robin allocation set or anything like that as far as i know... 'DigiTechSupt' asked.... Were you using a template or a previously created session that would have used the other drives folder for it's audio? 'johnnyv' added... Digi, we just had the same issue. Here's our situation: Brand new Harpertown 8-core, fresh internal drive, fresh Leopard install, fresh PT8 install. A client brought us a session from another city, we copied that session in its entirety onto our hard drive. It was a 7.4.x session, which we opened in PT8. We worked on the song for several hours. When we finished the session, we put a full copy back onto another hard drive owned by the client. When he got home, he said that many of the audio files were missing. We went into the audio folder on our drive, and many of the files were there (roughly half). We could open the session fine, and we could see all the files, but WHERE WERE THEY? We found them on another hard drive hooked to our computer...just as the guy described above. On that drive, there was a folder with the session name, and inside of that, there was a single "Audio Files" folder which contained JUST THE MISSING FILES. So, IN THE MIDDLE OF A SESSION, for some reason, the location of our recorded files started to be stored on another hard drive! I was totally stumped. 'Rail Jon Rogut' correctly pointed out... Just a heads up - never copy sessions with the Finder when sending out a copy for a client on their drive.. Use Save Copy In... and select to copy all the audio files. 'Howardk' agreed with Rail... You can't go wrong if you follow Rail's advice on this. . . and by the same token, anything someone brings in on a transfer hard drive, open it on the drive, and use Save Copy In to copy it over to your work drive. THere are other ways to do this, safely, but this is simplest. 'johnnyv' responded... Rail - Yes, that is advice well taken. From now on, that's what we'll do.  However --- I can also imagine us keeping backups for clients, and it's troubling to know that PT is somehow switching up hard drive locations without anyone's knowledge, so we should definitely get this sorted out. We also had no round robin allocation selected. 'Rail Jon Rogut' also suggested.... Make sure the drive in the Workspace was a "Record" drive. 'johnnyv' replied... Well, that's the weird thing, Rail. Half the audio files went where they should go...in the Audio Files folder in the ProTools Session Folder. The other files ended up on some random drive we have attached to our system; a drive having absolutely nothing to do with the session, PT8, the client's files, etc. And this all happened within the span of one recording session over the course of about 8 hours. Totally weird. 'Rail Jon Rogut' asked the right question... Can you open the session and check the disk allocation for the tracks which went to the wrong drive? 'DigiTechSupt' then asked... And did you possibly have 'Round Robin' enabled in the Disk Allocation window? 'mixboy' added... I have also experienced this. Disk allocation shows everything going to the correct place and round robin NOT selected. Yet files end up on some other drive - a drive on which that project has never resided before. Internal for me, as I only use externals for transfers/backups and they are powered off before I boot PT. But I have 5 internals in my G5. It's literally like PT randomly decided to change disk allocation yet leaves no bread crumbs for finding out where they went. 'johnnyv' replied.... Digi, no Round Robin selected (checked it when this happened). It's just like Mixboy Bob suggested...it's like ALL OF A SUDDEN PT decides to put audio on some random drive without letting you know. I've never seen anything like it. Rail, will have to get in front of the session again to answer your question 100% accurately. We were checking many things when we found the problem, and I want to answer your question accurately...which I will do later today... 'carlos santana' suggested a possible work round... to not allow the system to have this error again you must set the recording drive to (R) and all of the others to transfer only (T) this way protools will only reccord & work on the one you want it to & not n the others 'audiogeekzine' suggested.... Also get to know the Copy and Relink function in the project browser 'Howardk' followed on.... Yes, the project browser is very handy for this. . . just sort the listing by drive/folder (click on the header way over on the right) and if anything is in a different drive or folder it is easy to see, and then you can right click on the filename to copy and relink. Everyone gets fooled by this and sometimes it can be very serious (when mistakes compound). . . I believe there really should be an indicator on the top of the edit window to goes red whenever there are files outside of the designated audio folder (ProTools really should have a dashboard with key information like this). . . .here is one thread on this topic. DigiTechSupt then stated... Pro Tools has never, in any test I've done, placed files randomly on a drive. I've heard this complaint on several occasions and have even gone to customers studios to witness it, only to find something in their workflow that's causing the problem. I'm not saying it's not possible - well, it really shouldn't be - but I've yet to see concrete evidence that it's putting files randomly on a drive. 'johnnyv' replied.... I'd be THRILLED to know that we have something set "wrong". We haven't been using PT8 for very long, so I hold it entirely possible that it is, in some fashion, "operator error". BUT, in this case, I DON'T THINK THAT'S THE PROBLEM. Rail, Digi and others, check this out...when I go to the session in question, the Disk Allocation shows NORMAL, it points all tracks to the proper Audio Files folder within the Session Folder. YET, only half the audio files (well, actually less than half) are actually there...the others are on a random drive ON WHICH WE HAVE NEVER EVER RECORDED AUDIO in a folder with the proper session name and inside of that, a single folder named "Audio Files" which contains the other files that we recorded ALL ON THE SAME DAY. So, SOMEWHERE DURING OUR 8-HOUR SESSION, somehow the files were directed elsewhere. I must say, having used PT for years now after starting on Sound Tools back in the 1990's, and owning a D-Control, HD5 Accel, Waves Mercury, etc etc, this is a weird one, and I have no explanation for it. I totally appreciate everyone's suggestions, and as Rail pointed out, I'll never copy via the Finder ever again. And I'm going to learn about the things others have suggested upthread. But still, something had to make this happen, and I have NO idea what it is/was. 'DigiTechSupt' then asked.... If you drag and drop an audio file from a different drive and do not have 'automatically copy on import' preference enabled, it will keep the audio file at it's original location and play it from there. Were all these files recorded in the session or were some imported? Now, is it possible that round robin was enabled at any point? What is the nature of this other drive - how do you know for certain that audio was never recorded to it? Was the drive ever used to move a session from one place to another, possibly to another computer? If you go to the Regions bin and 'show full path names' - do the audio files path indicate anything about how the audio might have ended up on that drive? Was the drive name ever changed?  Was there a session template used and, if so, does the template possibly have incorrect drive allocation? 'johnnyv' replied... Digi, thanks for taking an interest. Let me check into your questions and try to answer them accurately (can't do it right now, as I'm working at the moment). To be honest about Round Robin, I never even knew about that until this issue popped up and one of my assistants looked at the setting (it was not checked). We only installed PT8 about two weeks prior to that session, and perhaps you can answer whether or not RR is "ON" by default when installing PT8 fresh for the first time on a fresh drive with fresh system, etc. I can say that the drive that this went on is a backup drive which only holds my BFD (drum software) files, and some weeks back, I copied my entire PT7 system drive onto that drive just so I had a backup in case anything ever went wrong. But, as far as I know (and I'm the main one in that room), we have NEVER ON A SINGLE OCCASION used that drive as any sort of a PT recording drive...that's just another weird element to this. I have a Mac 8-core Harpertown with 4 internals...we record PT onto two of those internals...this drive was an external drive which happened to be hooked to the system in case we needed BFD files. I'll report more later... 'smlworld' suggested... I cannot recommend these 'videos' highly enough. Browser relinking is covered and all prefs are discussed in detail. As a long time PT user (back to SD2) I really appreciate Kenny's command of Pro Tools. 'DigiTechSupt' asked.... If there's some way we can get a concrete example of this occurring outside of user error, obviously we'd want to get it fixed. I've tried personally to make this occur on several occasions, replicating customer setups as closely as possible, but without success. If you see this occur, please note everything about the current state of your system, plus anything prior to the incident that you can recall, even if it seems irrelevant. 'studiojimi' posted their experiences.... I had an issue like this over the weekend and I thought I had lost my guitarist's overdubs because they weren't on the drive Ii was using and i had not noticed that my back up drive was online during the session and some of my templates tracks were still allocated to the BU drive because it used to be my internal. I recently purchased a terra drive and now that's inside I was lucky that the session at least put the new info in fresh rogue folders-- probably because the old backup sessions were in a project folder of their own...otherwise i would have been hosed because I had dragged and dropped to the BU drive in that project folder when backing up.  I usually manually back up the files by date and the fade files and the old sessions and backup sessions as well as the audio but as you guys know sometimes when you are tired or distracted...you do a walk away and .... hmmmm that could have been a disaster. I feel very lucky cuz I had already called the client to tell him I had lost the files...then...miraculously I found them in those new rogue folders....and I named that a blessing immediately. 'soundboy35' asked.... So any ideas? I'm curious about this as well. While we're on the topic of templates being the possible culprit, if I open a template and create a new session from drive A, then save it to drive B, and change the disk allocation to drive B, is this problem going to happen? 'rinky' added... This weirdness also happened to me. I noticed that my sessions were gradually taking longer to process fades and audiosuite edits. Come to find out, my main system drive had some of the fade/audio files on it. I checked the disk allocation and sure enough, some files were being written on my system drive and some on my original 7200 rpm external drive! No idea when it started to do that since I hadn't made any changes to prefs or to external drives... just snuck up on me! But ever since this problem my edits have been to a grind claiming that my my hard drive isn't fast enough, etc. even after correcting the disk allocation issue. So guys, you are not alone on this. 'DigiTechSupt' asked... For us to make any kind of real traction on this, we're going to need details about the history of a session Which drive it was created on? How was the session created (File>New Session, from a template, etc) Are you using the File>New Session>From a Template function, or opening a Pro Tools Session file (by double clicking or otherwise) as your template? Did you use any custom disk allocation at any point Was round robin ever enabled? If you moved the session at any point how did you do it (drag and drop, backup utility, etc)? Did you ever use Save Copy In to make a copy of the session and, if so, did you copy all audio files? Which drive did you save it to? Is the preference to automatically import audio to the audio files folder enabled or disabled? The more detail you can give, the easier it will be to determine what may be going wrong. 'timragnur' responded... I've been talking with 3 colleagues of mine who has, like me, experienced this very problem. To be excact, it have occured with sessions that were made in one place, then moved (Finder, drag-and-drop) to another computer. Then, what you record/consolidate/audiosuite from this place will be put in another available harddiscs, sometimes the internal, sometimes the external. A session folder will be made in the root with the new audio files and fade files only. Obviously when you move the session, files will be missing. They were all originally made in PT HD 7.3 (new, not templates), but problems occured long after it was opened/saved with PT HD 8.0 No changes was made in the Disc Allocation, and all links appeared fine refering to the right folder. It doesn't necessarily occur again within a troubled session. Save Copy In was not used. I know this might create a confusion, but like one wrote earlier in this thread, in the last 2-3 years using PT HD 7.3 i've had this problem maybe 5 times (with same kind of random choice harddisc allocation). Knowing the system very well, I think we are talking about a bug getting bigger with version 8.0. 'Sean Russell' also suggested this possible work round.... Change every drive you don't need in the session to 'T'. That solves the Disk Allocatin weirdness. 'TimNielsen' added.... I just want to chime in here too and say I have had this problem before as well. I have also had on many occassions, fade files that will regenerate in their 'original' location where they were first built, even though I have all my tracks set properly in Disk Allocation. Like, if I delete all my fades, then relaunch the session, a bunch of the fades will still redraw on the wrong drive. The only solution I found in those cases was to quit PT, take that drive off-line, delete all fades and open the session. When PT can't find that drive it wants, then it would seem to follow disk allocation properly. I have also had the very wonky issue with PT8 where upon importing session data, tracks, and telling PT to 'copy' the audio, that PT will get some random part of the way through, and then just 'reference' the rest of them. If you aren't watching the progress bar, and don't see it 'jump' to the end, you would have never known. As far as I know, this is still present in PT8.03cs2. I now have to check upon every import that PT copied the audio. About 1 in 5 times, it will copy 'some' and reference the rest. It's a disastrous bug that really screwed me several times until I realized what was going on. Save Copy In does seem to work, I haven't had it miss any files so far. But importing session data seems still buggy. Just posting because maybe these are all somehow related. Well I must agree that I have experienced situations when folders with some audio files or fade files folders have started to appear on other drives, but I have always found it to be due to Disk Allocation to be set to 'the other drive' Even for fade files. I completely agree with 'DigiTechSupt' that you must be very careful when moving sessions from one drive to another especially when using the Finder. The safest way to move sessions is to use the Save Session Copy, but who wants to boot up Pro Tools to move a session from one drive to another when you can drag and drop from the Finder? The workround that 'Sean Russell' and 'carlos santana' should work but I would find it very difficult to keep switching drives from R to T in the Workspace Browser depending on what session I was working on. The suggestion from 'audiogeekzine' to get to know the Copy and Relink feature is very well made and one that I have posted about here too. I agree with 'smlworld' and cannot recommend Kenny's videos highly enough.

'CEM3387' asked recently on the Digidesign User Conference about a problem with BlackMagic Intesity and ProTools 8.0.1 LE..... Whatever codec and resolution, data rate I have tried on the B.M. Intencity card it looks totally terrible when I play the video files back in ProTools thourgh the B.M HDMI out, the files are so pixelated and harsh. If I play the same files in their own Media Express software it looks decent not good. Better resolution but still harsh. What kind of codecs do you guys run? Is there any adjustments I can do apart from the ProTools menu for quick time which does not affect the quality at all at this stage. It looks like a very low rate QT file for a Cellphone played at 1920 x1080. MacPro 8core 3.0GHz, 6GB RAM, 10.5.8 ProTools LE 8.0.1 QT 7.6.6 Black Magic 3.6.1 'JeromeOD' replied... I use prores with the same kit and software as you and all is great. I'm not certain about the quicktime version though, is that definitely what it should be? Gary Nattrass added... I am running virtually the same system but with QT V10. Like Jerome Pro res full HD files are no problem. Have a look at the BM card settings in system preferences there may be something adrift there. CEM3387 responded... Thanks for the replies. First of all it the harshness was a "AV MODE" setting on the display I am running. As soon I found that bastard and disable it, it looks more natural. "I am running virtually the same system but with QT V10" Do you run OS 10.6.x or 10.5.8? "Like Jerome Pro res full HD files are no problem." OK I´ll see if they can prep that for me. What version HQ, regular or LT? "Have a look at the BM card settings in system preferences there may be something adrift there." I un-checked the "Remove field jitter when video is paused" that was recomended somewhere else. Other that that I do not know what could affect output. Output is set to HDMI NTSC/PAL and output processing it Off. Also I cannot get the display the whole picture frame regardless of setting on the monitor setting. The monitor is native 1920x1080 and I have tried with movies at native 1920x1080 and still the picture is a bit cropped. 'Newpostguy' suggested... Open quicktime pro and convert it. You dont wait for picture department that way and dont look like "oops I forgot I can only run this type of codec" guy. Convert to apple pro res 442 (mpeg streamclip or QTsync will do this for free almost as good) Make sure the video is 720p or 1080i if HD (BMI does not do 1080p) It would be wise to learn about various codecs and why they are used at different times. CEM3387 replied... "Newpostguy" THANKS! Im am now tempted to change the the subject of this post to "NO Problem with BlackMagic Intesity and ProTools 8.0.1 LE" Mpeg Streamclip For the win! It can batch convert too! "Make sure the video is 720p or 1080i if HD" (BMI does not do 1080p) Ahhh, did not know that I love progressive so 720p it is then. Thanks a lot for solving my problems!

'D'Animation' asked on the Digidesign User Conference if anyone else was having problems with automating SpeakerPhone, he wrote... Just a quick check to see if anyone else is having issues with Speakerphone 2 losing its automation presets/snapshots? I have about 6 different effects loaded into the first 6 preset slots so I just automate the preset index to switch between fx but every so often it loses all the preset settings within the plugin (the actual 'automation preset index' automation lane in protools keeps its data within the track though) and resets to the default 'bakelite phone' setting on all presets? Plugin is on a aux on its own being fed via prefader sends from VO tracks Pt's HD 8.01cs1, HD2 system, Mac OS 10.5.8, Mac Pro, 8 core Harpertown, D-command, Speakerphone 2 v. 2.0.3. 'minister' replied... Oh yeah. Got bit by that when I did some nice automation for some source music moving within a scene. Opened the file the next day to review with client and it was all ferkakta. All subsequent scenes were all a shambles as well. Ended up taking the time in the review session to reset and print the filters. Now, I always do it. 'PT Lover' chipped in with... I don't use Speakerphone myself, but have you guys read this? 'D'Animation' came back to say... Have to say I generally don't have everything write enabled and none of the presets use the sample bay so not sure if its just something funny going on - it is random and infrequent is the only blessing. I wish printing was an option (at the moment) but still lots of ADR and PU's coming in so I'd only end up redoing work. Its so obvious but I will admit to not thinking of it - Once everything is in printing is the safest bet alright ! 'PT Lover' later asked... Did you get this sorted out? Have you discussed it with Audioease? I'm considering this plug-in but I'm tired of workarounds. 'D'Animation' replied saying... No solid answer yet as its totally random and not repeatable to test but it is a great plug for 95% of the time. The current series I'm working on has lots of radio/speaker situations for vo and at times its replaced up to 4 plugins in a chain to do the same fx, kinda wish it was TDM though as, the way i use it, it lives on an aux! Luckily I've never lost any settings as i've managed to import the correct plugin data from a back-up session 'PT Lover' replied... Ok. Thanks. It sure does look and sound like a sweet plug-in. 'Pirate Post' added to confirm... Love the Plug-in but the automation just doesn't work. I always print it. 'PT Lover' asked... Are you using 2.0.3? 'Pirate Post' replied... Just checked, I'm on 2.0.2. I'll load up 2.0.3 and report my findings. PT Lover replied... Thank you. Pirate Post then confirmed.... That would be a big NO on the automation working correctly in version 2.0.3 PT Lover acknowledged... I see. Thanks for checking. So it seems as if Audio Ease have a little work to do on this one. As of today it still isn't fixed.

iZotope have released this announcement regarding a potential problems with iZotope software causing problems with Mac OS 10.6... Attention Mac OS X Users: We've recently learned that under rare circumstances, installing an iZotope product or demo and then applying any Mac OS X 10.6 update can cause some computers to experience problems booting. We have identified the cause of this issue and have provided a simple fix below. Please download and install this patch immediately, even if you have not experienced any issues at this time. Also, make sure you delete and re-download the latest iZotope installers for Mac OS X. Please note that as of today (May 7, 2010), all of the Mac OS X installers on the iZotope website have been updated so that they no longer cause this issue to occur. iZotope Mac OS X 10.6 Patch If you suspect your computer has already been affected by this issue and you are unable to boot your computer, please follow the steps to fix in the iZotope Knowledge Base. We apologize for any difficulty this has caused. Unfortunately, this issue was unpredictable and related to a rare interaction between the install process and security measures that Apple recently introduced in Mac OS X 10.6. We appreciate your understanding, and please don't hesitate to contact us directly with any questions or concerns at support@izotope.com. Sincerely, The iZotope Team

Following my posts on the problems with Canopus boxes and Pro Tools 8.0.3 here, here and here as well as the jerky video problems I have posted on and the video compendium I posted about here and here, there has been another interesting post on the Pro Tools 8.0.3 Big Bug thread on the Digidesign User Conference.  'zoing123' has posted.... Gentlemen. Fear Not. It _is_ a known BUG. The work around is to take the video to internal before closing. I went nuts figuring this out, but thats it. Spoke to a real Digi teck and they are working to fix this. I have been flawless after I found this. 8.02cs2 /10.6.3 on an  002 box. So hopefully this will provide folk with a viable work round until Digidesign can fix it.

Following my posts on the problems with Canopus boxes and Pro Tools 8.0.3 here, here and here as well as the jerky video problems I have posted on and the video compendium I posted about here and here, there has been a couple of interesting posts on the Pro Tools 8.0.3 Big Bug thread on the Digidesign User Conference. Matt Faddy posted.... I know this won't help your immediate problems but we were using the ADVC 100 and 110 's for years and always had constant issues with them (I have 8 broken ones stacked up in our machine room) - They were unbelievably temperamental and over the years I have grown to despise them but unfortunately they were always a necessary evil. We switched to Black magic intensity pro pci cards a few months ago and they are brilliant. Rock solid, support a few formats and have HDMI as well as component and composite O/P's - the best thing about them though is they are even cheaper than Canopus ADVC 110's ! The only drawback is they use an extra slot so if you're running an HD3 system you'll need an expansion chassis. and 'filmsdunjour' responded... Attention PAL users.  I've posted a thread here. The Blackmagic cards have a major problem in SD PAL (haven't tested SD NTSC but I guess it's working fine, 1080i50 is perfect) using ProTools HD 8.0.3cs(1&2) on Mac OS X.5.8, even with the latest Blackmagic drivers. Image quality is terrible (jerky and aliased) on both HDMI and SD analog outputs. The outputs are perfect on Final Cut Pro, so it's a software issue. I think it's related to the way Pro-Tools automatically sets-up the output's resolution. Final Cut Pro works fine because the set-up is manual (you have to change it when going from SD-HD-PAL-NTSC) Sadly the ADVC110 is the only option (don't know about mojo) to have a "nice" image in SD PAL... Clearly this problem still has some mileage to run before it is resolved!

MIKEROPHONICS asked this question on the Digidesign User Conference recently... I have just installed one of those esata extender cables from OWC to the motherboard of my xeon mac pro 3ghz - the hidden unused esata ports. Ok it cost next to nothing, apart from a painfull evening taking my macpro hd3 apart. So far my initial obs have not been good. Backing up one of internal drives to my esata drives , the finder stalled and crashed. One of my Freelance chums has also had the same experience and was disappointed too. Anyone else any experience of these cables? 'jeremyroberts' responded with... eSATA is the modern day equivalent of "SCSI Voodoo". DEPENDING on your eSATA controller, SOME external devices will work, Some won't. Some look like SCSI to the CPU (must reboot to mount/unmount), some are removable (like firewire). Some enclosures simply work, some will only work with a specific host card. Much has to do with the controller chip on the external device. I feel your pain. I lived through an "eSATA compatibility challenge" last week while trying to get an expresscard to work with my macbookpro. I haven't found a definitive "this works, this doesn't work" thread anywhere. I read that some external enclosures that support multiple interface protocols (usb, fw800) may give some eSATA interfaces trouble -- this doesn't make sense to me, since I have 4 eSATA devices -- and some simply refuse to work with some hosts. All have some combination of USB or FW800 or FW400 and eSATA. So I don't get it. It's voodoo. Back to the future, yes? 'jmdigi' added... I've been using the eSATA cables on my 2.66 QuadCore MacPro to connect to OWC quad interface drives for several years with very good results (no issues). The only catch is remembering that the SATA controller on the MacPro motherboard 'sees' those drives as internal-- no hot swapping. A reboot is required to add drives to the bus. MIKEROPHONICS replied... Thanks for the replies chaps. Jeremy, if you find the vudoo mojo please let me know. I was aware of the no hot swapping, I don't however get why the finder would crash - ie sit there with the file txfr half copied and refuse to complete. My shiny new Gdrive 2T triple interface has been so far otherwise exemplary, I will google around when I get some more free time and see what I can come up with I wonder if a chat with OWC tech support may help? even though I am UK based. Mike Thornton (Me!) offered... I have heard mixed reports about using the internal sata ports as esata ports with the extender. In the end I decided to use an esata pci card which is working fine for me so far. MIKEROPHONICS replied.... I don't have a spare slot as have an HD3.  I thought it might be a free lunch - but alas no. I have had two crashes with my Gdrive quad 2TB and am going to ignore my efforts. Back to quitting protools and using fw800 then..... so that I don't loose my mojo! So it seems fairly conclusive that trying to use the free internal SATA ports in a Mac Pro is not a reliable solution.

There is a growing thread on the Digidesign User Conference on 9019 and 9031 errors on Pro Tools 8.0.3 It was started by Nathaniel Reichman asking... Since moving from the various 8.0.1 releases to 8.0.3, I frequently get the message: "DAE is having trouble keeping up. Your disk may be too slow...firewire, etc., etc. (-9019)" which is followed by a beachball and then: "DAE error -9031 was encountered." And this repeats until we quit the app and relaunch. Sometimes hours go by with no problem, sometimes we get this 3 times in an hour. We haven't seen this in PTHD, only on the PTLE/CPTK system listed below. We tried trashing databases and volumes folder. After some system and workflow checks Reichman confirmed... Nothing has changed in my typical post workflow or drive usage since PT 7.3. Thanks for posting, but I really doubt the non-contiguous file theory. If that were true, none of my projects would have worked with any version of Pro Tools. For now, I blame the .3. "Garnoil" responded.... Ok, so it must be .3. I am on 8.03 and although I had one massive, annoying, problem (0922 too many files corruption), 8.03 *at least for me*, has been a great improvement. I run HD2 and push it to the limit, I mean 192 voices (160 tracks+) + full HD film at 2k resolution. So far, so good but of course there are lots of bugz to fix, some worse than others. Good luck! Then Digi Tech Support weighed in... I see you have an eSATA hotswap tower in there - is that what you're using for playback/record? If so, have you tested with other drive types? 9019 is a drive error related to drive communication speed - we usually see it on PC's where drives are not in DMA mode. The 9031 error is usually related to having illegal characters in the drive, file or folder name - is that possibly the case here (keep in mind that previously fudged illegal character acceptance is no longer possible, so what may have 'worked' before no longer will)? Reichman responded.... Yes. And I know it's not officially approved, but it's performed flawlessly every since PT 7.3 on a G5. I thought I cleaned out all of my illegal characters in the PT6-7 transition. Thank you for writing back so quickly. I'll report back if I learn anything. The "smpkeys" chipped in.... I just experienced this same problem. I've been on 8.0.3 for about 2 weeks and have not seen this, however , tonight I was using the playlist lanes view for the first time, and that's when it occurred. All my drives are internal SATAs - 1 for OS, 1 for audio, 1 for samples. Not using any video in my session, and no illegal characters. Reichman - have you found a solution with your setup? Reichman replied... Haven't found a solution yet, primarily because it is happening infrequently now. Occurred once yesterday when opening an AudioSuite plug-in window. Every time it does happen, it will continue persistently until I save, quit and restart PT. When I get out from under this mountain of work, I'll try another drive type for a while and see if that helps. For the record PT 8.0.3 is really stable. For PT8 doubters, now is the time to get on board (is Frank Kruse reading this? :) ) Digi Tech Support came back with a request... Can you guys do something for me - after you experience the error, quit Pro Tools as soon as possible after it, then send me your LogFiles folder from inside your Pro Tools folder. Zip it up and send it to: vi [at] digidesign [dot] com. Put the thread number (265212) and '9031' in the subject of the message. "Sunzate" added... I'm getting these errors right now with a midi-only session, controlling the PLAY EastWest orchestral plug-in. Never seen it before today. Recently updated to 8.0.3. Let me know how I can help. Then "Oroz" asked... I'm getting the DAE error -9031 a lot! Can you further explain what do you mean by illegal characters in the drive? How can I solve it? Digi Tech Support replied... Your Pro Tools Reference Guide has a list of unsupported characters. You should make sure that no drive, folder or file name contains any of those characters. This error on Mac is also caused by incorrect drive format. I would recommend backing up your audio/video drives and erasing them using the Disk Utility, then copy the data back and test again. Oroz asked... Do you think that it may be because I'm recording to a partition (dedicated to audio) of the internal drive? If so, would a USB external drive be a solution? Since I'm on an iMac there's only one Firewire 800 port. I have read successful stories from guys using USB drive as an alternative but I'm not sure. Digi Tech Support replied... Recording to a partition or to a USB drive is not recommended or supported and definitely could be a cause for these errors. Please see the General Troubleshooting thread for more details. With an iMac that has only one FW800 port, get a FW800 to FW400 cable to connect to your drives and interface. smpkeys posted... Just happened to me again on Saturday. This time when it happened, I was changing the output of a channel. Digi, I've zipped and sent my log file using the directions posted earlier.  One more thing - I had trashed prefs about 2 hrs before this crash. So a couple of lessons from this thread. You cannot use USB drives for Pro Tools sessions. USB needs processor time to negotiate the data transfer on and off them and does it when it gets round to it. Where as Firewire has dedicated chips on the interface to manage the data transfer in a timely manner. You must have correctly formatted drives irrespective of what platform you are running on. On the Mac platform that must be Mac OS Extended with journalling. I recommend you format your drives with Disk utility rather than any 3rd party formatting software. Check the characters that are used for naming anything. Drives, folder, file names.

following on from my posts on the Canopus bug here and here I referred to another thread on the Digidesign User Conference about jerky video playback. Well a guy (bedubya) has posted here a very comprehensive report on tests he has undertaken in his facility so here it is... I work at a large studio and I have done extensive testing on this problem being that we are seeing it consistently.  I have used a G5 with PT7.4 as a dedicated pic playback device without issue for many years. We decided to turnover one of our stages completely to PT8 using Satellite to latch everything up, but when we went to play picture (wild, no Satellite) after freshly installing 10.5.8 (subsequently 10.6.2), all flavors of PT 8.0cs3-8.0.3cs1, we noticed the stuttering video cadence. We reverted back to 10.4/7.4cs10 and playback was smooth playing wild as well as latched up to timecode.  I decided to up the ante and installed a brand new Quad core 2.66 Mac Pro with PT8.0.1cs1 (subsequently 8.0.3cs1) on Snow Leopard (shouldn't work, but it does) and video playback was consistently stammering.  After reading all of the various threads on this user conference, I started trying everyone's suggestions. The only thing that proved helpful was the Quartz Debug app. This helped explain everything... Leopard defaults the "beam synchronization" to automatic which would explain why when testing we could run the video a few times with no issue and then it would look really awkward for the next few playbacks.  Forcing the beam sync on causes an exaggerated playback stutter and disabling it altogether let the video payback without stutter BUT(!) it causes a tear horizontally across the frame at fast pan or travelling motion through the frame. It definitely is night and day performance from enabled to disabled beam syncronization, but the tear is not acceptable either. I used four distinctly different CPU's (older to brand new out of the box)... a PCI-x G5 w/ATI video card, a PCI-e G5 w/NVidia video card, an older Mac Pro Quad w/ATI video card, and a brand new Mac Pro Quad w/NVidia card.  The PCI-x CPU works with 10.4/PT7.4 very smooth playback, but same hardware with 10.5/PT8.0-8.0.3cs1 stutters.  We use DVCProHD 1080 that we generate ourselves from Avid DNx source files for most of our stage playback with some DV for standard def.  Same hardware and video files that work in 10.4/PT7.4 do not work when that system is running 10.5 or 10.6 and PT8.  I have spent an entire week going through all of the motions and confirming and reconfirming the symptoms. I can tell you that there is something wrong with how graphics in Leopard works.  It's very real.  the best way to test this is to look at film company logos, ie, Universal, Fox, WB logos.  Travelling panning shots look horrific.  And I've tried it all... lower resolutions, hiding the ProTools windows, hanging the video window over the edge of the main screen, using actual size instead of filling the screen with video window, creating boot drives of various combos of Mac OS and PT, video cards, video window on main screen, various codecs (older and newer versions), Intensity Pro card... everything everyone here has suggested.  Quartz Debug almost nails it if not for the tear. I have a test bed set up at my desk and I have resources if anyone has any suggestions (good ones) to try.  This is critical to our business and needs a quick resolution as our clients would like to see the video they provide play properly on a 30' wide screen when the director and producers show up.  Hopefully the alarm bells are ringing there at Digi because they are ringing here on the lot.

There have been a number of posts added to the thread here on the DUC since I last posted here about it. Here are two more work rounds suggestions. First one is from SOUTHmsd... I had clients make a surprise pop in yesterday since editorial is right down the street. I generally work (when i'm by myself) with a qt file in the session on one of the host screens. I updated from 8.x.x to 8.0.3 last thursday. With 30 minute's notice, I started prepping the sessions for playback on the big screen. That's when I discovered the issue. My fix for this mega-annoying bug was, before switching between sessions remove the dv file from the regions list. Then import again on the fly when reopening. It looked a lot better than jumping behind the desk and yanking cables out and putting them back. and the second from JimLeb... My Canopus runs off of AC (not the Firewire for it's power). I set up an X-10 remote control and an appliance module to turn the box off every time I launched a session. I'm happy being back on 8.0.1cs1. Outside of having to unmount drives within ProTools, I don't feel like I'm hurting for 8.0.3. It seems as though my advice from my first post is that anybody using video and Pro Tools should stay on 8.0.1 until this has been fixed.

This is a scary bug that somehow has slipped through the beta testing process. If you want to read all the posts then click here, but here is a synopsis of the issues and suggested work rounds... nhaudio outlined the basic problem... Just updated ProTools to 8.0.3 on two systems and have found a major problem: If I save and close a session that has a video file in it (.dv which is going out firewire to a Canopus ADVC110), when we try to reopen the session, ProTools 'Unexpectedly Quits' when trying to rebuild windows (the last few status updates you get when a session is opening). Sessions with no video file open fine, no problem whatsoever. We can't work like this! We open various tv commercial sessions all day, and rebooting each time is brutal!!! Digidesign pitched in very quickly and asked for crash log file details... In Pro Tools 8.0.3, we added better and more robust logging to help track down problems like the one you are seeing. When Pro Tools crashes, some information about the crash is written out to a log file. The log files are kept in the "LogFiles" folder that is next to the Pro Tools application. Here's what you need to do... 1) Reproduce the crash you are seeing. 2) Look in the LogFiles folder and find the latest log file. The file name ends with .dlog 3) Email this "dlog" file There is no need to do it now as the list of posts confirming the problem grew very quickly and Digidesign quickly confirmed they could reproduce the problem... We can now reproduce this bug in our test lab. We're still investigating what is going with this bug and are trying to narrow down the root cause of the issue. It looks like there is some combination of changes that were made in Pro Tools 8.0.3 and updates to the Apple QuickTime software that introduced this issue. I'm glad to see there are several workarounds for this problem, albeit not particularly nice ones. Bob Brown Principal Software Engineer Also two workarounds came through from users. The first came from nhaudio… I've found a workaround for now. It seems if the Canopus is powered off when I launch a session, it opens fine. Then I can turn the Canopus back on and work as normal. So for now, I plan to turn it off before opening any session to keep workflow... well... flowing. And the second from stustan… I also have the exact problem but I have a different work around that is 100% effective. Instead of bothering with the Canopus Box which is out of easy reach, I rename the pix folder by adding an X to its name. PT 8.0.3 LE then opens perfectly with the relink window informing me it cannot find pix. I then relink to the renamed folder and all is well. The next time I need to boot the session I rename the folder again, usually back to the original name and go through the above steps. My pix folder's name then flip flops between Pix Folder and XPix Folder Then diamondscwin chipped in to say… at the moment it seems to me that Quicktime playback and 8.0.3 is broken... people in this thread are reporting issues with Blackmagic cards, AVID Mojos, Canopus boxes and just desktop playback... only cure regardless of OS is rolling back to 8.0.1 so I dont think its apples fault. Then uno1234 was one of several that suggested… We are reverting all our 4 systems back to 8.01. As nasty as that 8.01 bug list is, we just can't deal with firewire out crashing anymore. How exactly does an official software release get so bungled up like this? Was there no beta testing in a simple post production workflow? Is there ANY accountability at Digidesign anymore? Also to note that the 8.0.3cas1 update hasn’t fixed this problem so it would seem that for video post facilities using video peripherals should say on Pro Tools v8.0.1 for now.

I have just received an email from Will Holiday... Hi Mike, I read your pro tools blog a lot, it's one of the best. I noticed a bug in pro tools 8. When in the fade dialog, and the fades are unlinked, the waveforms are drawn incorrectly when you start moving the fades lines around. (Pic attached). I can't find anything on the web about this. I wanted to see if you or anyone else knows about it, and if there was some kind of solution. Thanks, and keep up the awesome posts. and here is his picture... Thanks Will for this. So I did some checking both on line and on my own system and sure enough on my HD rig I found this... I also did a search on line both in the DUC and the Anwersbase and only found two references, one from Will flagging it up on the DUC here and also another user mrsticks also flagging it up... The fades dialog box allows control and manipulation of crossfades. In PT 8 the views of waveforms do not correspond to the movement of the fade lines when unlatched. (This is a feature I use often.) The "B" side of the fade actually decreases visually while you try to increase it. The audio is not affected but it makes creating the fade more difficult because the visual is incorrect. It will be interesting to see what develops...

There has been a thread on the DUC about jerky video problems in Pro Tools 8. I have covered this issue here and here. Well buried in the v8.0.3 notes is that 8.0.3 fixes  these problems and confirmed in the DUC thread by this post from Digidesign Tech Support...The 8.0.3 update has fixes for the Quicktime issues in this thread...!  Let me know what you find please...

This is a known issue in Pro Tools HD & LE 7.4.2 & 8 (Mac OS X PPC).Workaround: Format the drive with Apple Partition Map partition scheme.This little problem slipped in with the introduction of Intel Macs and Mac OS 10.4.6 when GUID Partition Table support was introduced. The default mode when formatting drives now on Intel Macs is GUID Partition Table. If you put this drive onto a Power PC Mac like a G4 or G5 then you are likely to get 9131 errors in Pro Tools.You can check if your drive is partitioned with a GUID Partition Table using Disk Utility.If you select the higher level icon in the drive list in Disk Utility, in the bottom section it will show what partition map has been used.Any drive formatted on an Intel Mac will use a GUID Partition Table. You will need to use the Options menu in the Partition tab to force Disk Utility to select Apple Partition Map.Alternatively just format the drive on a Power PC Mac and it will be formatted with an Apple Partition Map.If you have an incorrectly formatted drive you will need to move all the material off it to reformat it with the correct partition map.It is in the Pro Tools documentation but it has caught me out!