planet Z

>>>In the manual it states that the recommended system
>>>have at least 128 mb mem and a 8 meg AGP card. Why do
>>>you need so much memory if everything is run from the card?

Let me try to answer this question as it appears quite frequently... It'll be a complex answer, as it's a complex topic. I can't go into smallest details here but I try to get you the picture.

First of all - Pulsar is not only a hardware card but also brings a lot of software with it that enables you to configure and operate the Pulsar environment. We recommend 128MB because we assume the average Pulsar user will use Pulsar in conjuction with an audio sequencer like VST, Logic or Cakewalk. Everyone who extensively worked with (for example) VST before knows that 64MB is already the minimum to run VST (with all its audio and effects buffers etc.). Now - as also Pulsar requires memory for itself, 64MB will not work out anymore if you run Pulsar alongside VST (or other MIDI/Audio software). The logical result will be that your PC will get "as slow as an 486" because Windows is burning processor time with swapping memory to hard disk. This is just the same thing as if you try to run VST with Freehand or Coreldraw at the same time on a 64MB machine. The plain fact is - modern software (due to modern structures, compiler overhead and ever growing Windows overhead) requires RAM. There is an evil running gag in our support department - just run the Pulsar with 64MB and it should be o.k. - then start VST and it stalls - so it must be VST that messes up your machine. That's just a joke of course, the fact is that there is no way around providing a computer with more physical RAM - because RAM requirements of different software packages add up if you want to use them at the same time. If the DSP Factory was able to be reconfigured, there would also need to be software with it and it also would require a certain amount of RAM.

Now we approach the topic why Pulsar requires more RAM than other software. This is related to the architecture of the system - which is extremely flexible. In contrast to other DSP-supported cards, the functionality is not predetermined. Not at all. All functionality is contained in the software modules for Pulsar. Those software modules are again modular. "Under the hood" also the mixer has a signal circuit (like the synths etc.) and it is build out of hundereds of smaller modules. This is a fundamental property of the Pulsar/SCOPE architecture - which enables the system to "squeeze" modules onto the DSPs in a flexible way. If - for example - a synth was coded "en bloc", then you could not use the DSP resources efficiently because every voice might eat up one DSP (even if there was "space" remaining in that DSP). The way it is, the system can span one module (like a synth) over several DSPs and make configuration very flexible. Also - going the modular approach makes software development pretty fast. If building a "device" for Pulsar required coding that piece of software the conventional way, we would not have been able to supply you with that much functionality even in the first release and you could not expect so many further "devices" coming ahead as you can. Basically, every owner of the SCOPE system will be able to build "devices" for Pulsar users. So - only due to the highly modular approach, Pulsar functionality will expand the way you can expect it.

This highly modular architecture requires more memory than conventional programming. Why? Because actually each module you drag onto the project screen contains an abstract description of its functionality. Each synth - for example - contains hundereds of modules that again have up to dozens of parameters, where every parameter is an abstract structure. Some people think it's the graphics that eats up the memory, no - it's the structures that Pulsar has to store in order to administer and bring to life the "device" on the DSPs. This adds up - if you use a couple of synths with a couple of effects and the big mixer, you can easily spend many megabytes of memory on that. Just think of how complex those modules are. We made it very easy for users to drag and drop devices onto the project surface, but some people tend to forget how complex and powerful those "devices" are.

Finally, using the sampler (or multiple samplers at one time) with high-quality samples (and several layers of those) also requires RAM. There are people who spend 128MB of RAM just for their AKAI to be able to load the (number and quality of) samples they want to use. Concerning your host RAM, you need to put that on top of your software requirements. That means that 128MB are usually sufficient for operating Pulsar with VST - but it does not represent an endless resource of RAM. If you want many many tracks (-> VST audio buffer memory) with some DirectX Plug-Ins (-> each having its audio buffers), lots of devices in Pulsar (-> Pulsar module management) and many samples (-> Sample player RAM storage) you may find that you need even more memory than 128MB to keep Windows from swapping to hard disk.

Fortunately, RAM is about everything Pulsar needs. Once that is in place, you will find that Pulsar improves your Windows audio environment a lot and that the extra DSP power on the card lets you do more things on the host side.

When we learned that the structures we desired to realize were more RAM consuming than what was usual at the time, we still continued with our concept. And I'm sure we took the right decision - the flexibility of the system and all the wealth of Pulsar software that is in the queue speaks for itself. I'm sure that within a year or two, the RAM requirements for Pulsar will be called "moderate" compared to what other latest software will need. Also, the RAM issue will relax a lot in future - and 128MB or even 256MB will become standard for even the cheap offerings at Office Depot with just a short time. But then, due to the flexibility of the Pulsar/SCOPE architecture, you'll already have plenty of software modules to play with.

We also would have liked to see that software of tomorrow runs great on any machine from yesterday, but due to the explained technical reasons, unfortunately that's not the case. So just make sure your software has RAM to breathe, and everything's fine.

Cheers Frank/CreamWare