On Oct 31, 2004, at 1:53 AM, "ivandeaton" <ivandeaton@...> wrote: > My solution for the simple question of solution for playback was to > have > installed an ATTO UL4D Ultra 320 card and a SCSI raid capable of > reading 200+ MB/sec. > Logic 6.3.3 is working pretty flawlessly, and the drives put out all > the tracks I need without > any hickups. It will loop a few bars of 90 tracks all day long. Hi Ivan, Thanks for this report! I think what it shows is very useful. It suggests that while other applications may have more robust disk/cache handling than Logic, it IS possible to get high track counts from Logic, if willing to invest in extra hardware. Ideally, it shouldn't be necessary to invest in extra hardware to use Logic at high track counts if it is not necessary to invest in extra hardware to use Cubase/Nuendo at high track counts, but it is good to know that it is possible. Orren -- http://www.mertonfolio.com Author of: • Logic_6_Power • GarageBand Ignite http://www.courseptr.com/ptr_catalog.cfm?group=Music%20Technology

> > My solution for the simple question of solution for playback was to > > have > > installed an ATTO UL4D Ultra 320 card and a SCSI raid capable of > > reading 200+ MB/sec. > > Logic 6.3.3 is working pretty flawlessly, and the drives put out all > > the tracks I need without > > any hickups. It will loop a few bars of 90 tracks all day long. > > Hi Ivan, > > Thanks for this report! I think what it shows is very useful. It > suggests that while other applications may have more robust disk/cache > handling than Logic, it IS possible to get high track counts from > Logic, if willing to invest in extra hardware. Ideally, it shouldn't > be necessary to invest in extra hardware to use Logic at high track > counts if it is not necessary to invest in extra hardware to use > Cubase/Nuendo at high track counts, but it is good to know that it is > possible. > > Orren Orren and Ivan i've followed this discussion in and out, but i wanted to add that i have done extensive drive testing with logic and have never seen RAID improve performance. i've got a dual G5 and have tried every combination of drives from a RAID made up of 8 15K SCSI drives attached to an ATTO UL4d (4 drives per channel - read and write times around 270 MB/ sec) to a firewire 400 drive. and this is what i've seen: 1. RAID does not improve performance with logic. when using a RAID with logic, i've always gotten the same performance as using a single drive from that RAID. meaning, the 8 drive 15K SCSI RAID performed audio playback at the same level as a single 15K scsi drive. so if ivan is getting 90 looped tracks to playback from his RAID, my guess is he would get that exact same performance from 1 of the drives which make up the RAID. 2. Logic on X can not make use of multiple drives for playing back audio. well, i should say - it can playback audio from multiple drives, but it doesn't improve track count performance to do so. meaning - if you can play back 50 tracks from 1 drive and you add a second drive just like it, you will still only be able to playback 50 tracks (even if you split the tracks evenly across both drives). 3. if you think Logic playback performance is bad at 44.1, try it at 96K - it degrades dramatically at higher sample rates. and i'm not talking about being able to play 1/2 the tracks at 88.2 as 44.1 - i'm talking about being able to play about 30% of the tracks at 88.2 that you can at 44.1. 4. Logic exhibits the same lack of performance improvement when using multiple drives with the EXS for streaming samples - you can stream from multiple drives but it does not improve performance. meaning, i experience dropped data at the same point in songs whether streaming from 1 scsi drive (all instruments on 1 drive) or from 8 (with the instruments spread out across the 8 drives). for more info on some of my testing of various drive set-ups with 96K go here: http://community.sonikmatter.com/forums/index.php?showtopic=‰28&hl= for confirmation of another logic user who initially thought he was seeing improvement from a RAID only to test it and discover her wasn't, go here: http://discussions.info.apple.com/webx?14@46.SoRPaBRjAsO.0@.689d9169 anyway, just wanted to add my experience for anyone considering going the RAID route. in my experience, the best track count performance you can get from logic is with the single fastest drive. at the moment, that remains a 15K scsi drive. i really do hope that apple gets on the ball with this.

