Is there any real benefit in using XTC opposed to SFP ??

[musurgio]

I cannot find a single benefit using XTC instead of SFP.
Can anyone make me feel differently ?

Regards,
Dimitrios

[valis]

If you're familiar with the Scope interface and with recording versus rendering, then no, but I'm with the majority in appreciating the incredible flexibility of Scope. Without Scope's routing I suspect I would feel like Logic without the environment.

I can understand why people who are comfortable in certain VSTi environments might approach Scope from a direction that finds XTC more accessible. Honestly I've never put enough time into it to know if there are any tangible benefits. The added latency from PDC and the round trip to the pci bus always puts me off.

[voidar]

I think I would ask the question the other way around. What can you do in OS-mode that you can't do in XTC-mode?

Despite for some synths that use the "ugly", old preset system, I can't think of anything but a few annoying quirks.

It all comes down to your host sequencer as you will be doing all your "hot" routing in there. REAPER is great for this, Tracktion 2 works well too and I guess eXT.

The way you set up your project is also important and I find I am discovering new things each day, to use a clichè..

Everyone who is familiar with Scope has to be familiar with recording instead of rendering. I.e REAPER I can do this internally without leaving the appl. through ASIO.

I don't have to keep track of what ASIO channels are connected to what, and I can keep everything on one "screen"; one workflow.

If I want ot expand this I'll just edit my project to load a mixer at start up and do all my summing on DSP, then record that if I want. All mixers can work.

PDC means sample-accuracy. Setting up parallel compression in OS-mode can be tedious. Try with a Vinco on RMS i.e. Your are more or less left to faith.

I _can_ freely mix and match native and DSP plugins as I please without much ado, even though I prefere DSP religiously.

Besides summing there is no loss of quality associated with the 32-bit float/32-bit integer conversion of a single audio stream when done properly, like Creamware is doing with their VST-wrapper and ASIO drivers.
You can test this yourself by passing a signal from 0 dB0 to -inf through a bypassed (on DSP) XTC-plugin. You should reach below 180dB in headroom.

Some quirks:

Enabled MIDI fails on startup, but works when enabled after. This means an extra annoying trip to host-sequencer preference/setup. Maybe there is a way to solve this as it was for the sync plate issue. XTC-mode is still being excavated .

Side-chaining with stereo dynamic processors is a bitch due to the two (2) input limitation of the VST-wrapper.
To overcome this one must use two (2) mono instances of the processor instead and most likely use a phase-fix or the native alternative Voxengo Sample Delay to correct the sample offset that might occure.
This of course requires a host-sequencer that does advanced routing and/or parallel processing.
You can also use OS routing for side-chaining (right click -> select), but this is not saved with the project.

Some plugins, like SPL, are not XTC-enabled and has no preset-system so you can only save its setting when its loaded in a MultiFX module.

However if you are happy working in OS-mode then that's all that counts.

[steffensen]

You cant use Modular in XTC mode, i.e build along the way. I think you can make ready made patches into XTC-devices tho.. but thats not what modular is about imo.

[voidar]

True, not in the sequencer. Howere I am pretty sure you can hardwire a modular into the XTCproject. Just leave the surface displayed on save/close.

Even if it's connected or not, you could edit and save as you go. Preferably to the same .dev if you are progressively working on a patch. Then just reload the VST and it should run.

[steffensen]

As the host im using now, is pretty modular (freely routing), i wouldnt mind trying out XTC again, IF there was a way to get modular working in it that is.

I spose i have to close the host, reopen SFP just to browse thru my modular patches, and then save the XTC project with the patches ive choosen, etc.. Feels like a lot of work, instead of just using SFP instead, with no latency.

[voidar]

No, you do this:

1. Load an empty modular into XTCproject.pro. Optionally: connect it via MIDI and to outputs for monitoring if you like.

2. Save a MyPatch.dev

3. Make sure modular surface is open (must be left open), save XTCproject.pro, enable XTC-mode and close SFP.

3. Create a MyPatch.dll from any .dll

