Display problems

[Lance]

Bob;

I'm having display problems with MWS which is similar to other display problems which I've had in the past with the main MT and FMixer window. In fact, the freezing seems now more frequent with the additional windows that I have open.

The problem is that sporadically, different active windows cease to update and they just freeze. However, the audio continues to playback with no problems, the window just stops displaying. The "hot" zones seem to work ok if I click on them, but the display doesn't reflect these changes either...they just operate as clicked.

i.e. in MWS, I'm watching the notes as it plays back...the cursor is moving along, all of a sudden the cursor just stops updating, but the system still continues to play. When I right click in the "frozen" area, playback stops, and if I right click again, it starts...no problem. But the display just sits there.

BTW, this has happened before with the FMixer and also the MT window.

I have systematically gone through and disabled all the graphic card acceleration (ATI Radeon 8500) until the windows screen updates crawled. But the display still freezes. I also disabled all the screen effects and it still freezes. As well, I have the workspace stretched across both monitors and the various SSL windows are within this workspace.

I do a standard save, exit, then re-launch SSL and it works fine.

I am running dual monitors off this one card and do not have this type of problem with any other application.

Any ideas?

I will try to see if there is some sort of commonality to the freezing...

Thanks.

Lance

[Lance]

Bob;

OK.. some things to add to this...

In MWS, when the display freezes:
The transport controls still operate and change when I click on them.
The hot track indicator changes.
The vertical cursor position changes to wherever I click in the window...and playback starts from that place...

However, once playing, the cursor does not move and the display does not update.

Lance

[Bob L]

Sounds like device contexts are being locked... there are possible loopholes in my plugins that were discovered while we were debugging Pieter's last Compressor plugin.

The problems only seemed to ocurr on dual cpu systems... and then only on certain motherboards and under certain exacting conditions.

Are you using a dual cpu system... or does your cpu use HyperThreading... if so... follow the tweaks suggestion for disabling Hyperthreading or dual cpus and see if that solves it.

Otherwise... more specifics are needed... it may be related to certain plugins, mine or others... you will have to take note of screen details or events that may be significant in tracking it down.

Bob L

[Lance]

Sounds like device contexts are being locked... there are possible loopholes in my plugins that were discovered while we were debugging Pieter's last Compressor plugin.

The problems only seemed to ocurr on dual cpu systems... and then only on certain motherboards and under certain exacting conditions.
As we move forward into dual core cpus and hyperthreading as a norm, do you have a path for solving this problem? It would be a shame to not be able to take advantage of the power. Especially with dual core cpus, this will be a necessity.



Are you using a dual cpu system... or does your cpu use HyperThreading... if so... follow the tweaks suggestion for disabling Hyperthreading or dual cpus and see if that solves it.

Otherwise... more specifics are needed... it may be related to certain plugins, mine or others... you will have to take note of screen details or events that may be significant in tracking it down.

Bob L
Yes. I am using a dual CPU system. I will try disabling and see if it works. I'm only using MWS and the Edirol Super Quartet Vsti, 6 instances on different tracks in the MT.

I will look for exact conditions in MWS.

Regarding my similar screen problems with the MT and FMixer windows, they generally occur during playback when I drag a DSP-FX module, typically, the Studio Reverb across the window, or move it from where it sits on top of the FMixer/MT window. Then I get an area about the size of the plugin which does not refresh, within the particular window and I think that the window overall stops working.

In fact, I believe that the problem always occurs duing playback.

Thanks Bob.

Lance

[Bob L]

How did I guess dual cpus? :)

You may be surprised to learn how little increase in performance (if any) dual cpus actually dilever in common real-world applications.

SAWStudio is designed to handle duals specifically, but unfortunately Windows and drivers and other system components like firewire drivers etc... can cause all kinds of grief in dual cpu systems.

Disableling one cpu might actually improve your system performance... most definitely your system stability.

Bob L

[Lance]

How did I guess dual cpus? :)