> Orren and Ivan > > i've followed this discussion in and out, but i wanted to add that i > have done extensive > drive testing with logic and have never seen RAID improve > performance. i've got a dual G5 > and have tried every combination of drives from a RAID made up of 8 > 15K SCSI drives > attached to an ATTO UL4d (4 drives per channel - read and write times > around 270 MB/ > sec) to a firewire 400 drive. and this is what i've seen: > > 1. RAID does not improve performance with logic. when using a RAID > with logic, i've > always gotten the same performance as using a single drive from that > RAID. meaning, the > 8 drive 15K SCSI RAID performed audio playback at the same level as a > single 15K scsi > drive. so if ivan is getting 90 looped tracks to playback from his > RAID, my guess is he > would get that exact same performance from 1 of the drives which make > up the RAID. > > 2. Logic on X can not make use of multiple drives for playing back > audio. well, i should > say - it can playback audio from multiple drives, but it doesn't > improve track count > performance to do so. meaning - if you can play back 50 tracks from > 1 drive and you add > a second drive just like it, you will still only be able to playback > 50 tracks (even if you split > the tracks evenly across both drives). > > 3. if you think Logic playback performance is bad at 44.1, try it at > 96K - it degrades > dramatically at higher sample rates. and i'm not talking about being > able to play 1/2 the > tracks at 88.2 as 44.1 - i'm talking about being able to play about > 30% of the tracks at > 88.2 that you can at 44.1. > > 4. Logic exhibits the same lack of performance improvement when > using multiple drives > with the EXS for streaming samples - you can stream from multiple > drives but it does not > improve performance. meaning, i experience dropped data at the same > point in songs > whether streaming from 1 scsi drive (all instruments on 1 drive) or > from 8 (with the > instruments spread out across the 8 drives). > Well, You are absolutely WRONG on every point except #3(...yes,96k does impeed performance). I've had years of experience with this, and what I've found is this... 45 tracks on an interanl ATA will playback fine. 90 tracks on the internal ATA will stop the system... ie...core audio error message. I can take half the 90 tracs and put them on the OTHER internal ATA and all 90 playback as easy as the single drive playing 45 tracs. The same 90 on a SCSI array playback even easier with no probs. With slower drives it is quite easy to watch the audio performance meter turning red as well as just listening for problems and watching the computer stop playback trying to crunch data. This not only was the case with the Dual 2 gig, but easily quantifiable on the dual 800 I have when I went from internal drives to an internal 160 SCSI with one 15k Cheetah way back on Logic 4. I've mixed a lot of records on these systems, and drive speed is THE difference between success and utter frustration. By the way, I'm talking about actual full song length 44.1 24 bit wave, or SDII files in the arrange window. The setup is a dual 2 gig G5 with 2 gig of RAM. 2 internal 250 gig serial ATA's, a 72 gig SCSI array thru an ATTO UL4D, an RME digi card playing back thru an Apogee AD 8000. Drive speed is THE difference. Regards, Ivan