4. Fire up your ASIO-host.

Voila, the modular surface which you left open in SFP should load as a new window - you've just opened a little window into the SFP-world (!) where you can work on your patch as you please. Be carefull not to close it as you will only be able to recall it by restarting the host or by sending a MIDI value to a controller assigned X (close) button.

Scan for MyPatch.dll and make sure it loads without problems. You might get an error which you can ignore. If you use Mod III you can avoid this by saving the device with just the MRC loading.

For every time you wish to test your patch just save the modified MyPatch.dev and replace your VST instance ot MyPatch(.dll) in the host. You don't need this if you've already hardwired the modular like in the first step, but that only complicates a project. Or perhaps it's a good idea as the modular doesn't have a Direct Play mode (I guess).

[steffensen]

Tons of work, for something that works instantly in SFP..
But ok, let say someone actually is willing to do all this work, does the patch get saved along with the track in the host? Or does one have to save it indipendently? (like u would anyhow for that matter..)

I can feel there would be a LOT of closing the host - reopening XTC project - editing - over and over..

again, SFP feels a lot smoother to work with.

[voidar]

But you're not closing the host... (!)

And this is for people who like to work in XTC-mode yet want to use the modular - even create and edit while your ASIO-host is running. If your only concern is to use the modular then by all means just use OS mode .

Each unique modular synth (configuration) needs its own .dll, and I presume each synth can have different patchings like in the real world. I don't know how this would work, but presets are probably loadable, like any other device.

If you load a VST-instance MyModular.dll and a preset, save the host programs project and recall it later on, it should load as you left it, like any other synth. I have never tested this though, but in theory.

I am just explaining what you can do as you asked a question.

My point is that, with this option you have just two windows to work with which means less mousing in my experience:

1. Host with all effects and synths loaded - project

2. Modular hardwired to the XTCproject for editing/creating new sounds.

[steffensen]

Im in no way defending/attacking, im just thinking out loud really.

I would actually enjoy using XTC mode from time to time, as i would love to be able to use the SCOPE plugins along with my native ones.

Tho, integrating Modular feels like a almost impossible task.

When im producing, i either build patches along the way, or editing already made ones, or simply use stuff ive did before. I always have at least 4 diff modulars goin in a project.

And if i get you right, i would have to have a Modular dll for each new patch i do?
Lots of patches. And if i wanna add/remove a modular, i have to quit my host, open XTC project in SFP, edit, save, reopen the host etc. for each and every tune i work on.
Thats what i ment before.

XTC is fine with plugins, but for Modular, thats a diff story...

[steffensen]

Just to add to the theoreticly speakin section..

http://www.planetz.com/phpBB2/viewtopic.php?t=19127

using the above, might be benefitial with XTC. As this modular shell/host, can be opened as a scope plugin.

Heres hope djmicron develops this beast further.

[voidar]

Merely discussing, sure . Wich is good.

XTC and SFP-mode are two different production paradigms and I am sure they have their strenghts and weaknesses for each way of working.

For adding/removing a modular to your XTCproject, yes you would need that. But I don't see why you would want to add more than one. It's only for editing a patch one at a time. Think of it as a notepad editing multiple .txt files. For the ones you want to review or won't work on for some time, just load them as a VST instance, playing back whatever.

Yes, there will be quite an amount of .dlls, one for each .dev. It really depends on how many you create, how many unfinished patches you keep etc. You will eventually want to clean up.

A way of working could be to first contemplate on how many modulars you want to use for a certain project (restriction prevails), and then create devices and .dlls called MyProjectA ... MyProj...B .. .C etc.
Load them all as VST instances, then start editing device A via the modular shell loaded with your XTCproject. Save, then Delete/reload VST instance "A" once you're mildy satisfied and want to proceed onto "B". Proceed and keep cycling until you're done.

If you were performing live, SFP-mode would be the fastest and most flexible obviously, but with all the time in the world XTC-mode is not necessarily a bad thing.

There is a lot of XTC-bashing on this board it seems . Yes, it deserves critique for not being 100% complete, but it works surpricingly well and transparent.