You may be surprised to learn how little increase in performance (if any) dual cpus actually dilever in common real-world applications.
Actually, I get a significant amount of increase in Photoshop and Premiere.

However, when I use the Force to One CPU setting in your program, I must say, I actually do get better performance... i.e. lower %CPU usage...by approx. 1-2 points. Very interesting...



SAWStudio is designed to handle duals specifically, but unfortunately Windows and drivers and other system components like firewire drivers etc... can cause all kinds of grief in dual cpu systems.

Disableling one cpu might actually improve your system performance... most definitely your system stability.

Bob L
Actually, my problems seem to have stopped when I use the Force to one Cpu option.

Overall, I don't really have a problem with system stability... things do work as they should.

It would be interesting, given the proliferation of Dual CPUs and Hyperthreading, to have a panel in SS that can allot CPUs to different functions in SS, i.e. one devoted to the Playback engine. The other devoted to Plugins.

Currently, I'm using Dual Xeons in Hyperthreading mode so it looks like 4 CPUs (small wonder that SS is sensitive to my environment :D ) and I'm sure that much of the power is being wasted... but it would be nice to be able to allocate resources and distribute and load balance the tasks.

This is, of course where Intel, AMD is headed. In fact my Creamware card does this with the 6 DSPs onboard. (highly recommended btw)

Thanks for the help...

Lance

[ambler]

Lance, You might want to experiment with SMP Seesaw (http://www.mlin.net/SMPSeesaw.shtml) from Mike Lin. It allows you to assign processes to a single CPU, restrict a CPU to specific processes etc. I don't know if it will address your specific needs but it's worth a look.

Mark

[Lance]

Mark;

This looks very interesting and will give it a try.

Not sure that it will be that effective for SS specifically because the application and plugins will most likely appear in the same process context and not as seperate applications or threads. i.e. vsts don't show up in Task Manager, but SawStudio(Lite) does.

Nonetheless, it is something like this that I was suggesting to Bob that might be valuable (and perhaps revolutionary) in the DAW environment.

Thanks.

Lance

[Bob L]

SAWStudio does already designate specific processes to the different cpus... it is very well designed to split screen and display operations and engine and mix proccessing operations between the cpus...

There are dozens of active threads in the engine that require specific priorities and timing to operate efficiently.

The display problems can become very tricky with duals and a complex realtime environment like SAWStudio ... each plugin dll and hardware driver dll that is part of the loop must be so designed as well... and these are out of my hands...

Screen updates are happening all simultaneous from the user adjusting controls and workspace views and the engine updating the cursor and scrolling the screen in realtime... all with dozens of active threads firing in specific sequences with timing interactions at the nanosecond level... not a simple scenario to say the least.

The Force Single cpu option keeps all SAWStudio processes on one cpu... but as I have stated in other posts, drivers and plugin dlls can still be split between the cpus randomly... thousands of variables are being updated per ms and if every possible variable is not protected properly from two different routines processing at the exact same instant... BOOOMMM... this is a much harder process to tame when 2 cpus are trying to access the same memory and hardware buses and video drivers and display hardware all at the same time. :)

This is still not the same as using the /ONECPU option on the boot.

Bob L

[Leadfoot]

About the 2 cpu thing, first off please know that I'm not trying to annoy you and I understand your explaination of why 2 cpus is a potential problem.
I like the idea in an earlier post about trying to use one of the 2 cpus for vst & dx plugs. Would there ever be a way to force the saw program to one cpu, but force the effects api to the other cpu? One of the only problems I ever have is running out of cpu from plugs. I know the workarounds and have no problem with that. Like I said, I'm not trying to annoy you with this topic, just asking an honest and imo reasonable question.

Thanks for everything ofcourse.

Tony

[Bob L]

Each plugin runs its own dll and is independent of SAWStudio. I already separate the processing threads that calls the plugins... the rest is totally dependent on the plugin code... and also you must realize that a DX plugin depends on thousands of Windows dlls and registry links... and a VST plug also depends on many core VST component library calls that all also need to be dual cpu aware...

