Some thoughts about XTC mode
1. The way it works: to run XTC mode (e.g. in Cubase) one needs a properly configurated XTCProject.pro file. There are two modules (merge and DirectPlayContainer) that are not available anywhere else than in the originally installed XTCProject.pro file (why not, actually?) and that are of major importance for running XTC mode. Merge allows to mix down with XTC effects and instruments and DirectPlayContainer allows to play instruments in real time from within XTC mode. Both modules, as well as ASIO and midi drivers, have to be connected in very particular manners and not all ASIO drivers are good for this, in particular the DirectPlayContainer module does not seem to like 32 bit drivers. The original XTCProject.pro file is never properly configurated after installation and one always has to make changes by hand. These can be done without any problems with the SFP project editor (routing window). The “settings” window in Cubase is probably supposed to make these changes in a more user friendly way, but it simply doesn’t work.
2. XTC mode was first released with Pulsar XTC. The above said (item 1.) was not in the manual. The manual did not even mention the XTCProject.pro or the merge and DirectPlayContainer modules. Also, Pulsar XTC software did not include any software that would load the XTCProject.pro file. Lucky owners of Pulsar 2 would be able to edit this file with the Pulsar 2 software. Owners of Luna/PS/Elektra that additionally bought the Pulsar XTC card (like me) were not able to edit XTCProject.pro with the Luna/PS/Elektra editor either (error messages like wrong version, project cannot be loaded, etc.). These fellows had to wait with using XTC mode till SFP arrived. Funny, huh?
3. Since SFP everybody is able to edit his XTCProject.pro. However, the SFP manual still does not mention XTCProject.pro, the merge and DirectPlayContainer modules or how connections should be made. The whole needed information (see item 1.) was found out by users and posted in forums.
4. Recording with 32 bit depth is getting to a standard, the lates since Cubase VST/32. SFP has 32 bit drivers included and it should be supposed that one can use these in XTC mode. However, including 32 bit drivers in the XTCProject.pro file leads to errors with the DirectPlayContainer module (try playing a synth real time with a 32 bit driver in XTCProject.pro, and an error message like “DirecPlay input not compatible with whatever driver” will pop-up).
It is also absolutely not clear which driver is indeed active, since in the settings window (within Cubase) there are two options (16 and 24 bit drivers) and both can be clicked completely independently of what drivers are actually included in the XTCProject.pro. This seems to be an old forgotten feature that used to make sense when XTC mode was first released and there were only 16 bits and 24 bits drivers. As said before, I suppose that the intention was to automatically configurate the XTCProject.pro file from within this settings window, but it actually never worked properly.
It is also not clear what bit depth the merge module actually has, i.e. is merge actually processing a 32 bits stream with >= 32 bits, or does it converts down to 24, then passes it to the ASIO driver, and this one pushes it up to 32 bits again? Of course, absolutely no information on this can be found in the manual or elsewhere.
5. Resuming: XTC mode is not really an option.
Some thoughts about XTC mode
Gonzoft, you're right! A lot is unclear. But on thing is true (in my case): XTC performs a lot better than SFO-OS-mode when using >60% in Cubase SX / Nuendo. Please read my comments in "XTC sounding better ?" thread in "Problem solving". With Scope/Pulsar it's the only way right now to combine native/DSP - Power without killing native by the DSP-OS-GUI of SFP IMHO.
Well, yes. I agree with you that it is stable and leaves the native resources alone so that they can do their job in peace. But it is a great factor of insecurity not to know for sure which drivers are actually being used or if the inevitable merge module does not cut a couple of bits from the audio stream without any kind of dithering. The issue with the drivers is really funny: even if one uses 32 bit drivers, in Cubase they are always and everywhere identified as 24 bit ones. And who has the priority when selecting drivers, the XTCProject.pro file or the "asio settings" window? Cause the latter would automatically ignore the 32 bits ones, since it knows only 16 and 24 bits drivers. And it WAS designed to select drivers independently from what is in the XTCProject.pro (how else could it allow one to select between 16 and 24 bits without having both in the project file?). What kind of audio stream is this combination of XTCProject.pro, asio settings window and merge module producing? Very obscure...
** But it is a great factor of insecurity not to know for sure which drivers are actually being usedOn 2002-09-20 10:58, GonZoft wrote: **
-> The ones that are loaded into your XTCproject.pro. IMO it's bad luck the 32bits don't work so well, 24bits seems superior here for XTC.
** if one uses 32 bit drivers, in Cubase they are always and everywhere identified as 24 bit ones
-> Don't think so, it's only the Cubase setting that is not updated from the actual XTCproject.pro. If you record in SX 32flt and have 32flt drivers in XTCproject, it'll be the same 32flt.
** could it allow one to select between 16 and 24 bits without having both in the project file?
-> auto switching/loading? Could be just like XTC dev.
** What kind of audio stream is this combination of XTCProject.pro, asio settings window and merge module producing?
-> Forget about the asio settings window, use XTCproject.pro instead for routing and drivers.
-> Merge module takes same as ASIO devices, cos it's dsp<->VST via ASIO.
____________________
Onder voorbehoud ;o)
. Nevertheless, CreamWare should REALLY put a whole lot more information as to all this in the manual.