PlanetZ forums - scopeusers.com

Is the routing software WIN code ?

The part that decides what parts of devices will get put to which DSP's (and the SAT connections between them), as you add them to the GUI.

Maybe that might be a bit snappier if 64 bit. I wouldnt be suprised if that was part of the redev effort expecially for XITE, albeit I would imagine it may not be as much of a bottleneck as actually loading the DSP's down the PCIe bus.

I always thought of the 'router' a bit like the old travelling salesman problem in programming (recursive) - except you might have a lot of salesmen trying to use the same highway simultaeously so a lot more complex, and a lot of 'recursing' as they swear at each other.

PaulSh wrote:

ARCADIOS wrote:ram

So, which part of the Scope system do you think needs multiple gigabytes of RAM? Certainly not the DSP code, you'll run out of DSP resources or PCI bandwidth long before you run out of code memory. DSP code isn't bloatware like current x86/x64 code, it's very small and tight - even the largest Scope devices are typically barely more than a megabyte. With the single exception of the Scope STS samplers, Scope should run quite happily in under 100MB. If you're an extensive user of the samplers then I might agree with you about the need to be able to use more RAM, but otherwise, no.

outside scope... i work a lot with synthogy ivory withen the sequenser. also ivoryII is out and i expect it to be big enough. many times i have been using 2 instances of it.

scope works in combination with other staf.

Amongst all the fiddling trying to get my crackling issue to stop, I noticed my cpu clock ratio was set to 27 instead of 26...

I put it back on 26, and disabled enhanced C-states in my bios, and viola! ULLI on lowest setting performs beautifully with ASIO!

So, if anyone else experiences crackling problems, you might want to consider making sure your cpu / pci clock is running at the right speed.

johnnycage wrote:Amongst all the fiddling trying to get my crackling issue to stop, I noticed my cpu clock ratio was set to 27 instead of 26...

I put it back on 26, and disabled enhanced C-states in my bios, and viola! ULLI on lowest setting performs beautifully with ASIO!

So, if anyone else experiences crackling problems, you might want to consider making sure your cpu / pci clock is running at the right speed.

Wow, I seem to remember this being an issue going way back years now.
Crazy PCI...

Glad you got it sorted out.

G

Can someone pls check if Direct Monitoring in ASIO2 drivers is working in Cubase or Reaper.
thx

siriusbliss wrote:

johnnycage wrote:Amongst all the fiddling trying to get my crackling issue to stop, I noticed my cpu clock ratio was set to 27 instead of 26...

I put it back on 26, and disabled enhanced C-states in my bios, and viola! ULLI on lowest setting performs beautifully with ASIO!

So, if anyone else experiences crackling problems, you might want to consider making sure your cpu / pci clock is running at the right speed.

Wow, I seem to remember this being an issue going way back years now.
Crazy PCI...

Glad you got it sorted out.

G

how do icheck this?

You have to read the manualof your particular motherboard.
THe BIOS is what you need to read.
Each mobo is different but the BIOS is either AMI or Phoenix based.

ARCADIOS wrote:scope works in combination with other staf.

The Scope system can work together perfectly with 64-bit software in a 64-bit environment even if it's not all 64-bit. If you have a 64-bit host for Synthogy Ivory, you can run the 64-bit version. I use the VSL Bosendorfer Imperial with Vienna Instruments Pro-64 running under Sonar 8.5-64, all talking perfectly happily to Scope 5.1 and not limited in any way by the Scope UI being 32-bit.

If you're still not convinced then bear with me while I go into a little more detail. Scope consists of 3 main parts (and please correct me if I'm wrong here, anyone):

- The actual Scope system itself that does the audio processing. This runs on the DSPs, which for the PCI version have a 26-bit address space of 32-bit words (effectively equivalent to a 28-bit address space if you think of it in terms of bytes). Each DSP chip has 68KB of RAM on board, plus each PCI card contains various amounts of RAM. The cards can also use the PC's RAM, but as I said before, DSP programs are typically relatively small by modern PC standards. It's meaningless to talk about 64-bit or 32-bit versions of this because it's NOT running on the PC's processor(s).

- The Scope UI that you interact with to manage the Scope system - loading/unloading DSP programs and defining the signal paths. With the single exception of Scope's own STS samplers (because the UI would have to manage the sample memory), it's irrelevant to talk about 64-bit or 32-bit versions of this as long as it's capable of running under a 64-bit architecture, which it clearly is.

- The Scope drivers. These interface the DSP cards to the PC's memory and to other pieces of software. They have to be 64-bits to work fully within a 64-bit architecture, and they are.

ARCADIOS wrote:how do icheck this?

Well, unless you changed the settings, ie: overclocked your cpu/ram, then those should be stable on your pc, and I wouldn't worry about it if everything is working fine for you.

If you want to check, many recent motherboards' bios have an "advanced" section (sometimes under CPU or Processor section) that allow you to modify your PCI clock and clock multiplier ratios. Basically your stock ratio for your CPU should be: <whatever number for multiplier ratio> x 133 (which is my pci clock speed) = <closest to your cpu speed>.

In my case, my cpu is made to run at 3.33GHz, so the closest whole number (*without under-clocking*) to 3.33GHz / 133 = ~26.

Lots of (most?) CPUs come with locked ratios anyway, and you can't change them. Mine was unlocked cause I have the xtreme.

