Hi GC,
I threw 12Ghz out as a number. It doesn't mean anything in real world terms. I just picked a number and ran with it. I was referring to more processing power and, as you mentioned, dual-core systems address part of the concerns. But even with higher processing speeds we'd still be facing the small memory footprint that's available with today's PCs. Streaming from disk is inefficient and cannot solve the aforementioned program change issues(more on that later).
Receptor is a fine, but it's no more useful than another computer. Basically, I have the equivalent of Receptor now. I run one PC, 3GHZ P4, 2 Gbytes RAM for my Synthogy Ivory and the other soft synths. Actually, come to think of it, I have more RAM now than what a maxed out Receptor allows(from what I've read it only goes up to 1GB). So Receptor isn't the answer for me. Heck, if I am going to pay $1600 for Receptor I might as well buy three P4s on Ebay and stack them up and network them via ethernet or MIDI. Then I would be able to run TONS of plug-in synths! No brainer there.
Please note that I am not saying that solutions cannot be found for the shortcoming of SW synths. If money is not an issue, then throwing it at a problem will find you a solution. You can build a cabinet and put half dozen 3GHZ PCs, maxed out on RAM, each one capable of running ten or twelve instances of SW synths and you'll be set to go! However, I don't have the kind of money for such a massive project. Doing something like that would negate one of the premises of SW which is to eliminate or reduce the need for more HW. Having to buy more PCs or constantly having to upgrade them in order to accomodate new SW synths kinda makes the whole excercise a moot point. Instead of stacking up HW synth racks, I'm stacking PCs! LOL!
The final solution that will put HW synths on EBay, at least for me, will be when RAM is so cheap that we can have dozens of Gigs that will allow instances of multiple SW synths to sit in memory, whereby processors can swap out samples at higher speeds. Of course, the proper OS would have to be designed/revamped to allow for such incredibly high memory addressing and management. But that isn't going to happen any time soon.
As for Korg to start dropping hardware in favor of SW synths is questionable. The company released the OASYS, and frankly, it's THE MOST powerful synthesizer to date. Korg is banking that this platform will be a step toward a modular system that will trickle down to more affordable units(maybe an OASYS rack module?) This monster runs on Linux and that in itself is a HUGE move in the right direction. I'm guessing that within the next two or three years we'll begin to see HW synths with several Gigs of memory(the OASYS has as a standard 500+MB of sampling RAM and more for the program area). Basically, Korg is addressing some of my concerns. It's just not affordable yet.
Hi John,
When I mention program/bank changes I am speaking specifically about making these changes to the soft synths WHILE the sequencer is running. In other words, let's say that I have this song/sequence running in Sonar and I need to change the program that is running on MIDI channel 5, which is assigned to my first instance of Dimension Pro. I want to change from a splash cymbal to a crash. How would I do that? Currently, there is no way to automate that through Sonar. I cannot send a MIDI program-bank change to DPro to tell it to change programs WHILE Sonar is running.
In contrast, if I had MIDI channel 6 assigned to my Korg Triton and it was running a synth patch and in the middle of the song/sequence I wanted to change it to an organ patch, I'd simply insert a program change via Sonar on that MIDI channel. I'd assign the bank and patch in Sonar that corresponds to my Triton patch and whala! The program would change mid song. I can do this toggling of patches an infinite amount of time and each time there would be NO glitch on Sonar and none on the Triton. Why? Because Sonar is simply sending a MIDI control message which takes next to no CPU cycles to process and the Triton, having ALL patches easily accessible via ROM/RAM, can change the patch in a blink of an eye. The Triton has no hard drive to contend with.
This basic, and may I say old, MIDI principle cannot be sustained with Dimension Pro and other SW synths. Supposedly some can do it by having the user predetermine the patches that will be needed during the project and putting these on a queue. Once running, the sequencer can swap these patches in and out of memory. But, again, we are talking about MORE MEMORY to load MORE PATCHES.
Why can't DPro make program changes on the fly? Because DPro uses huge samples that reside on disk. The ones that are already loaded and used in Sonar are in RAM, but all others are on disk. Hence, any program changes would force a load of the new samples from disk to memory. This, sadly, is one strong short coming of SW synths. It negates the premise of SW doing away with HW. It tells me that I need a LOT of RAM in order to exploit the power of my SW synths. So, am I really doing away with HW?
Of course, you could ask me: "Why would you want to change patches midsong?!" Well, if I recorded directly to audio each time I played a patch, then I wouldn't need to make program changes at all. In essence I'd be working in the audio domain an not with MIDI. But I don't work that way. I ONLY commit to audio when I am fully satisfied with my composition. I may try a dozen bass patches and a dozen synth patches etc for each track before I commit any to audio. Once in audio, I cannot change the timbre. But in the MIDI domain I can take my time and change things MANY times.
This is a good article on DPro that mentions the MIDI program/bank change issue:
http://remixmag.com/synthesizers_and_samplers/remix_cakewalk_dimension_pro/ "...
(Note that because Dimension Pro's programs depend on large samples stored on the hard disk that you designate upon installation, Dimension will not respond to MIDI Program/Bank change commands.)
..."
Of course, if you don't care about MIDI program change then all of this talk is superfluous!