petal wrote:It's true that the XITE has ram onboard, but I believe I read some where, that soniccore has not made this ram available yet in scope 5/5.1.
Someone please correct me if I'm wrong.
There´s 32MB RAM on each of the new SHARC DSP chips, but not available yet.
petal wrote:
If I'm right, I really hope that making this ram available for the developers is high on the agenda at SonicCore's meetings.
I´m sure, S|C developers think about to make everything available XITE hardware delivers.
The question is how and for what.
The devices in SCOPE are different.
I´m not a expert DSP coder,- but IMO, it might be more imaginable making the RAM available for specific devices than in general.
Since we have 32MB RAM in each of the 12 DSP chips, these 32MB RAM of a single chip might be not enough to create reverb algorithms using 80+ tabs like the TC hardware reverb does,- that will probably require more and dynamicly usable RAM,- so the RAM of the SHARC DSP would have to be organized in clusters and across several DSP chips on demand.
That´s eventually not possible w/ the architecture of a single SHARC DSP chip, so set in stone and not a task for S|C developers.
Please correct me too if I´m wrong w/ that.
OTOH, it might be imaginable, devices running on ONE DSP chip alone,- like a STS-4000 sampler p.ex.,- that would be able to use the 32MB RAM of THAT single chip one day and as a result, STS-4000 might behave like the old AKAI S-1000/3000 series hardware sampler then which both had 32MB RAM available only.
Cool for loading AKAI CD-ROMs,- but that´s not what we want from a sampler today and could only be satisfying as a optional gimmik.
But maybe and one day,- we see STS-4000 sampler streaming samples from disk and use the 32MB RAM on a SHARC chip to hold portions of pre-loaded samples ?
Just only a idea because I don´t have any knowledge about access time of the/a DSP to it´s RAM and if that would be fast enough allowing a to that DSP loaded device immidiate realtime access to the data temporary stored in that RAM.
It can also be, that RAM is usable for instructions only.
petal wrote:
I like the XITE, but I really had expected that all those damn error messages we see in scope while loading plugins was history with the XITE. Sadly they are not.
What kind of "all those damn error messages" do you have ?
Up to now, there are bugs in some devices, very few in 32Bit systems, more in 64Bit systems.
With a DSP system like old Creamware PCI cards and XITE, you cannot throw in and out plugins like you do in native VST because of the DSP load and unload processes and re-configuration of DSP load in background which needs some time.
I think it can be optimized in some way but will never be the same than VST.
XITE is a piece of hardware to be pre-configurated by the user for different tasks.
Any different project makes it a different piece of hardware gear and it´s up to the user understanding how XITE DSP system works, what the advantages are and what´s the limits, which obviousely exist.
As a general statement and to prevent an offense,- I´d say "it´s not a idiot proof system" like a VST host is when it comes to loading and removing plugins, changing sample rates and buffer sizes on the fly and such.
That rules for SCOPE 5.1 for the time being, but I expect we´ll see imrovements w/ SCOPE 6 and probably more when ParseQ sees the daylight.
Finally,- I don´t say you´re an idiot w/ my line above,- for me, it was just only the best way to describe what I think about this technology in regards of loading and unloading devices.
B.t.w., sometimes, some of the communication error messages come from connectivity of HDMI cable and PCIe card.
That happened to me 2 or 3 times when I pulled my rackmount machine from the rack for mainenace tasks,- replacing harddrives p.ex..
The HDMI cable has some weight and that has an impact to the card.
Unplugging and plugging HDMI cable has too and sometimes is good to do that twice and take care the PCIe card sits perfect in the slot of the mobo.
Bud