Trust me... it gets very complex... and in my opinion, will probably never be all ironed out for these types of apps.

Bob L

[Lance]

Each plugin runs its own dll and is independent of SAWStudio. I already separate the processing threads that calls the plugins... the rest is totally dependent on the plugin code... and also you must realize that a DX plugin depends on thousands of Windows dlls and registry links... and a VST plug also depends on many core VST component library calls that all also need to be dual cpu aware...
I'm sure that this is true. Yet, for sake of argument, there are many other programs out there which are able to operate in a dual cpu/HT environment without problem. Photoshop and Premiere both work well. Premiere even has ASIO support. Though I don't like Sonar, I used it for 2 years prior to buying MWS. Sonar never had any display problems. I'm sure that the competitive DAW landscape has many programs that, though they are not as easy to use, nor sound as good as SS, do run fine with dual cpus using both DX and VST. All I'm saying by this is that it can be done... and as we move forward with Intel and AMD, it will become a necessity by 2007. Intel's first dual core CPU is due out second quarter of this year and there are 15 models of dual core processors scheduled for release in 2006.



Trust me... it gets very complex... and in my opinion, will probably never be all ironed out for these types of apps.

Bob L
Bob, someone is going to have to do it. And as this industry matures overall, being the infantile state that it really is in, someone will. This is called progress.

From here forward, we're entering the land of multi-processors. I wouldn't think of going back to a 486 or Pentium II at this point to do any serious work. As it is, I find it extremely productive to have two processors. I do feel an impact with the responsiveness of the machine. I like to jump from SS to Masterwriter to work on Lyrics without shutting down SS. I like to check my email or take a look at this User Group board... bouncing between apps. Yes, you can do this with one CPU, but it really isn't as responsive as two, and like it or not, the industry is moving away from a one cpu model, to a dual core model.

The fact is that I love SawStudio, as do many others here. But a crossroads is coming in the next year to two years where if SawStudio can't operate in a dual cpu environment, that environment will affect the programs marketability, because every new PC will have a dual core chip. We're already seeing more and more posts on this board about problems with Hyperthreading.

I've had dual CPUs for 2 years now and have lived with the graphics problems which I had first emailed you about at that time, 2 years ago. However, since getting MWS, the problems have increased. My system is the same, but the graphics problems are worse. Yes I can make music with the system, yes, it sounds absolutely fabulous and yes, I wouldn't trade it for anything at the present.

However, when the program goes south in front of talent or clients that I have in the studio, my professionalism comes under question. Once I have to explain why I'm exiting and then rebooting in the middle of a take, my position has been compromised.

Thing is, the only real problem with all this dual cpu/Hyperthreading controversy is the graphics issues. I haven't heard of any sound driver issues or SAW Engine issues, or any other issues related to Dual Cpu/HT. In fact, if we consider graphic co-processors like the ATI Radeon problem recently reported, isn't this also a form of a dual processor issue between the GPU and the CPU. Isn't this why reducing hardware accelleration settings is one of your solutions? It just brings everything back to a single processor environment.

Bob, yes it is very complex. But you have achieved great things with this product and I know that you will continue to achieve greater things with it as the product continues to mature. I also know that this is a great labor of love for you and certainly quite a showpiece as to your abilities, particularly as compared to all the other products out there. But perhaps this is a time where an independent software consultant with expertise in Symetrical Multi-Processing (SMP) might be able to provide you with the help you need to cross over into the world of SMP with your product. If it's not really that difficult, then that's cool, but that's not what I'm hearing. As well, ignoring that dual cpus exist is not the solution either and that's what is being offered as a solution, to turn off the second cpu.

You have a great product. IMHO, finding some way to fix this bug rather than avoiding it will only make it greater.

Respectfully,

Lance

[Ian Alexander]

Lance,