--- In logic-users@yahoogroups.com, "ivandeaton" <ivandeaton@y...> wrote: >> > Well, > You are absolutely WRONG on every point except #3(...yes,96k does impeed performance). > I've had years of experience with this, > and what I've found is this... 45 tracks on an interanl ATA will playback fine. 90 tracks on > the internal ATA will stop the system... ie...core audio error message. I can take half the 90 > tracs and put them on the OTHER internal ATA and all 90 playback as easy as the single > drive playing 45 tracs. Ivan with all due respect, you're making my point for me because what you've failed to mention is that a single ATA drive can playback around 90 tracks. i've tested them a bunch and that was always the case - they can handle between 89 and 92 tracks. so that you can playback 90 on 2 ATA drives makes my point exactly - you can use multiple drives, but they don't improve performance (OK, if you are claiming that by using 2 drives you can gain a performance increase of 1 track - i'll concede). now, if you could playback 170-180 tracks with 2 ATA drives, then you'd have some kind of proof about multiple drives. look, i've tested these a lot (along with using them). for more testing i did a long time ago on my dual 1.25 with ATA drives (among others) go here (you will see that ATA drives can handle 89-92 tracks): http://community.sonikmatter.com/emagic/ultimatebb.php?ubb=get_topic;f%; t0262#000000 >>>>> The same 90 on a SCSI array playback even easier with no probs. Well, of course they do - because the SCSI drive is faster. but if you've ever really taken the time to test a RAID vs a single scsi drive then you'd know that a RAID makes no real world difference for logic. you get almost exactly the same performance from a single SCSI drive. again - i'm not the only one who has experienced this. go here: http://discussions.info.apple.com/webx?14@46.SoRPaBRjAsO.0@.689d9169 and check the posts of a guy named Gerald Stringer - he thought RAIDs improved things too, until he actually tested it. seriously - just because you've spent a lot of time on your system doesn't mean you know how it performs. i've spent a lot of time on my system and i've spent a lot of time testing my system. i've done a LOT of testing on all of my systems and i've spent a LOT of time documenting that testing and posting it for the benefit of other logic users (primarily over at sonikmatter and at the VSL forum). and frequently these tests have been confirmed by other logic users. if you'd care to actually run controlled tests, document them, and post the conditions and results - i'd love to read them. i'm sure others would too. but until you do, i think suspicion should be cast on what you're claiming - because i have a great deal of direct experience which contradicts what you say. and let me stress - i DON'T WANT IT TO. i really WANT to be able to use all of these hard drives with logic - they cost a lot to be of no benefit. but as of today, they don't improve performance. so - to recap: 1. RAIDs DON'T improve performance with logic. well, to be clear, i've encountered one other user who was using a hardware RAID card (which a UL4d isn't) who experienced improved performance in OS 9. there is NO situation in which a UL4d will improve track counts with logic. i've tried single channel 8 drive RAID. dual channel 8 drive RAID. single and dual channel 4 drive RAID. single and dual channel 2 drive RAID. tried the RAIDs with UL4d. tried em with UL3d. tried all combinations in the 133 MHz PCI slot of a G5. tried all in a 100 MHz slot in a G5. and, with the exception of the UL4d, i've tried all the combos on a dual 1.25. and NONE of them showed any real world performance gains. 2. multiple hard drives DON'T improve performance with logic (beyond, at best, a couple of tracks). again - i've tried multiple (up to 8) 15K scsi. i've tried a 15K scsi on the UL4d and a 10K scsi on a UL3d (separate PCI busses). i've tried 15K scsi and a fw800. i've tried 15K scsi and an internal 10K SATA. tried internal SATA drives. again - in NO set-up could i improve track count playback performance by more than a couple of tracks. 3. EXS streaming does NOT improve when using multiple hard drives (as measured by the EXS Virtual Memory window - where is shows the 'could not get data in time' figure). 8 15K scsi drives on 2 channels of the UL4d drop data at EXACTLY the same point that 1 15K scsi drive does. again - tried this with all combinations (scsi and firewire, scsi and SATA, etc.) and not one combination ever improved performance. a LOT of people have assumed that using multiple hard drives improves track count and streaming performance simply because you can use multiple hard drives for both things. but i've tried many times to confirm this on many systems and have never been able to. hope this helps

