PlanetZ forums - scopeusers.com

well, aside from the fact that 7 Profit 5s is kinda crazy(can't you commit anything to a recording?), if you think about it, a Profit 5 takes about two of the old dsps for one voice. that's about 14 of the old dsps. there are many different kinds of communication requiring different and limited resources. the error is not surprising. what it means is that the motherboard/cpu/chipset has no additional lanes of communication between the XITE and the system memory. f*ck! as if seven synths is too few.....if those were hardware, they'd cost you oh....$14,000 minimum, like the cost of 4 XITE-1s....

The thing is that it appeared suddenly.

There was no message and suddenly I can load less intruments than before.
The behaviour changed so that I can assume there is something wrong with
S|C hard/software.

That is the fact!

And still no reply from S|C.

cheers
Harry

and it appears when the load is only 30 % also ...

on what, a new project or a saved project?

async is stuff connected to the motherboard's memory and resources.

garyb wrote: async is stuff connected to the motherboard's memory and resources.

Ahhh, interesting info,- didn´t know this up to now,- thx !

His 7 or 8 Profit 5 example, one voice each is quite interesting as is he´s running into errors @30% load.
I never had this,- but not being in XTC mode.

Even I was unable to load more than ~ 50 - 55% on the XITE-1, I was able to load the STM2448X (mix of stereo and mono channels), M2S, MV Classic, RSPV-1S, Chorus S and Delay LCR S in the auxes, 2 Seq MIDI sources & XITE MIDI source, MIDI Merge 4, MIDI monitor plus 8 synths:

Minimax monophonic
B2003 (full polyphony anyway)
Prodyssey / 5 voice poly
Profit 5 / 5 voice poly
Vectron Player / 8 voice poly
Lightwave v5 / 8 voice poly
UKnow 7 / 8 voice poly
Vocodizer 4-voice poly ... before running into errors.

In addition, there were the Mic/DI source, XITE-1 analog source and phones destination in the project, Wave source module, ADAT A source (8 channels) and destination (4 channels), ASIO-2 float 64 I/Os (4 channels In / 8 Out,- I use the busses of STM2448X to go back to the sequencer)

I had to remove STS 4000 to get that working on recall of that project after it was saved,- but it was also successfull w/ STS-4000 / 32 voice poly, but without Vocodizer in that project then.

Here´s a shot of the project w/ STS-4000 from april this year ...
You see, that´s a lot of connections (MIDI OX running in background too as well as Reason 6.02 and PS1 Pro v2) - and I use STM2448X dynamics and EQ in addition on a few channels, but if you look at the DSP meter, the load is under 50% and there are a lot of zeros in the ASYNC display.

Nonetheless, that was the limit of XITE-1 connected to my machine, even DSPs #13 / 14 / 17 & 18 show a lot of free ressources.
That wasn´t the last project I did, but I don´t have other screenshots up to now.

But now I wonder why his project doesn´t work w/ 7 instances of Profit 5 monophonic and in XTC mode.

Is that all about motherboard and RAM ressources of the machine in use ?

Bud

Could be also the bandwidth of connection from Scope to Host. I can run more STS4000 on PCI than on XITE for example, where my PCI cards communicate with host over 3 x PCI slots (but 1 STDM cable between them). XITE communicates with host on one PCIe connection.

dante wrote:Could be also the bandwidth of connection from Scope to Host. I can run more STS4000 on PCI than on XITE for example, where my PCI cards communicate with host over 3 x PCI slots (but 1 STDM cable between them). XITE communicates with host on one PCIe connection.

Hmm, the STS4000 is possibly not the best example because it´s not optimised for XITE up to now,-that´s how I understood,- and it seems to be right ´cause "32 voices only" and -
"you need to place each of them on DSP 7, 8, 9 or 10. Each on a single DSP".


PCI bus vs PCIe ...

PCI is 133MB/sec peak on the overall bus

PCIe 1.1 is 250MB/sec per lane
PCIe 2.0 doubles the transfer rate

In fact, I don´t see any faster or better communication over PCIe when using more than 1 PCI card in more PCI slots.

What spec is XITE-1 PCIe card,- 1.1 or 2.0 ?
Website and XITE-1 manual (the one I have) offers no info.

What´s up w/ the 32MB RAM on each new SHARC chip in XITE ?
Is it in use w/ SCOPE 5.1 ?

Bud

The XITE-1 PCIe card is PCIe x 1 from memory. You can plug it into a faster socket but it only goes x 1 (correct me if Im wrong anyone - recalled reading this elsewhere).

As for the ADSP RAM, according to tgstgs could be redundant if developer focus on using the machine code native to the DSP :

http://forums.planetz.com/viewtopic.php ... 31#p284831

I'm *assuming* (again correct me if I'm wrong) that to get a high end verb takes a lot of time and work which you dont get for free just by using the RAM.

Would be interested to know if RAM might help in building a sampler app though..(tgstgs?)