I don't know anything about dual processors or graphics troubles, but here's another approach to having one machine with the horsepower to do everything at once. I decided a few years back to get a new dedicated computer for audio only and use the old one for everything else like email, this forum, and office stuff. The audio machine never goes online, so is far less likely to get a virus, spyware, etc. The machines are networked, so it's not completely immune, but you have to get those pesky mp3s out somehow. I picked up a little Raritan SwitchMan KVM switch and use one display, keyboard and mouse for both machines. Works very well.

[Bob L]

Lance,

All the programs you mentioned have no display problems possibly because they are not even close to having any display performance... they are very slow and kludgy and almost impossible to move around display wise... and take notice how their displays freeze and sputter and the cursor jumps and glitches while playing back a few tracks of audio...

Now look at SAWStudio... put up 20 or 30 tracks with all the eqs on and compressors and plugins patched... and then use the F-Keys to instantly completely redraw screens (something none of them can do) with not even a sputter on 20 meters being displayed in realtime with no latency... lets get serious.... its complicated because I have much higher display standards than most other apps... especially the ones you mention...

In order to obtain the display performance that SAWStudio does without glitching the audio engine running at low latencies... I had to bypass many Windows standard klunky routines and completely redesign how high power graphic bitmaps are processed... this is the source of some of these problems...

The problems happen because of many of the things I mentioned... its not just my problem to fix... but I am always finding ways to stabilize the code and I include these things with each update.

Little by little its getting extremely bug-free...

Duals are still a problem... simple as that... if you feel the dual is such a powerful advantage... at this time you will have to absorb some of the side effects... if you can follow my suggestion, then you can have a trouble free SAWStudio experience... right now... today... even without me having all the answers.... it becomes your choice... I wish everything was perfect... but its just not.

Also... many of the apps you mentioned need the dual to get even acceptable performance... SAWStudio will beat them all hands down with a single cpu.

So... a dual boot ini file is a very simple solution for you if you must go beyond the Force Single CPU option in SAWStudio... when you use Premeire... boot into dual... when you use SAWStudio boot into single... simple and you will not feel any loss in the SAWStudio environment.

Bob L

[Pedro Itriago]

I also do as Ian does. I placed my old system to be the internet/other stuff machine (it's a dual system, but until I come along into making some hardware modifications to the motherboard, I'm using it as single cpu). This one is also dual boot to 2 differents os's. This machine is still able to use saw or video editing, so if I need to do 2 things, i can switch between them (god bless gigabit networking, 10 gigabit anyone?). My setup is dual monitor as well & am using a kvm to switch one of the monitors between the main audio machine (hyperthreading activated btw) and my old machine.

I agree with you that the hyperthreading/dual core thing is only going to get ubiquitous, but so far, I have no problems dealing with them as long as I get some tweaks made on my systems, but that has been the nomr no matter what software you use since even with single cpu mobo's & windows 3.1 (at least as I can remember regarding audio & video editing)

[Lance]

Bob, Pedro, Ian,

First, I do use the workarounds. I'm a real diode head from way back and can always get things to work. I'm surrounded by more computers than I know what to do with (my company manufactures an IP based settop box). So that's not really the issue...

All I'm saying is that over the next year or so, given the complexity of working with dual cpus and Hyperthreading, and given the length of time that I know it takes to research and develop around complex technology, hardware or software, unless the problem with dual cpus and hyperthreading is directly acknowledged and a path mapped to effectively work bug free in such an environment, every other application that right now suffers all the problems and glitches expressed earlier, will have all the cpu power they need to effectively come close to what saw does now, as fast, and as well.

If Saw could take full advantage of what is upcoming with multi-cpu technology, imagine what it would be like? SawStudio on steroids!

I've already hit the ceiling on the number of VSTis I can have playing simultaneously with MWS. Sure I can bounce, but I prefer the flexibility of editing at will. This is one reason I got the Creamware card, and now I feel that I could use another batch of DSPs for that! CPU power is seductive, the more you have, the more you want.

