Scope/SC platform 5.0

Hi,

does anyone have any information yet as to whether (& if so, how) we SDK users would be affected by installing the new Scope 5.0 when it arrives? I'd assume that there won't be any problem & that all devices will run on 5.0, but was just wondering if anyone had any further info or insight??

cheers,
Mark

'bundling to a 15 DSP card' ?? I'm not following you with that Stardust. If you mean bundling of the M&M & S&S packs, then I'd presume that there won't be transfers as such, but that you'll get most of those plugs (or better alternatives) included. I don't know, but they're surely not going to give you a free upgrade that drops some of your plugs.

...but was just wondering if anyone had any further info or insight??

you're kidding, aren't you?

...but was just wondering if anyone had any further info or insight??

you're kidding, aren't you?

No, not really. I won't be installing the new Software until I know what implications it has.

No - stop - I meant with bundling the precondition that the SDK can only be run on 15 DSP cards currently.

I'm still not really getting your point. I also don't see the point of this thread any more. I'm glad it wasn't me that posted it.

...but was just wondering if anyone had any further info or insight??

you're kidding, aren't you?

No, not really.

what I wanted to say is: they are so cagey about it, I doubt that anyone here has further information. they are so few people that it would be quite clear where the information leak is, so this is a perfect conspiracy. I'd like to know more on this, too, but I'm afraid we will only know when it's there.

sorry for not being helpful at all...

-greetings, markus-

Will the free SDK run and be licensed on a XITE as well ?
And.
Will the SDK (4.0) devices run easily on scope 5.0 ?

AFAIK the SDK environment will run on the XITE system, but I dont know if SC have any intention to license the free SDK on the XITE system. The XITE system would be unusable for me if I couldn't use it for development.

I know that SC have tried some early versions of my reverbs on the XITE system without problems. I would imagine that there're limits to what can be changed in Scope 5 for the current version of HW - The XITE system is a totally new design and WILL therefore be quite different compared to the current Scope boards. The XITE system will be one of the best prototyping environment from my perspective - the only thing Im missing from the current spec is support for 192/384kHz support or even higher - That would have been absolutely awesome.

the only thing Im missing from the current spec is support for 192/384kHz support or even higher - That would have been absolutely awesome.

true!
but that may come in the future.

I`d also like to see something like an internal upsampling and downsampling atom, so you can decide, where you need higher sampling rates inside your creations and where you don`t need it.

= ressource safing.

I`d also like to see something like an internal upsampling and downsampling atom, so you can decide, where you need higher sampling rates inside your creations and where you don`t need it.

= ressource safing.

That would introduce latency of x samples - depending on the chosen downsampling algorithm - but it would be a nice addition.

AFAIK the SDK environment will run on the XITE system, but I dont know if SC have any intention to license the free SDK on the XITE system. The XITE system would be unusable for me if I couldn't use it for development.

I know that SC have tried some early versions of my reverbs on the XITE system without problems. I would imagine that there're limits to what can be changed in Scope 5 for the current version of HW - The XITE system is a totally new design and WILL therefore be quite different compared to the current Scope boards. The XITE system will be one of the best prototyping environment from my perspective - the only thing Im missing from the current spec is support for 192/384kHz support or even higher - That would have been absolutely awesome.

I'll probably only get one when I can afford it if I can have an sdk with it or the required tools/extensions for the current sdk. I'm really looking forward to building things specifically for running on those new dsps.

what I wanted to say is: they are so cagey about it, I doubt that anyone here has further information. they are so few people that it would be quite clear where the information leak is, so this is a perfect conspiracy. I'd like to know more on this, too, but I'm afraid we will only know when it's there.

sorry for not being helpful at all...

-greetings, markus-

Yes, I absolutely understand markus. I realised this last night after posting this thread & that's why I said I no longer saw the point of having posted it.

Thanks for clarifying that for others though..

.oO( it's sooo fu**in' top secret )

But isnt there an option to do that in HW ?
e.g. 48 kHZ at the interface but 96 internally ?

The new DSP chips does include SR converter algorithms - but it's a nice idea to have 192kHz or 384kHz internally and max 96kHz at the audio interface, since they only support 96kHz as max SR.

I think using 192khz or more through the whole chain would be nice but also a lot of waiste of power potentially. because simple processes would not really profit from the higher sampling rate quality wise, but would take much more power.

via up and downsampling you could decide as a developer where and when you need quality atoms inside the development structure.

On the other hand when many upsampling and downsampling processes are used it may make sense to calculate an complete device at higher sampling rate.

Some sort of mixed environment could be nice too. So that you could specify via device (synth,fx) at which sampling rate you wanna run it, although the master scope system just runs at basic 44,1.

just an idea...

Hifi, I don't think downsampling in Scope is really an issue either technically or cost wise so there's probably not much point discussing that.