If nothing is wrong with your rig, you should NOT mess with those numbers. Setting them improperly can cause *permanent* damage, and/or make your system not be able to boot up at all!

DrhiQ wrote:Can someone pls check if Direct Monitoring in ASIO2 drivers is working in Cubase or Reaper.
thx

Yes, they work fine for me in Cubase 5.1 with direct monitoring on. Asio2 modules (Flt-Source 64) + (Asio 2 Dest).

johnnycage wrote:

ARCADIOS wrote:how do icheck this?

Well, unless you changed the settings, ie: overclocked your cpu/ram, then those should be stable on your pc, and I wouldn't worry about it if everything is working fine for you.

If you want to check, many recent motherboards' bios have an "advanced" section (sometimes under CPU or Processor section) that allow you to modify your PCI clock and clock multiplier ratios. Basically your stock ratio for your CPU should be: <whatever number for multiplier ratio> x 133 (which is my pci clock speed) = <closest to your cpu speed>.

In my case, my cpu is made to run at 3.33GHz, so the closest whole number (*without under-clocking*) to 3.33GHz / 133 = ~26.

Lots of (most?) CPUs come with locked ratios anyway, and you can't change them. Mine was unlocked cause I have the xtreme.

If nothing is wrong with your rig, you should NOT mess with those numbers. Setting them improperly can cause *permanent* damage, and/or make your system not be able to boot up at all!

DrhiQ wrote:Can someone pls check if Direct Monitoring in ASIO2 drivers is working in Cubase or Reaper.
thx

Yes, they work fine for me in Cubase 5.1 with direct monitoring on. Asio2 modules (Flt-Source 64) + (Asio 2 Dest).

IF YOU CAN TRANSFER THIS CONVERSATION TO TECH TALK THAT WOULD BE FINE... i couldnt find the way, unless creating new subject.
anyway


i overclock my system by having max fsb possible which in my case is 1600mhz.
i set the cpu x8 and the memory speed is 400 achieving the 1:1.
the cpu can be set to x9 but gives me too high clockspeed 3.6ghz. so i lower it to x8 and get the max of 3.2ghz.
this way i have the max fsb in the system.
gigabytedq6x48 that i have has bios settings all other set to auto in order to make adjustements.
in fact i do not know if its running 100% ok. lower (settings ully) i get are not the lowest other people here say that can achieve.

I'm not sure if sleep mode is supposed to work or not with a Pulsar 2. I couldn't even put my PC into sleep mode until I moved to Windows 7, and after that I waited until the 5.1 beta was available before installing the Scope software. Now, waking up from sleep triggers a slew of Scope errors including the "don't mess with copy protection" message.

So, the question is whether or not Scope 5.0 supported sleep on a Pulsar 2 under Win7-32. If it did, then it doesn't seem to support it with 5.1 under Win7-64 and I'll file a bug report. If it didn't, which I suppose wouldn't be unreasonable for a card whose basic design is over 10 years old, then I'll just disable sleep and be no worse off than I was before.

music production studios have no need for sleep....


that'd be no to your pc sleeping.

I'm not a great one for sleeping myself, but I do like to run umm let's just call them "batch jobs" overnight, and it would be good if I could save the planet a little if they finish before I wake up.

Like I said, it's not an issue if it's not supposed to be able to sleep, I just wanted to know if it was able to under Scope 5.

We'll sleep when we die

putting the computer to sleep won't do anything for the planet. just shut it off if you want to save power. the dsps can't sleep.

sleep mode isn't working at the moment.
As for asio and CPU load, there is another update in preparation with more optimized asio drivers and hopefully working samplers, too.

Thanks Julian for the S|C insight

btw, what's up with Gizzmo? You're the man behind, aren't you?

Cheers,
Roman

astroman wrote:the extended adressing has not a single advantage for what the SFP system does.

That may be true, but what about x64 compatibility when using a x64 host? Think about the 32-bit VST problems when using a 64-bit host. Or would that be an driver?

VeryPSB wrote:

astroman wrote:the extended adressing has not a single advantage for what the SFP system does.

That may be true, but what about x64 compatibility when using a x64 host? Think about the 32-bit VST problems when using a 64-bit host. Or would that be an driver?

that really only requires the x64 driver.

Greg

siriusbliss wrote:

VeryPSB wrote:

astroman wrote:the extended adressing has not a single advantage for what the SFP system does.

That may be true, but what about x64 compatibility when using a x64 host? Think about the 32-bit VST problems when using a 64-bit host. Or would that be an driver?

that really only requires the x64 driver.

Greg

I think VeryPSB is talking about XTC Mode wich i assume SCOPE plugins will still need a bridge to work in 64bit host just as 32bit Native plugins need one. To my knowledge this is the Nature of dsp-card plugins and a bridge is required for all dsp Platform plugins running as VST's in 64bit Hosts (e.g. UAD, Powercore, etc all need bridges, and Protools HD Sequencer cannot take advantage of extra Ram). This will probably never change for any dsp platform. If what i say is correct then SFP Mode in 64bit enviroment is definitely your friend.


Edited in: Well Protools HD Host may get around the Ram problem but the Native 64bit VST problem for other dsp Platforms i doubt will ever change, or do so anytime soon. Such is the nature of the dsp card.