What could dual cpu/HT provide us? Rewire support, live real-time notation, networked score support, multiple convolution reverbs, realtime audio to midi conversion, more than 5 VSTis operating simultaneously, but the real killer would be Video Workshop, Midi Workshop and SawStudio all operating as a unified environment with all of the aforementioned additions. Effectively, this would be what Lucas and Industrial Light and Magic have been trying to do with Droidworks for years. It is also why Yamaha bought Steinberg.

Everyone else is playing catch-up at this point. SS is clearly a superior product. That's why we're all here singing its praises to every Saw newbie that hits this board.

The potential is enormous. But that potential is simply not going to be realized on one CPU.

Lance

[AudioAstronomer]

The potential is enormous. But that potential is simply not going to be realized on one CPU.


I must respectfully disagree. The future will be on a single multicore cpu ;)

[Lance]

I must respectfully disagree. The future will be on a single multicore cpu ;)
:D I stand corrected. You are absolutely right.

I meant that...really I did... hahaha:o

Lance

[SoundSuite]

Lance,

From one of your earlier posts...
"they generally occur during playback when I drag a DSP-FX module"

I've been using dual-cpu or HT cpu's since the celeron 333's that clocked to 550....with SAW products, now SAWStudio.

The only issue I have personally ever had, after following Bob's tweaks, was with a plugins being the cause of display hitching.
Sonoris, which was fixed, and DSP-FX which I threw in the trash years ago.
(a few other freebie VSTs I tried and removed too)

Again, the only issues I have truly had were plugin related.
If it only happens when using the DSP-FX, get them to fix it, or stop using it.
There are plenty of other plugins out there.


To continue with the rest of the story:
In 'everything' else I do, multiple cpu's help performance...
In SAW, single is faster more than often.
Maybe the other apps 'need' multiple cpu's to hang, maybe SAW needs one to hang...Either way, there are many things that SAW does against the norm, do not fight them, embrace them.
It's not that SAW does not support fully SMP, it's that SAW does what the other guys cannot only using one cpu, so there is no 'need'.

VSTi's are memory/cpu hungry beasts, I dare say if you were currently using a quad xeon board and 2x creamware cards you'd still choke it using these kludgy beasts.
Until a good virtual instrument format comes out, and/or people code good code for the format, we're stuck with Steinberg's backwards thinking and will NEVER have enough cpu or RAM.
VSTi's loading down an app is not a fault of the app.


"The potential is enormous. But that potential is simply not going to be realized on one CPU."
That's why they make the creamware, uad, TCcore, etc. :)

[Leadfoot]

will NEVER have enough cpu or RAM.
VSTi's loading down an app is not a fault of the app. You said alot with that one. No matter how much cpu we get, the more we'll eat up. And you're right, loading an app down with vst's is not the fault of the app. Whatever the future brings, the history of Saw and it's creator shows that it will always be taken care of, and in the best possible way. And btw, I've never had anything but blazing fast screen draws in Sawtudio. In fact faster than any app I've ever seen, which is amazing considering what's going on under the hood.

Tony

[Lance]

Lance,

From one of your earlier posts...
"they generally occur during playback when I drag a DSP-FX module"

I've been using dual-cpu or HT cpu's since the celeron 333's that clocked to 550....with SAW products, now SAWStudio.

The only issue I have personally ever had, after following Bob's tweaks, was with a plugins being the cause of display hitching.
Sonoris, which was fixed, and DSP-FX which I threw in the trash years ago.
(a few other freebie VSTs I tried and removed too)

Again, the only issues I have truly had were plugin related.
If it only happens when using the DSP-FX, get them to fix it, or stop using it.
There are plenty of other plugins out there.You're right. I'll probably stop using it when I get the Anwida plugs. But for now, I like the way it sounds and it's very stingy with the cpu.



To continue with the rest of the story:
In 'everything' else I do, multiple cpu's help performance...
In SAW, single is faster more than often.
Maybe the other apps 'need' multiple cpu's to hang, maybe SAW needs one to hang...Either way, there are many things that SAW does against the norm, do not fight them, embrace them.
It's not that SAW does not support fully SMP, it's that SAW does what the other guys cannot only using one cpu, so there is no 'need'.I've been using Saw products for over 12 years so I think that I've gotten beyond the "embrace them" part of the equation. ;) First used the original Saw on a 386 with a CardD so I know the migration path. Short of the full SawStudio, I own all of Bob's products from the beginning of IQS. I've bought on big time.

