PlanetZ forums - scopeusers.com

I have to say I really like the copy options we now have.
Below is an example.

In XP32bit SP3 I had to copy over 1700 dsp. files which was a major PITA.
I always had to say no..no..no..about 1700 times.
Now you can copy/paste, then the option box appears and you check the conflict box,
in the lower left of the window, then press don't copy ( which means do not overwrite the new files ) and watch the red progress bar.

Ankyuvarymush,

XITE-1/4LIVE wrote:I have to say I really like the copy options we now have.
Below is an example.

In XP32bit SP3 I had to copy over 1700 dsp. files which was a major PITA.
I always had to say no..no..no..about 1700 times.
Now you can copy/paste, then the option box appears and you check the conflict box,
in the lower left of the window, then press don't copy ( which means do not overwrite the new files ) and watch the red progress bar.

Ankyuvarymush,

Untitled.JPG

Hmm... i have XP SP3 and when i do that i just have to confirm once and that is all...It worked same in SP2 and SP1. I also have Win7 and i agree new option is nice but it does same thing as in XP.

I always had an issue where new dsp. files were getting overwritten by older ones.
But perhaps there was a better way to copy over older files to new ones I was unaware of.
If that's the case, I am happy that Windows 7 shows this feature without having to dig too much.

I believe you're talking about the "no to all" option missing in XP32 dialog box??

probably a few years to late with this great tip:

hold SHIFT when pressing NO responds as "NO to ALL" !!

I use Beyond Compare to be able to see time-stamp and other data rather than just relying on what Windows 7 shows me.

Meanwhile I have the latest 64-bit beta running in a separate folder/install, with it's own default start at bootup and everything is running great.
VDAT and STS samplers don't work yet. I'm not using VSTim, so I haven't tested XTC mode (in Samplitude). But otherwise things are working well.

Greg

In XP, I usually take the backward approach: I move the 'destination' apart, put the old ones in place, then overwite all with the new 'destination'. Single-click to confirm overwriting all old ones with the new versions.

That works for .dsp files, but I still need to wade through the other stuff, like modules, since I cannot resist putting them in my custom subtree...

In 5.1 XITE-1 beta are any of the devices ADSP-21369 optimised ? Or is it just to get Scope onto windoze64 ?

So this is ONLY a win64 scope version, right? I cant run it ón an xp machine?
Thanks

If it's XP 64 you can.

dante wrote:In 5.1 XITE-1 beta are any of the devices ADSP-21369 optimised ? Or is it just to get Scope onto windoze64 ?

The native devices were DSP optimized a while ago in the pre 5.1 betas.

This latest 64-bit driver release has those optimizations.

Greg

siriusbliss wrote: The native devices were DSP optimized a while ago in the pre 5.1 betas.
Greg

Ok thanks. But (per Warp69's comments), theres still a couple of areas of XITE-1 optimisation for S|C to work on isn't there ?

1) XITE-1 devices taking advantage of onboard RAM (not sure if this means onboard the DSP chips themselves or on the XITE-1 board itself ?).

2) Automatic distribution of devices across multiple DSP's. Albeit most stock devices would run on a single DSP when fully optimised and maybe only some of the bigger 3rd party devices may be affected by this (?)

My understanding is the RAM is inside the new DSP chips (12 Chips)
Certianly I think there quite a bit of optimisation to go - probably in the third party area, but I get the odd DSP error from time to time on some of Sonic Core's devices. Manual DSP placement usually does the trick

Ok thanks mausmuso, thats what I thought - more opto to go - great pic I've never seen inside of XITE-1 before.

The picture came from a Germany magazine article I believe.
If you search the Z its posted here somewhere.
It might be a good picture to add to SCOPERISE as some point, although I don't know about copyright associated with using it?

mausmuso wrote:My understanding is the RAM is inside the new DSP chips (12 Chips)
Certianly I think there quite a bit of optimisation to go - probably in the third party area, but I get the odd DSP error from time to time on some of Sonic Core's devices. Manual DSP placement usually does the trick

Recent email from Ralf mentions that all Scope native devices should have been optimized. I think only the 1632 mixer was not yet fully optimized, but that was several releases ago.

On Xite, the 3rd party devices mostly do OK until you start jamming in a ton of devices, and then the DSP-to-DSP error messages start happening (although you can still get the devices to load and work). Optimization of these will come after SC finishes 64-bit, and SDK stuff when the other developers can work on optimizing their devices.

Greg

mausmuso wrote:My understanding is the RAM is inside the new DSP chips (12 Chips)

Can't recall for sure, but my PCB experience (and if I recall earlier discussions correctly) makes me think that the RAM chips for the new DSP are on the bottom-side of the board.
I don't see the purpose in building RAM into DSP topology.

Greg

[quote="siriusbliss]Can't recall for sure, but my PCB experience (and if I recall earlier discussions correctly) makes me think that the RAM chips for the new DSP are on the bottom-side of the board.
I don't see the purpose in building RAM into DSP topology.

Greg[/quote]
Interesting, I seem to remember asking the RAM question sometime back and the answer was the RAM is built into the DSP chips. I guess it does'nt matter as long as it is there and it leads to better devices.

both is true - the DSPs have a certain amount of processing memory (on chip, like a CPU cache) and there's additional DRAM on the circuit board for 'extended' use.
On the former 21065 DSPs on-chip memory was really tight which lead to the situation that longer delays quickly ran out of juice and accessed the PC mobo's Ram. The infamous PCI bus load...
I don't have the figures at hand, but the new DSPs probably have enough local memory to handle every existing reverb plugin internally.
If more Ram is needed (for whatever purpose) it doesn't have to be requested from the host OS (and hardware) anymore - a big step imo.

cheers, Tom

astroman wrote:I don't have the figures at hand, but the new DSPs probably have enough local memory to handle every existing reverb plugin internally. cheers, Tom

Thats what I was wondering about - if reverbs happened completely inside the SHARCS. Guess the answer is Yes. The other reason for the question - just reaffirming that the platform hasnt yet reached its full potential - theres still juice left in the development tank performance wise. Coz thats the view I'm gonna push in ScopeRise.

mausmuso wrote:The picture came from a Germany magazine article I believe. If you search the Z its posted here somewhere. It might be a good picture to add to SCOPERISE as some point, although I don't know about copyright associated with using it?

You read my mind mausmuso - of course ! If its a copyright infringement though then we've already infringed

astroman wrote:The infamous PCI bus load...
I don't have the figures at hand, but the new DSPs probably have enough local memory to handle every existing reverb plugin internally.
If more Ram is needed (for whatever purpose) it doesn't have to be requested from the host OS (and hardware) anymore - a big step imo.

defo, particularly for "infamous" and "big step" words. Let's wait for da new sdk and the community be the judge. Not any big risks in saying it's already better than ever