"ivandeaton" > <ivandeaton@y...> wrote: > > Well, You are absolutely WRONG on every point except #3(...yes,96k does > > impeed performance). > > I've had years of experience with this, and what I've found is this... > > 45 tracks on an interanl ATA will playback fine. 90 tracks on > > the internal ATA will stop the system... ie...core audio error > > message. I can take half the 90 > > tracs and put them on the OTHER internal ATA and all 90 playback as > > easy as the single drive playing 45 tracs. Bill I have run this exact test and in my experience it simply does not happen as you are describing. If I reach the ceiling of my system using a single internal SATA drive, and then transfer half the tracks to a different drive, there is absolutely zero improvement in disk performance - many others on this list have also confirmed this. If you are seeing totally different results, then I can only assume you are using a different disk controller or a different system (I am on G5 2x2GHz 5GB Ram). Basically the scenario Stupid8track is describing mirror pretty much exactly what I have seen on our G5. Drive speeds, multiple drives and RAID make absolutely no difference to Disk performance. The only thing I haven't tried is a SCSI RAID configuration, because I wasn't prepared to invest in the additional hardware when nobody (Emagic included) could tell me it would improve performance. Are you running a G5 or G4, and which OS? Maybe Logic yields better results under OS 9 or on G4 hardware (I wouldn't be surprised). Sorry to sound like I'm disagreeing for the sake of it, but I've done a lot of testing on this issue and am concerned when I see results which contradict everything else being found. Personally I'm pretty sure that on G5's (only Mac hardware I have) Logic's poor Disk IO performance is NOT a limit of the disk drives involved. This is further born out by the fact other applications get (in my experience) up to 60% better track counts from the same hardware on the same system. You also get significantly better track counts from older versions of Logic running on older Windows hardware with slower disks. Jules

In regards to Stupid8Track's posts I will make only one last remark, because it is pointless to keep arguing this stuff. I'm not trying to stream samples into an ESX. I'm using files, usually from Protools or other DAW's, that clients bring to me with upwards of 100 24 bit files to be mixed. Files imported to Logic that have to be accessed fast and accurately. If internal ATA's give the same peformance as external SCSI's... everyone would be doing HD video from slow internal drives instead of ultra fast arrays. The analogy to audio is valid. The faster the array, the faster you can work. I've never gotten a single drive to do any more than 60 tracks without serious problems. Using multiple drives, Ultra 160 or 320 SCSI arrays gives WAY WAY more track counts, frees the processor to deal with tons of plug-ins, and enables me to mix without all the problems everyone is complaining about on this very forum. So go ahead and try to do the impossible from your firewire drive, and I'll keep making my living mixing records with 24 to 100 tracks of 44.1 24 bit audio. Except.... my system wont be lagging, coughing and freezing up while I have clients waiting. I do know my system, and that faster drives DO give more track count. I posted this to try to give some helpful hints. If you don't believe me, go ahead and use that 5200 USB drive. Gee...I suppose faster video cards don't give better FPS game performance either. Best wishes, Bill Deaton

On Monday 01 November 2004 19:10, ivandeaton wrote: > If internal ATA's give the same peformance as external SCSI's... everyone > would be doing HD video from slow internal drives instead of ultra fast > arrays. I wasn't watching this thread but it looks like I missed some fun. :) Anyway in case anybody still didn't know: SCSI drives might have comparable speed specifications to fast IDE drives, but IDE puts much more strain on the processor because the controller is less intelligent. Hence, an X mbps SCSI disc will allow for more tracks than an X mbps IDE disc even if X is the same for both drives. SCSI RAID arrays obviously make this performance increase drastically because the datatransfer rate multiplies while the processor load hardly increases. Firewire also reduces processor load compared to IDE but is much slower. This means that you could actually notice an increase of possible tracks when switching from IDE to firewire (depending on how much strain you have on your processor using plugins etc). The RPM count of the used drive doesn't enter into this; the firewire interface itself will usually be the bottleneck. An interface that has to send one bit at a time through a long cable will always be slower than an interface that pushes 32 or even multitudes through a short cable with high quality demands. The communication physics will continue to be improved for all 3 interfaces. Maurits.