However, I would beg to differ about the no 'need' part...it has already been said many times that Rewire Support would tax the system, as does Convolution Reverb. There's also the issue of multiple VSTis. Hey, I'd never try to run MWS and VSTis in a 386 environment... imagine what SawStudio could do in an 8Ghz system?



VSTi's are memory/cpu hungry beasts, I dare say if you were currently using a quad xeon board and 2x creamware cards you'd still choke it using these kludgy beasts.
Until a good virtual instrument format comes out, and/or people code good code for the format, we're stuck with Steinberg's backwards thinking and will NEVER have enough cpu or RAM.
VSTi's loading down an app is not a fault of the app.Unfortunately, plugins are a way of life, and not all are going to be efficient. Some are by their own process, not efficient, like convolution reverbs, modellers, and streaming samplers. All bias and emotion aside, while kludgy, they do work for the time being, and it IS a point of fact that the more cpu speed, the more of these kludgy beasts you can run.

While it is not the fault of the app, the app by function is the host for all the plugs. If the host doesn't run well in a multi-cpu/core environment, then the use of plugs will have limitations. Bob has already indicated that "there are possible loopholes in my plugins that were discovered while we were debugging Pieter's last Compressor plugin.

The problems only seemed to ocurr on dual cpu systems... and then only on certain motherboards and under certain exacting conditions." I am not faulting him for this. SawStudio is remarkably bug free for all its complexities. I'm just hoping that there is an intent to bring SawStudio into compatibility with a multi-processor environment as opposed to just using a workaround by shutting off "half the cylinders".

Within the next 6-12 months, cpus will move towards dual core. The Intel and AMD lines will cap at about 4Ghz. All they will do from that point forward, is add more cores to the die so you will have one "chip" with 2 or more cores that for all intents and purposes, look like multiple CPUs to the OS. If SawStudio doesn't get a handle on working in a multiple CPU environment, then from here forward, all you will be able to work with is a 4Ghz system. The rest of the world will be working with 8, 16 or more Ghz worth of processing. Chances are that you will have a system where all your other software can work using multi-processors, but you have to turn off "half your cylinders" to do Audio.

In 2+ years, the effect will be the same as if I told you that you "have" to work on a 386 in Windows 3.1 today.:eek:



"The potential is enormous. But that potential is simply not going to be realized on one CPU."
That's why they make the creamware, uad, TCcore, etc. :)Sure, but I like Bob's philosophy of doing everything Native. If that were a possibility, I would be using an RME interface today and not Creamware.:)

Lance

[SoundSuite]

imagine what SawStudio could do in an 8Ghz system?

I thought we were supposed to keep pornographic material off these forums ;)






The rest of the world will be working with 8, 16 or more Ghz worth of processing. Chances are that you will have a system where all your other software can work using multi-processors, but you have to turn off "half your cylinders" to do Audio.
I agree more is better, believe me.

Let's clarify though, you are not turning off half your cylinders, per se when referencing HyperThreaded cpus.
Instead of running two 'virtual' cpus at 1200MHz, you are running one 'literal' at 2400MHz when HT is disabled.