dante wrote:The XITE-1 PCIe card is PCIe x 1 from memory. You can plug it into a faster socket but it only goes x 1 (correct me if Im wrong anyone - recalled reading this elsewhere).

We´re talking about different specs ...
http://en.wikipedia.org/wiki/PCI_Expres ... xpress_1.1

PCIe 1.1 and 2.0 relate to the PCIe protocol and doesn´t depend on count of lanes.

PCIe x1 tells it works w/ 1 lane, x4 w/ 4 lanes, x16 w/ 16 lanes.

So, if a PCIe card is spec 1.1, transfer rate is 250MB over 1 lane and if it is 2.0 it doubles the transfer rate up to 500MB over 1 lane.

Now, depending on PCIe protocol spec 1.0a/ 1.1/ 2.0/ 3.0 & 4.0,- real world data transfer depends also on what the motherboard/ chipset is capable of and I think that is what Gary was talking about above in the thread.
It might explain why XITE-1/D PCIe might behave different in different machines.

Nonetheless, I´d like to know if XITE PCIe works w/ 1.1 or 2.0 protocol in a PCIe x1 slot.

dante wrote: As for the ADSP RAM, according to tgstgs could be redundant if developer focus on using the machine code native to the DSP :

http://forums.planetz.com/viewtopic.php ... 31#p284831

I'm *assuming* (again correct me if I'm wrong) that to get a high end verb takes a lot of time and work which you dont get for free just by using the RAM.

Would be interested to know if RAM might help in building a sampler app though..(tgstgs?)

Well, I´m far from being a coder and don´t know anything about SCOPE SDK, but assume Analog Devices had something in mind when constructing these chips w/RAM.
Today, 32MB per chip isn´t much, compares to the max. of 32MB AKAI sample RAM standard.
Because the chips are organised in a column of four in 1 slot in XITE, I assume it would be a tricky task adressing more than 128MB,- if that is possible at all across chips.
OTOH, as a AKAI hardware user, I´d be lucky mimiking a AKAI S-1000 on one chip and have 32MB sample RAM on that chip without the need SCOPE using the computer´s RAM.
But I also imagine modulation and delay devices using ADSP RAM, especially when short delay times are needed only.
Or a imaginable device working w/ impulse responses, p.ex. speaker cab emulation or such.
And it could be usefull for single cycle waveforms/ wavetables for synth devices too.

Bud

Bud Weiser wrote:But I also imagine modulation and delay devices using ADSP RAM, especially when short delay times are needed only.
Bud

Well, I had a question on the other post which I've seen no answer to yet - about reverbs: "Can the sound of reflections can be calculated mathematically" - if so, maybe you only need to store one loop of the sound and calculate the reflections from it - hence no need for big amounts of RAM (for that purpose).

Sampling is another matter.

dante wrote:Well, I had a question on the other post which I've seen no answer to yet - about reverbs: "Can the sound of reflections can be calculated mathematically" -

I´m not sure if I understand that question correctly.

To me that is what every digital reverb does, in hardware or virtual, because "reverb" is nothing else than a variable dense cloud of reflections, being calculated mathematiclly and depending on user parameters defining the character of different virtual surfaces reflecting a sound.
So to me, the answer is yes.

dante wrote: if so, maybe you only need to store one loop of the sound and calculate the reflections from it - hence no need for big amounts of RAM (for that purpose).

AFAIK, calculating the reflections caused by whatever input signal and depending of a given set of parameters needs an amount of RAM always,- more dense reflections need more CPU and RAM.

Looking at convolution reverb units, it seems to be a similar technology.
Shoot a needle impulse into a room and record the response.
Works w/ virtual rooms too.
Can be used w/ any kind of input signal later.
Do it w/ a sound loop, the result is for that loop only.

But mathematical calculation in realtime needs CPU and RAM always.

dante wrote: Sampling is another matter.

I differenciate "sampling" from "sample playback".
When talking about AKAI S-1000 (p.ex.) emulation above, what STS-4000 is for me, I´m talking about loading AKAI library stuff into the STS.
AFAIK, the STS doesn´t need the host computer´s CPU as long there´s no time stretching in the ballpark like w/ STS-5000,- right ?
So, why using the host computer´s RAM for small sample sets like a AKAI S-1000 bank (32MB max) if there´s 32MB of RAM on a SHARC already ?
Now think about the eventuality adressing 128MB of RAM across 4 SHARC chips in a XITE DSP slot.
That would match the amout of (flash) RAM you have in a Kurzweil PC3K model,- just for loading samples and programs for a live gigging scenario.
STS doesn´t load a variety of sample set formats,- so for the gigabyte sample sets we´ll use Kontakt or such anyway.

Some time ago, there was rumour, Ferrofish might come up w/ more devices like the B4000+.
I think it would be possible to create a relatively cheap STS-4000+ desktop clone out of a ARM processor for the interface and 1 of the new SHARCs incl. 32MB RAM and USB drive to load AKAI banks.
Just as a idea, but some more static (flash) RAM would be welcome.