[voidar]

Just to add to the theoreticly speakin section..

http://www.planetz.com/phpBB2/viewtopic.php?t=19127

using the above, might be benefitial with XTC. As this modular shell/host, can be opened as a scope plugin.

Heres hope djmicron develops this beast further.

Yup, it's quite interesting. Especially if you want to load Flexor stuff as inserts in either SFP and XTC-modes.

Sadly djmicron has removed the device indefinitely.

[steffensen]

As i have nothing better to do tonight, im gonna try this out..
I managed to ge tthe modinsert by micron before he removed it, hopefully he wont get upset if i try this out. Its not like im sharing his device in any way.

[steffensen]

Interesting.. Using a modular as insert efx is working nicely (in XTC mode). One build in realtime and do allmost everything one can in SFP. As a synth, not working yet however..

[voidar]

You mean the Modular Insert module? I guess you load it in MultiFX or such.
It will probably need a VstSynth.dll shell to function properly as a synth.

[steffensen]

You dont have to use MultiFX, just use it as a regular scope efx. It takes the old trick with renaming dll's etc tho.
I did the same for the synth, but it wont load the mod patch. For efx, it works like a charm however.

As u can save the patch as a .dev and .mdl, im gonna investigate further today.
Only tested with .dev as of yet..

Im sure micron can sort this out, when he's back on track. This is pretty revolutionary imo, so i hope micron realizes what he have discovered/created.

[valis]

I think I would ask the question the other way around. What can you do in OS-mode that you can't do in XTC-mode?

I can still think of quite a bit that the OS-mode is useful for.

For starters, zero latency monitoring of effects for monitor sends, possibly with a separate recording chain. Certainly this is more useful for those with outboard instruments or vocalists, but I find I use this in many other ways.

A simple non-music related example: I have a gaming soundcard in my main DAW as a second soundcard used for the 'default' audio out. I could lose the gaming card (really I should) and just use the RME for everything, but there are cases where it's still useful. For instance the RME will also not internally clock to lower than 44.1khz so there are a lot of files and flash applets online that either don't play or throw up samplerate mismatch errors. So I have it assigned so that all the typical 'windows' style audio goes to it: Myspace crap, occasional recycle edits alongside my main ASIO host or for gaming (2% cpu usage in a game compared to close to 10% for my RME wdm/mme drivers). Now for some reason using its mic input crashes my entire system (freeze), probably due to the amount of other stuff I have installed (RME HDSP, additional usb2 & firewire, Nvidia Quadro4 pro gl card, etc). Using it for anything else does not, so I can assign the game's output to its drivers which have been optimized for games.

To get the gaming card mic input to work still with the cheap headset that I refuse to replace just for 20-40 minutes of gaming, I swapped the drivers from the Creative Labs one to the KX drivers, then routed inside the KX DSP appliet from the mic input to the channels 3/4 outputs on the gaming card. Those outputs go up to a tape return on my Soundtracs board that sits unused. During gaming I sweap those tape inputs down to the main faders with the 'mix' switches, set the channels to route to bus 1/2 instead of the main bus as bus 1/2 on the board are routed into my Creamware cards. Once the audio enters Scope it is slightly compressed with Vinco, a bit of a hipass and midrange boost in PEQ4 to better provide the compression codecs in the games with the frequencies they're tuned for, and the a bit of soft clip/limit action from Optimaster just to make sure I'm driving the compression codecs as hard as I can. I route the signal back into the main DAW via aes or adat, and then assign windows 'default recording input' to that RME input so that my games will 'see' it. The result is that people never have a problem hearing me in games :p I could use a studio mic but even with a boom or stand that's a lot more ungainly and doesn't leave me as free to shout and move around as I blast people in UT.