On Nov 1, 2004, at 1:48 PM, Maurits van de Kamp wrote: > Firewire also reduces processor load compared to IDE but is much > slower. This > means that you could actually notice an increase of possible tracks > when > switching from IDE to firewire (depending on how much strain you have > on your > processor using plugins etc). The RPM count of the used drive doesn't > enter > into this; the firewire interface itself will usually be the > bottleneck. An > interface that has to send one bit at a time through a long cable will > always > be slower than an interface that pushes 32 or even multitudes through > a short > cable with high quality demands. The communication physics will > continue to > be improved for all 3 interfaces. > > Part of this comment is in error. RPM does make a difference in drive performance, whether the interface is SCSI, ATA, or FireWire. I apologize in advance for the lengthy explanation that follows, with some added explanation that may benefit the overall discussion about track-counts. RPM influences two aspects of drive performance, raw data rate from the platters to the drive electronics, and average rotational latency. A 15K RPM SCSI drive operating at the same areal bit density (a measure of data bits per unit area on the platter) as an ATA/SATA 7200 RPM drive will deliver 100% more bits to the drive electronics in the same amount of time. Furthermore it will take 1/2 as long on average for the heads to be in the right spot to make a read or write (this is the affect of rotational latency). DAW drive performance is affected directly by both performance characteristics. Rotational latency more or less controls how many chunks of audio can be pulled from the drive every second, whether the chunk is small or large (within reason. I am speaking of the difference between a 200 msec edit and a 2 second edit). It fact it is not uncommon for rotational latency to be the overriding factor in track-count performance when the edit densities are high, especially if the edited raw audio tracks are long (in this case 10s of seconds or minutes) to begin with. Proper caching is the only way to mitigate a rotational latency restriction. Data transfer performance seems to get all the attention but that is often misplaced upon the interface instead of the actual raw drive performance. In the ATA world we have yet to have a 7200 RPM drive break the 75MB/sec barrier, so even the "slow" ATA-100 interface that was state-of-the-art 3 years ago is adequate for current drives. SATA drives *do not* improve raw transfer performance, they merely provide more headroom for potential future data transfer speeds. Drives with large built-in caches (i.e. 8-16MB) can at times saturate an ATA or SATA interface but the effect is short lived, and real-world tracking performance is rarely helped by a hard drive's native caching. SCSI drives obtain the well-deserved reputation for high performance from three primary factors, of which the SCSI interface itself is only ancillary. The first performance increase is that SCSI drives operate at high rotational speeds, 2X *most* ATA/SATA drives. This improves rotational latency a factor of two as explained. The second is raw data transfer. The raw drive data transfer rates are often not scaled directly with rotational speed because the tradeoff in drive manufacturing to obtain the faster rotational rate is to use less areal density. Still the faster drives spit out raw data faster. The final advantage is that SCSI drives historically are high-cost/high performance so they are manufacturered with superior track-to-track and average seek times to the more consumer ATA/SATA drives. The difference is not quite 2:1 but it is close. This used to be a much bigger advantage than today when drive densities were smaller and fitting audio files often took greater than 50% of a drive's capacity. Now drives are large enough that with proper partitioning it is reasonable to restrict audio files to a mere 10% of a drive's capacity, which has the dual benefit of decreasing average seek times dramatically, and increasing raw transfer rates by virtue of using the faster, outer-most tracks of the drive. This last aspect can approach 100% on typical drives today, be it ATA or SCSI. SCSI's fast, parallel bus transfer rate *helps* smoothly move the data between the drive and the host but it is only able to affect the performance by not degrading what the drive does on its own. There is some reduction of processor loading over ATA, and there is some potential for having multiple drives working almost in parallel, but beyond that the only reason that SCSI drives are faster than ATA is that they rotate faster, and have less average seek time. FireWire 400 was faster than the fastest 3.5" 7200 RPM drives up until around 18 monts ago at which point the interface itself became the limiting factor. However FireWire 800 is more than fast enough for today's generation ATA drives - the fastest ATA/SATA drive has a *peak* transfer rate of around 65MB/sec, well below FireWire 800's effective transfer capcity of around 80 MB/sec. In a real-world multitrack audio editing task a faster rotating drive will out perform the slower one, regardless of whether it is on a FireWire bus or connected on the internal ATA/SATA bus, unless the multitrack project is the degenerate case of a lot of really long tracks with few edits. Likewise one could also put a higher density (i.e larger capacity with same number of platters) 7200 RPM drive than the stock G5 Dual 160GB drives in an aging PowerMac G4 (say a 733 MHz Digital Audio Model, almost 3 years old), and obtain greater track counts with the G4 than the G5, simply because the drive is spitting bits out faster. How many more tracks is very much a function of the specifics of the project being edited! One last point regarding to the test data being discussed and its apparent contradictory nature. Drive technology advances so that doubling in areal density occurs almost every 12 months. If I test performance with the latest drive I can buy today, and report the findings, they will be no longer valid when compared against the same computer performing the same test six months from now if the computer has the then current drive installed. Next, partitioning can have a *great* affect on the test results. The size of the partition, as a ratio of the total drive capacity, and if the placement is at the outer rim, can tremendously skew the results compared to a situation where the partition is say the entire size of the drive. Also the actual project test data has enormous affect on the outcome, enough that unless the same project is used for all tests the results are suspect. Finally, track-counts are somewhat a misnomer. Its not the number of tracks that are important but the number of simultaneous overlapping audio chunks that can be played, especially simultaneously started. In this regard it is better to think of it as track polyphony and structure your performance tests with that analogy in mind. drK