what i meant to say is:

lets say you have a circuit with f.e. 4 atoms...

if you use 192khz in one atom it may be useful to upsample before atom x and then downsample again after that processing stage, the rest runs at 44,1khz

but if every of the 4 atoms needs running at 192khz, it may make more sense to upsample once at the beginning and downsample once again at then end. that saves power.

Even if the xite-1 has great dsp power, I don`t like to see developers waste the power for the ease of coding.

Right I'm with you now. So it wouldn't be a standard downsampling technique that you'd use to downsample from say 44 to 22 or whatever.

not really 22khz,

the lowest sampling rate is 44,1khz I guess, so you first upsample to a rate like 192 or 384, then do a process, and then downsample to 44,1 again.

I think nobody would downsample to 22khz and then upsample to 44,1 again as this would directly affect the audio quality in a bad way.

finally doubling the sampling rate of a complete system will simply halfen its overall power.

So an xite-1 running at a complete-environmental-384khz-mode would divide the power through the number 8. give the rough power of a scope pro for a bit higher quality which may be more obvious here or there.

with 192khz through factor 4
and with 96khz half the power.

So I think a more advanced split of the power and the possibility for internal sampling rate changes could be quite cool.

for example there is no need to run the basic stuff like mixers, etc. at much higher Sampling rates.

For a filter, a reverb plug-in or a synth it could be quite powerfull at least at certain internal stages.

I understood all of that before, but I think you misunderstood what I meant regarding 22kHz (that was just an example btw). I just had it in my mind that downsampling from 44 to (say) 22 in sdk is very simple & low cost, but that fact isn't very relevant to what you're talking about.

how?
can you downsample to 22khz?

as i cant. lol

I'll post a module, but I can't do it right now because sharc's using the sdk.

sounds interesting. i`m curious.

Since Hifi asked, here's a simple method/trick to downsample an audio signal in sdk from for example 44.1 to 22.5 kHz (or 11 or whatever). Nothing special & as I mentioned further up the page, it's not really all that relevant to what Hifi was talking about in terms of upsampling to high sampling rates & back down again. It's nothing impressive at all & would need the internal pot removed in use to reduce size, but anyway, here you go -

okay thanks shroomz.

But thats only half of the story, as the audio chain still runs at its native 44100 samples per second.

a "real" downsampling would calculate only 22050 samples per second and so save half of the scope dsp power or spoken in other words can calculate two 22050 samples-bitstreams at a time for the price of one 44100 sample-calculations.

otherwise every lowpass filter can be called a downsampler.

As I just said.

as I mentioned further up the page, it's not really all that relevant to what Hifi was talking about in terms of upsampling to high sampling rates & back down again.

I don't understand the point of the handshake imagery hifi. DSP to PC handshake?

no, the picture does describe "agreed".

As I just said

another form of 'fo shizzle ma nizzle ?

Ok Hifi.

It actually looks like a 'secret' handshake like something from a mason handshake teaching class.

the lowest sampling rate is 44,1khz I guess, so you first upsample to a rate like 192 or 384, then do a process, and then downsample to 44,1 again.

So I think a more advanced split of the power and the possibility for internal sampling rate changes could be quite cool.

for example there is no need to run the basic stuff like mixers, etc. at much higher Sampling rates.

It would ofcourse be nice to have up/down sampling as modules, but would it work? You'll introduce x sample latency - depending on the algorithm ofcourse - when you downsample - better quality more latency. Let say you have a filter and a summing engine in some kind of series (and you're unable to combine those two functions), both using a up/down sampling module - the downsampling algorithm use ex. 11 samples of latency, so you would introduce 22 samples delay in your device compared to all other devices in the environment - we cant have ADC, since we have a realtime system. How should that work?

We could eliminate the latency, but that would introduce aliasing in the downsampling - the exact same thing we want to prevent in the first place.

I think nobody would downsample to 22khz and then upsample to 44,1 again as this would directly affect the audio quality in a bad way.

I would need to downsample to ex. 16kHz, if I choose to emulate the AD/DA stage of vintage reverbs.

Warp, why would introducing a latency like a 22 sample delay in a device be a problem if users are informed of it? Surely users can easily compensate for that if they're made aware of it? I've read that TD on Scope has a significant latency, but I don't have it so couldn't say exactly how much.

Well - you could experience phase problems if you decide to mix the processed signal with the dry signal. But you're correct people could just compensate manually - they already have the problem with the look ahead function in a compressor as you descripted via the TD. But let say you have a path with sereval plugins with latency - combined around 200 samples - then that channel is delayed 4.5ms compared to all other channels from the DAW - you would have to compensate for every channel.

I guess that's what having a 0-200 sample delay per mixer channel is for.

I guess that's what having a 0-200 sample delay per mixer channel is for.

Im also using that for HAAS effect

Good point..