I'm not sure how many people here that appeals to (gaming) or who even bother to read messages this long, but I also have many other uses for OS mode that aren't directly related to working on a tune in Logic or Cubase. For instance when I do online broadcasts I can route the signal through Scope for a bit of limiting & cleanup before it hits the LAME mp3 codec typically used in the modern Shoutcast encoders (and sent at 128kbit in most cases). This is even MORE useful for really low bitrate compressed audio, whether streamed or rendered to a file. The hotter the signal you can give low bitrate codecs, the better the results, at least in my experience. This runs somewhat contrary to the continuing education against high RMS levels but I can think of many people that this would be useful for (podcasting seems to be a popular thing these days).

I also enjoy using the OS-mode to get several audio drivers going alongside one another & rip snippits of voice and other interesting bits from various video feeds online. Technically you could do this with a variety of other setups too. As a side note, C-SPAN here in the US is now releasing all of their broadcast content under a license based on one of the Creative Commons licenses, so that public use of their material is more free (meaning you can find stuff on Youtube again).

There's probably 30 other things that I could think of if I sat here long enough...

PDC means sample-accuracy. Setting up parallel compression in OS-mode can be tedious. Try with a Vinco on RMS i.e. Your are more or less left to faith.

I _can_ freely mix and match native and DSP plugins as I please without much ado, even though I prefere DSP religiously.

This isn't true. Reaper (or any other sequencer) can compensate for any known or detected buffer sizes and round trip latencies, but working inside the scope dsps isn't 'sample accurate' in the strictest sense for a variety of reasons. This most well known & talked about is the fact that things will load into the dsps a little different each time. This is compounded by the presence of an STDM cable, and even single devices might overlap more than one dsp under normal use. Things get a bit worse as dsp usage rises. This is an advantage from the perspective of efficient use of available dsp, but don't expect your parallel compression to be bulletproof in all cases. Instead I would use a self-made 'impulse' click to measure & verify the various tools I use. Most shifts won't be more than 4-5 samples in either direction, that may be something you can live with.

Over & above that known issue, no external gear is 100% 'sample accurate' compared to VST/AU/etc for a variety of other reasons. For instance in Drum&Bass I always sample externally generated subbass so that I can control the exact phase of the note-on. MIDI is the weak link here, although it exists as a bottleneck in either OS mode or XTC mode so I guess that's a tossup. You're probably aware of it anyway but it's good to state that just so people don't see PDC as a 'magic bullet'. In fact the control data in Scope runs at a different datarate and on the host cpu, so it isn't in any way really tied to your PDC system, as an lfo sweep in a VSTi would be for instance.

However if you are happy working in OS-mode then that's all that counts.

And I would say the same for XTC mode My statements at the top are based on personal preference, and what I point out here is simply for discussion's sake. Your post did point out that typical sequencer based workflows with PDC do benefit from XTC mode. I certainly wouldn't hold it against anyone if they prefer XTC mode, and I wouldn't be against trying it out for fun here & there. But my personal preference is that the OS mode sticks around as well and is continued to be developed.

[steffensen]

Now thats a Valis-cleanup.

[voidar]

valis:

XTC-mode is only meant for music production.

On my system SFP fires up at start-up with my "Passive"-project, obviously meant for gaming or general audio playback.

Reading the manual I think the hardware works in the background in Win 98/ME if not SFP is active. This is obvoiusly not so in XP.
Can anyone confirm this for 98/ME?

The VST-plugs report their latency correctly to the host, but obviously in some cases and depending on the device, the device will load onto multiple DSPs. Or during a optimization process, devices that loaded on a single DSP might be split over multiple DSPs. This causes an internal phase in-accuracy. This counts for both modes and is obviously not an argument for any of the modes due to the shared weakness.

What I meant though is that when routing in OS-mode over parallel connections, sample accuracy must be corrected manually whilst this is done automatically by a VST-host with PDC.
For some tasks this sample-offset, all though small, will create audiable phasing in audio.
Doing parallel compression on a drum buss with Vinco @ RMS-setting can be a very tedious process in SFP-mode. A slight sample-offset between the wet and dry levels, and the high-end (cymbals) will sound like crap.

PDC makes life easier and yields analog results, as only digital hardware can produce the defects in sound associated with sample-offsets.

In this regard I say my argument stands.