Hi Bill > If internal ATA's give the same performance as external > SCSI's... everyone would be doing HD video from slow internal > drives instead of ultra fast arrays. The analogy to audio is > valid. The faster the array, the faster you can work. I've > never gotten a single drive to do any more than 60 tracks > without serious problems. Using multiple drives, Ultra 160 or > 320 SCSI arrays gives WAY WAY more track counts, frees the > processor to deal with tons of plug-ins, and enables me to > mix without all the problems everyone is complaining about on > this very forum. So go ahead and try to do the impossible > from your firewire drive, and I'll keep making my living > mixing records with 24 to 100 tracks of 44.1 24 bit audio. Without wanting to speak on Stupid8track's behalf, I think there are some crossed-wires here. Nobody is denying that 'normally' faster drives means better performance. That has always been the case on Mac's and PC's whatever the audio application. The situation we seem to have here, and the reason this is causing so much hoo-hah, is that Logic is not behaving like other applications have always done, even Logic itself on OS9 and PC. Basically, there seems to be a bottleneck within the coding of Logic, which means that no matter what mega-fast drives you have to feed it with audio, it can't process what it receives fast enough and coughs up IO errors. Of course if you're working with a TDM engine, this is not the case, as ProTools handles disk IO (perhaps that's what you're doing). Every application I have ever worked with has been limited primarily by the speed of the disks it relies on for streaming. Logic in it's current form, under OS X and on G5 (I can't speak for G4 users) does not behave this way. It seems to have a finite track-count ceiling which nothing can breach (I can't speak for SCSI as I haven't tested this. Perhaps it's a limitation of OSX, perhaps it's something to do with the G5 SATA controller, perhaps it's just the way Logic is caching audio - I have no idea. But enough people have now confirmed the same findings for it to be a real issue. Perhaps you'd be kind enough to confirm your exact system spec's so that some of us can perhaps try and achieve the type of performance you're getting. Thanks for your input. Jules

Jules Bromley wrote: > The situation we seem to have here, and the reason this is causing so much > hoo-hah, is that Logic is not behaving like other applications have always > done, even Logic itself on OS9 and PC. Basically, there seems to be a > bottleneck within the coding of Logic, which means that no matter what > mega-fast drives you have to feed it with audio, it can't process what it > receives fast enough and coughs up IO errors. Amen. And even while I'm interested to see all the technical explanations here (admittedly I actually don't know much about all this), I can still run 128 tracks in 24bit (mono), with Logics internal CPU meter showing around less than 10% useage on my old 1GHz machine (which I'm not using anymore for music, so it's bloated with netstuff and the likes, not exactly what you'd call an optimized DAW computer), using the onboard Promise UDMA controller and an el Cheapo Maxtor UDMA 100 drive under LAW 5.5.1. FWIW, the Promise controller on this mainboard has allways been known to be a very nice one, but you'd expect the onboard controller on a G5 to be as good, won't you? Still, track performance is pretty much worse. And, as Jules pointed out, all this isn't even all that relevant. The most relevant point being that other applications simply don't suffer from the same symptoms but perform (partially way) better, using exactly the same system. - Sascha

> And, as Jules pointed out, all this isn't even all that relevant. The >most relevant point being that other applications simply don't suffer >from the same symptoms but perform (partially way) better, using >exactly the same system. > > - Sascha I made this very same point back in May, 2004 when I did an intense test with Cubase SX and Logic 6.4.2. http://logicuser.net/phpapps/phpBB2/viewtopic.php?t608&sidc6d72889454f1 7e67495b11519ddf4 Oddly enough, when I originally posted these findings on several different forums, no one seemed all that interested. Now, Logic 7 has hit the marketplace and everyone has discovered that Logic has a poor audio from disk transfer rate. Now, will someone PLEASE tell Apple!!! Just Fix it!!!

So now I'm a bit depressed. First, thanks for all this wisdom, one and all, but does that mean the order I just placed for two G-RAID firewire 800 arrays is, in all the important respects, null and void? I don't want anyone to have to repeat themselves — I get it — and this is a rhetorical question, sorta, but I was really hoping for a MAJOR leap in performance. G5 2 x 2.5 Gb Logic 7 1.5Gb RAM Internal SATA drives External Firewire 400/5400rpm Beer.

--- In logic-users@yahoogroups.com, "ivandeaton" <ivandeaton@y...> wrote: > > > In regards to Stupid8Track's posts I will make only one last remark, because it is pointless > to keep arguing this stuff. I'm not trying to stream samples into an ESX. > If internal ATA's give the same peformance as external SCSI's... everyone would be doing > HD video from slow internal drives instead of ultra fast arrays. The analogy to audio is > valid. The faster the array, the faster you can work. I've never gotten a single drive to do > any more than 60 tracks without serious problems. > > Best wishes, > Bill Deaton Bill just wanted to clarify - i never said that anyone would get the same performance from an internal ATA as from an external scsi drive. others might have, but i didn't. i said: 1. RAID doesn't improve performance with Logic over what you would get with any single drive in the RAID. 2. multiple drives don't improve performance with Logic. to get the best track count playback performance with logic, you need the fastest drive you can get. at the moment, that is 15K scsi. if you are only getting 60 tracks from a single scsi drive, then something is very wrong because i can get 120+ easily with a single 15K scsi drive. most people run into a wall around 100 tracks because logic can't use multiple drives to any positive effect. IMO, there is no inherent limitation to track count in logic beyond its inability to use multiple drives. fix this and the problem is solved. in fact, i've played back 45 stereo 192K tracks by creating RAM disks in my G5. so the power is there. it is now up to apple to improve functionality of the program. hopefully they will do so soon because they really need to to stay competitive. hope this clears things up.

--- In logic-users@yahoogroups.com, "broadlawner" <trevor@o...> wrote: > > > So now I'm a bit depressed. > First, thanks for all this wisdom, one and all, but does that mean the order I just placed for > two G-RAID firewire 800 arrays is, in all the important respects, null and void? > I don't want anyone to have to repeat themselves — I get it — and this is a rhetorical > question, sorta, but I was really hoping for a MAJOR leap in performance. > > G5 2 x 2.5 Gb > Logic 7 > 1.5Gb RAM > Internal SATA drives > External Firewire 400/5400rpm > Beer. well, never having tested them, i can only say - hopefully you'll see a major leap in performance. i'd be surprised if they improve things. i have tested a 10 drive hardwareATA raid (which benchmarked at around 200 MB/sec) and found that it performed at the same level as a regular ATA drive - both for audio playback and EXS streaming. major bummer. personally, i don't believe RAIDs are good candidates for audio anyway - the data is too small. IMO, RAID is much better for video, where larger data 'sets' are being streamed. anyway, i hope that they work. or perhaps you can return them? if you keep them and can be bothered to test them, please post back with the results. best of luck.

> if you keep them and can be bothered to test them, please post back with the results. > > best of luck. Thank you. I will do just that. :-)