Bud

Bud Weiser wrote:AFAIK, calculating the reflections caused by whatever input signal and depending of a given set of parameters needs an amount of RAM always,- more dense reflections need more CPU and RAM.

But mathematical calculation in realtime needs CPU and RAM always.

I agree more dense reflection needs more CPU - but Im wondering why it would need more RAM, if at the end of the day, you get a sound wave as input, and another sound wave as output. If the transformation of output from the input can be done with a single pass mathematical formula, then surely there would only need to be enough RAM to store the input plus the output.

Storing all the reflections in between would be redundant if this output can be 'calculated' from input (fast enough) - wouldn't it ?

garyb wrote:on what, a new project or a saved project?

async is stuff connected to the motherboard's memory and resources.

I run Cubase 6.5 Win7 32 bit. It appeard from one day to the other when I opened an already saved
project which worked fine until that day. When I opened it again there was this error-message.

Maybe it has to do with my hosts RAM, HD-space.

Can someone recommend some hardware (CPU, mainboard, RAM, HD, ...) which runs fine with XITE-1
where I can use XITE-1 as it was intended, with many instruments, FX, ...??

Thanks

it's not the amount of ram or anything like that. it might have something to do with the order things get loaded from the saved project, or it may just be a corrupted project(it happens once every great while). that's why i asked if it was in a new or saved project.

i mean, 8 freaking profit 5s and then a problem, well...

in xtc mode, there's a hell of a lot more going on than in Scope mode. putting the plugins inside the host mixer is gonna use a whole lot more resources.

if a project that works lost its working after you reload it than the dspassignments has changed_

one fix COULD be to manually assign each dev to a dsp_ before saving the project_

good vibes

more math calculation needs more dsp cycles_
could use the host cpu as well but with some additional latency_
the stsXk are hostbased btw._
--
for a verb as well as for about any other device you need a unit delay a multiply and an add_

good vibes

garyb wrote:
in xtc mode, there's a hell of a lot more going on than in Scope mode. putting the plugins inside the host mixer is gonna use a whole lot more resources.

Thank you Gary,- that´s the answer I expected coming up here !
For me, SCOPE mode is the way to go and that´s why I never tried XTC mode at all,- I expected the plugin DLLs inside the host will need additional ressources.
B.t.w.,- I don´t have plugin DLLs for every device coming w/ SCOPE 5.1, by what reason ever, so it made no sense for me using only a fraction of what SCOPE 5.1 delivers and in XTC mode though.

Bud

dante wrote:

Bud Weiser wrote:AFAIK, calculating the reflections caused by whatever input signal and depending of a given set of parameters needs an amount of RAM always,- more dense reflections need more CPU and RAM.

But mathematical calculation in realtime needs CPU and RAM always.

I agree more dense reflection needs more CPU - but Im wondering why it would need more RAM, if at the end of the day, you get a sound wave as input, and another sound wave as output. If the transformation of output from the input can be done with a single pass mathematical formula, then surely there would only need to be enough RAM to store the input plus the output.

Storing all the reflections in between would be redundant if this output can be 'calculated' from input (fast enough) - wouldn't it ?

Correct me if I´m wrong, but everything which has to do w/ "delay" is temporary stored in RAM, depending on the delay time.
For "reflections" it´s the same as for delays, but shorter delay times, different ones and many reflection-delays.
The density of the reverb isn´t anything else than much more delays,- and all needs RAM.
Most rooms aren´t a cube and the soundsource isn´t in the center of the cube, so there aren´t equal delay times for the reflections.
As a result, every single delay has to be stored temporary and depending on the room shape to be simulated.
In your example, each separate delay (reflection) would need the "single pass mathematical formula input/output transformation",- that´s how it appears to me though.

B.t.w. and as a sideband effect,- "Single Pass mathemathical Input/ Output Transformation" makes a good album title for me.



Bud

Yes, everything to do with a delay needs memory, but the question is 'how much' - do you really need to store each and every reflection ?

If you have a source sound 'A' its possible to calculate the first reflection 'B' and then the second reflection 'C'. But do you need three seperate RAM chunks for these 3 ?

Since the sum of 'A' and 'B' can be stored in the same amount of RAM as 'A' theres no need to keep 'A' and 'B' in memory seperately any more before calculating 'C' - isn't it ?

Its a bit like 'bouncing' on the old 4 track machines. Once you bounce Track 1 and 2 together onto track 3, then tracks 1 & 2 can be re-used.

Take the Roland Space echo for example. If you wanted 'denser' echos, you turned up the speed, but the tape itself didn't need to 'grow'

A better album name here : 'The Growing Tape Loop Time Bandits'

Re: Digital room simulation

Remember, that sound does not only move in line parallel with the walls across the room. It also moves in any angle in between. Soon you'll see, that exact room synthezis in not really practical.