some X-lite's tech speculations...

[Lima]

Seeing that the max poliphony of a synth is related to the ability to fit in a single DSP, I suppose that the new card is able to increase the max poliphony of all the synth already available. I think that the most advantages will be in the modular side: let's think for example to some Flexor filters that actually have a max poliphony of 5 voices...

If each DSP is about 10 times more powerfull, then we can suppose that the poliphony should be 10 times greater!

Other advantages should be in the mixers: wth bigger DSP we don't need that phase compensation button...

What do you think about this?

[Mr Arkadin]

Let's wait till Xite is out before speculating on X-lite .

[Neil B]

And remember that a pianist, harp player, guitarist, synth player et al still only have 10 fingers and thumbs for realism.

[Shayne White]

Well, there's an old paradigm that never fails: no matter how much hard disk space or memory you have, you always quickly fill it up. Therefore, I would move that no matter how much DSP power we have, we will fill it all up at once.

Thus the need for two Xite boxes.

[hifiboom]

Seeing that the max poliphony of a synth is related to the ability to fit in a single DSP, I suppose that the new card is able to increase the max poliphony of all the synth already available. I think that the most advantages will be in the modular side: let's think for example to some Flexor filters that actually have a max poliphony of 5 voices...

If each DSP is about 10 times more powerfull, then we can suppose that the poliphony should be 10 times greater!

Other advantages should be in the mixers: wth bigger DSP we don't need that phase compensation button...

What do you think about this?

thats true...

but there also are some little disadavantages:

for example the new chips have much more onboard chip ram, which is a great feature for reverbs etc.

but this will also mean that new devices will have compatibitly problems with the old hardware.

So as a developer you either can take advantage of the new features and release maybe two versions ( for old and new hardware) or ignore the new features and build a version that runds on bother systems equally.

[Warp69]

So as a developer you either can take advantage of the new features and release maybe two versions ( for old and new hardware) or ignore the new features and build a version that runds on bother systems equally.

There's a third solution - only develop for the new system.

[HUROLURA]

So as a developer you either can take advantage of the new features and release maybe two versions ( for old and new hardware) or ignore the new features and build a version that runds on bother systems equally.

There's a third solution - only develop for the new system.

The problem would only occure in case of low level developpement. In case of high level developpement (with DP or the SDK for example), you do not have to manage such issues ...

The trick would be to get smart low level DSP-code modules that detect the type of hardware and thus optimize the ressource use "on the fly". Would be just a dream.

[astroman]

well, according to rumors about the chip type, it can process about 5 times the number of instructions in a given time unit, due to a higher clock rate.
Which applies to all code.
The remaining '2 times' is achieved by optimizing for the SIMD architecture of the chip, simplified a 2 steps instead of one feature.
Code has to be adjusted to take advantage of the latter.

While it may seem a frustrating task to 'modify' all existing DSP modules, in reality it's probably not that hard - starting with the most fundamental and most used operations.

cheers, Tom

[spacef]

and what about 96khz ?

(currently at 96 khz, everything works fine (on my side) except that each dsp has less than half the power of what it has at 44.1. so if you do not take care, what you set to run on 1 dsp might end up running on 2 for user of 96khz).

the method i have seen on xite and scope5 at the mess, where the user can allocate devices to a certain dsp seems the best to me, especially if we can make this function available to users on the sub-modules (ie various modules inside the device). That way, dynamic devices (mixers etc) can be allocated on a project basis, on user preferences, rather than on an automatic process that can end up wrong in some situations (as it is the case now, which forces developpers to take care of the allocation of the algorythm, and forbids to rely on the Scope own allocation in many situations (eventhough, it works pretty well in general, there are many situation where it is better to implement it in advance, as most sdk user know now, as the majority works at 44.1 or 48 anyway).

[DSP ADD!CT]

in the messe video they said that with a little more tweaking even more then 10 times was possible right?
who knows what they can pull off

bring it!!!!

[Jah Servant]

this is more speculation but I think it's going to have a fancy little hat with wires all over it and then you can control the mixer just by thinking about it.
It will look kinda like this

[capacitor]

and then, after a few years:



http://www.imdb.com/media/rm3401227264/tt0112682


(the above flick is supposed to be awesome)

[dubcotics]

LOL !!!! Capacitor you funny son of a gun :lol:

[Jah Servant]

unfortunately it looks like we'll all have to shave our heads for these things to work