I’m about to make some big changes in my computer setup, and I’d love your advice…
I currently am running Finale 2006c, Sonar 5 PE, GPO, JABB, GigaStudio 3.14, and EastWest’s Colossus. I have 4mb RAM, and my hard disk is 145 gig. It’s a Dell 8400, in case that matters. I also have a laptop, Dell Inspiron 9300, with 2mb RAM, and a 80gig hard disk. I’d love to be able to run as much or all of my sampling software on my laptop as I can.
I’m about to purchase EWQL Symphonic Choirs, and EWQL Symphony Orch Gold and Gold Pro. In order to fit all these gigs into my setup, I need more hard disk space.
So, the questions – and I’d love your feedback and answers!
1. Should I buy a new internal hard disk drive (say 160gig) and put in my existing desktop?
2. If I do that, then is it prudent for me to keep all the software for these programs on the current drive (C: ), but put all the sampling libraries on the new drive?
3. And if I do that, then can I just move existing sampling libs over to the new drive? Or should I uninstall and reinstall all of them? Also, my intent would be to have ALL of GigaStudio on the new drive, since (while I love the sounds it makes), it’s a been a horrible, buggy piece of software from day one and I’d just as soon have it off the regular C: drive, which holds all the rest of my computer’s junk.
1. Should I buy a Firewire external disk, on which all the sampling libraries could go? That way, I could have the software for all these programs on both desktop and laptop, and just tote the Firewire drive wherever I needed it…. Is this a good idea/possible? I’ve heard this stuff runs well off of a Firewire drive – anybody have any experience with that? And if so, which drive, how big, what would I need, and how do I know my desktop and laptop can run Firewire connections (the laptop is but months old, so I assume it can, but the desktop is a year and a half old… is that important?).
Sorry for the long post…. I really need the help soon!
Re: Need your advice on Firewire/Internal HD drive!
Good questions, here is my take:
I don't see external drives offering the kind of speed you need for streaming samples, (at least the big stuff like EWQL and Symphonic Choirs) so I would stick with internal drives that have direct access to high speed busses. This may be something for you to consider if your motherboard is old. The faster the bus you have the better off you are, motherboards in the past year have significantly increased in their Mhz ratings.
For hard drives I've had the most success with this arrangement:
Disk 1 - Operating system and program files
Disk 2 - Audio and project files (for me this means Cubase, Sibelius, Reason, etc.)
Disk 3 - Samples (GPO libraries, Kontakt libraries, etc.)
Disk 4 - Backups and Misc installation files
Each disk above is a physical disk. I don't use anything slower than 7200 RPMs and I don't use striping or any other RAID technology. (It may not hurt, I just don't use it.)
Hope this helps,
We are the music makers, we are the dreamers of dreams …
24" 2.4 Ghz iMac, OSX 10.4.10, MOTU 828 MKII, 2 Glyph 250 Gig external drives, Logic 9, Finale 2008 GPO, JABB, Strad, Gro, Reason 4, EWQL Storm Drum, Adrenaline, Symphonic Choirs, SO Gold,All Arturia Synths, Many NI Synths, Spectrasonics Synths, KH Strings, VEPro on a Windows 7 4x 2.8 Ghz 12 gig of RAM
Re: Need your advice on Firewire/Internal HD drive!
Given the complexity of the problem I think the post was probably on the short side... certainly my response could fill a book!!!
It is a very fascinating question... and the answer changes as technology moves forward, so don't cast this in concrete!
In order to come up with a scheme for data storage you need to divide the data into classes. In a traditional environment we divide data into three groups:
1) data we don't care about - this would include temp files, swap files, browser caches, etc. Stuff that really is temporary and unimportant once the power switch is pressed a second time.
2) data we care about, but can easily reproduce or recreate without the benefit of backups. This would include the operating system and applications - pretty much anything for which you have the installation image handy. Sample libraries fall into this category, unless you make changes to them! I call this static data.
NOTE: this gets tricky, since there are always patches and updates, and I will comment more on that shortly.
3) data we care about, but we can't easily re-create or reproduce, pictures of the kids, our latest opus... you get the idea! I call this dymanic data.
BUT there is more... as people who are regularly pushing the computer to the edge of the envelope!
There is another distinction, how the data is accessed, and it cuts across categories (2) and (3) above. Over-simplifying a bit, the files are either loaded into memory or streamed off the disk.
Be careful here, some things that we might expect to load into memory don't, and probably vica-versa.
For example, your basic midi file (or word document or whatever) pretty much always loads into memory. The files are very small with respect to physical memory on a modern computer, and the programs no longer mess with splitting and overlays. Programs like Word or Excel are capable of loading parts of really large, really complex documents into memory, but in practice this rarely happens.
A Sonar project file also loads into memory. If you are integrating audio with MIDI there are two other file types to think about. The first is the actual audio files, and these are loaded into memory based on some super secret formula that tries to optimize load times and memory usage. It isn't streaming in the same sense that samples are streamed, but it is getting closer.
There are also picture files, these are the graphical representation of the waveform that appears in the tracks, and while having them around speeds things up, they are temporary.
If all of this sounds like I've had too much coffee, or have too much time on my hands, well, you may be right. Current technology makes some of these distinctions a lot less necessary than they used to be. BUT, thinking about data at this level of detail can have a very real impact on performance, and it makes backups a lot easier.
So, for my studio I have created five categories of data, and arranged my disks accordingly. I use five physical disks on four interfaces.
(1) Temporary data - my swap file and all my temp directories live on this partiton, which is a separate disk, and in fact is one of those gigantic 4GB SCSI disks I used to use for real data (who knew they'd be useful this long?)
(2) Static Data / loads into memory - This includes the operating system, applications, utilities, etc. All of this is installed on the "C" partition on a relatively small disk. The disk is connected to the motherboard primary IDE port. Speed is not essential, and if you have to cut corners to preserve cash or control heat you can skimp on this disk.
One of the more annoying trends, from a data management point of view, is programs that include HUGE amounts of data. Some developers (Garritan and Cakewalk for example) are kind enough to let you install the really large data sets elsewhere. If the developer didn't think to include this capability in their installer it is usually (always in my experience) possible to re-locate it anyway, and you should.
(3) Static Data / streams from disk - This is mostly sample libraries for Giga Studio and Kontakt, although it is possible to stream using the player that ships with GPO and JABB. This is a third physical disk, connected to the on-board Sata port.
(4) Dynamic Data / loads into memory - this includes all the smaller data files that I create or change regularly. Word, email, Sonar, my own sample libraries and sound effects, etc. This is a reasonably small disk connected to the secondary IDE port.
(5) Dynamic Data / streams from disk - this includes the audio files for Sonar projects, sample libraries that I have edited, and the like. This is a whomping big, screaming fast disk connected to the on-board SATA port.
One other distinction to keep in mind - while we don't, as a general rule edit the sample sets that come with a tool like GPO, JABB or Dimension, or even GigaStudo, once upon a time tweaking sample sets was common. If you use a sample library that you like to tweak don't treat it as static.
For example, I still use two hardware samplers, an Ensoniq ASR-10 and an Akai S1000. I've loaded all of their sample libraries onto my static data disk so that I can create custom CDs for the samplers. I've also imported all of them into GigaStudio, but the imports are on a dynamic data disk because I am always tweaking them.
Similarly, I do a lot of sound design. The sound effects libraries will be loaded onto a static data area, but when I create new samples they are saved in a dynamic data area.
One of the things I am experimenting with right now is ignoring the distinction between streaming and loading into memory. The theory, and it is just a theory right now, is that the computer accesses the data at distinct times, and thus if it is loading data into memory it isn't busy streaming, and vica-versa. My initial tests indicate that there is not a lot of conflict, and current hardware is capable of managing the conflicts that exist.
We certainly have come a long way from the days when one really cared about separate platters, separate interfaces, and even where on the disk the data was located. I don't really miss those days!!!
Re: Need your advice on Firewire/Internal HD drive!
Dang, I forgot to talk about internal vs external interfaces.
In the ideal world we could all afford large fibre channel disk arrays and none of this would be an issue! Imagine a TB of redundant disk that operates faster than your computer.
It's out there... but it costs a lot more than your computer too!
For now I stay away from external drives for everything but backups. USB can extract a real penalty in terms of CPU performance. Firewire does not, but there is still quite a wide range of quality in both chipsets and drivers. If you have a good chipset and a good driver it works, but I've had one too many fatal disconnects!
External SATA (eSATA) is finally arriving, and it looks real promising!
There is also iSCSI, which uses ethernet as the transport for SCSI commands. (Trivia - Fibre Channel is SCSI over fibre). I really like iSCSI, but it remains rather expensive. And of course the disks themselves are expensive. UGH!