(in your case, you'd have 1x at 2400 vs 4x at 1200, assuming dual 2.4G Xeons with HT on both)

As far as running two literal cpus, you are absolutley correct, this would not be 'good' to limit to one only, but HT cpus are not 'bad' to run in single mode.
The HT users do not get hurt from disabling HT via the onecpu option.

True dual systems are cutting half, like you describe.
If removing the troublesome plugins doesn't work, and none of the tweaks work, I truly feel your misery.
You are right, you 'should' be able to (ab)use this power.

[Lance]

Yeah...just call me a power abuser!! And I want more!!:D

Seriously, now that I've got MWS/VSTis going, I've eliminated stacks of hardware synths that I used to Midi Sequence with... I never got the same feeling of replacing my Hardware Synth Studio using Sonar. I feel totally productive at a moments notice, whenever the creative urge hits me. Nothing like technology to get in the way of inspiration.
Lance

[Naturally Digital]

The Force Single cpu option keeps all SAWStudio processes on one cpu... but as I have stated in other posts, drivers and plugin dlls can still be split between the cpus randomly... thousands of variables are being updated per ms and if every possible variable is not protected properly from two different routines processing at the exact same instant... BOOOMMM... this is a much harder process to tame when 2 cpus are trying to access the same memory and hardware buses and video drivers and display hardware all at the same time. :)

This is still not the same as using the /ONECPU option on the boot.

Bob LHi Guys,

Well, I *finally* gave this Force Single cpu option (in SAWStudio) a workout last night. (I'm sorry... I'm a Taurus AND I'm Dutch! :eek: What can I say? Stubborn as a mule) I run dual cpus and continue to enjoy what dualies have to offer (for my needs anyway).

The important thing here is to *listen* to what Bob is saying... The problem isn't SAWStudio... it's Windoze, 3rd party drivers etc. I've seen these same display anomolies here. Who's to say that the drivers for the latest ATI card are dual aware? Anyway, I'm running a couple of older matrox cards and I get frozen windows in SAWStudio and the like from time to time. I'm in the process of getting a new machine going with nvidia cards... I'll report back if it is better (I'm running dual Athlons).

OK. I tested the stability by running two instances of SAWStudio on one machine... (with 512mb ram) with 4x1024, 8 track edl, when I tried to playback on the second instance (while the first was already playing the same edl) I got a buffer underrun. I then checked the Force Single cpu option and hit play... bam! played without issue. Now, as you pobably know, running two instances on a 3-monitor setup, I was just asking for video glitches... The whole thing was significantly improved with Force single cpu. Not perfect, but much better.

At first I resisted this concept because I wanted to take full advantage of my dual system. However, as Bob has mentioned, this doesn't affect what Windoze does... only keeps SAWStudio running on a single cpu instead of dividing up threads all willy-nilly. This makes sense to me.

Keep in mind that Windoze will still run other processes on the second cpu and you will *still* get a benefit in terms of user interface etc. One of the main reasons I still like dual systems is that the user interface remains snappy, even under heavy loads. This is very important to me.

So, Lance... please don't feel shortchanged. Try the option out and see if you experience less glitches. You may be glad you did. If the glitches don't go away, perhaps try another video card.

Balancing the plugin load between the two cpus is another issue... That's up to Bob. Personally, I don't assemble dual cpu systems in an effort to get *twice* the plugin power. I have other reasons such as those mentioned above. Having said that, yes, there are ways to do it. The latest Mixtreme mixer v4.2 does a fabulous job of load balanceing VST plugins on both cpus.

I would suggest looking for innovative ways to make use of your dual system while working within the strengths (or supposed shortcomings) of SAWStudio. Consider running two instances of the software and finding a routing solution that lets you divide up the VSTi's somehow. At the end of my testing last eve I actually had both instances running on the second cpu (even with the force single option set). Anyway, this isn't going to help others much but I only mention it to illustrate one example. The point is, that it's all up to your imagination!

I'm still continually amazed at how stable SAWStudio is and I'm thankful that Bob offers these *options* in the software. Two instances, playing back the same edl... c'mon... I'd like to see those other apps do that!!!

Try to keep an open mind and put your thinking cap on... You may be surprised what you come up with. ;)

Listen well,
Dualie Dave.

[Naturally Digital]

BTW: Let's not forget the TCP/IP Host/Slave mode... Haven't even scratched the surface on that one yet!

[Lance]

BTW: Let's not forget the TCP/IP Host/Slave mode... Haven't even scratched the surface on that one yet!
Yes, this is very intriguing.