Subject:SF8 GUI is much slower than SF7

Posted by: Sound Samurai

Date:4/6/2005 6:00:45 AM

Hello,

Soundforge 8 is much more slow to work in than SF7. Zooming, dragging, redrawing, it feels sluggish. The response of dialogs and and popups are not instant like before, but they have a very noticable delay.

It feels like SF8 is using a different "framework" underneath than previous versions? Has anybody else noticed this, or is it only specific to my system (and if, what could be wrong?).

I think the speed and featureset of Soundforge is fundamental to its popularity, and a reason alot of people working on Mac keeps a PC for running Soundforge (me included).

I run on Windows 2000 with latest SP/drivers/updates.

Subject:RE: SF8 GUI is much slower than SF7

Reply by: Vocalpoint

Date:4/6/2005 10:36:10 AM

It definitely uses the .Net framework for some stuff...which is a slow-ass dog at the best of times....

I definitely agree tho - V6 and V7 had a nice snap to them...whereas V8 is pokey...feels sorta tired and heavy is the best I can describe it.

This also is quite common as today's dev teams usually work on cutting edge boxes with high-end everything...hence - not a lot of interface lag from their prospective...but when it get passed to the end user with a 14 month old box that he/she was once proud of to run V6 or V7...the result is less than desirable...

And so it goes....

Subject:RE: SF8 GUI is much slower than SF7

Reply by: Ben 

Date:4/6/2005 12:35:20 PM

I also agree - SF 8 feels extremely sluggish. Cursor is jerky and the GUI is a lot slower than it was, and we're not talking about the speed of processing.

The nice thing about Forge was that is always felt very snappy - the most worrying thing as far as I'm concerned is that playback itself now feels unresponsive. In all other versions (I've been using SF since version 4), from hitting space to the audio playing was pretty much instantanious. Now there's a noticable, if short, delay. This seems to happen whatever driver model you choose and makes using SF 8 pretty unenjoyable for me.

Funnily enough Vocalpoint, I'm using SF 8 on a brand spanking new Athlon 64 3500+ and it still feels sluggish as hell. I remember using early versions of Forge with a Pentium 2 or whatever and they always felt much more responsive than this. Don't think it's got anything to do with our gear - it's the code!

I've gotta wonder what the hell beta testers did actually test. Did they find the vast multitude of bugs? No. Did they realise that SF 8's GUI feels very slow? No. Did they just get off on the fact that they were beta testing software and not really do their job? Probably.

The sluggish GUI is an issue which really needs addressing, Sony.

Ben

Subject:RE: SF8 GUI is much slower than SF7

Reply by: Rednroll

Date:4/6/2005 10:06:50 PM

Ben, I was one of the beta testers for SF8.
To answer your questions, although I noted they're sarcastic.

"Did they find the vast multitude of bugs?"
Yes, many bugs where found in SF 8.0 before it's release, I reported quite a few myself. Did I find all of them? No, probably not. Sound Forge has a multitude of features, not all of us use every feature in Sound Forge, and we don't use that feature in the same manor that someone might find the correct steps in reproducing a bug.

"Did they realise that SF 8's GUI feels very slow?"
Yes, I did. I have Forge installed on 2 PC's, one of them is on a laptop with Win2k the other my Desktop PC with WinXP. The first thing I reported is that SF8 seemed to be slugish and unresponsive on my laptop machine, compared to running SF7 on the same machine for the first beta release I tested. I'm not sure of the reasons why, but it was definately brought up. It was improved from that time when I mentioned it. Sound Forge 8.0's audio engine has been completely revised and supposedly improved over SF7. I mentioned maybe, that is the cause, but I don't know for sure.


"Did they just get off on the fact that they were beta testing software and not really do their job?"
It's a job? That's good to know, because just so you know, none of the beta testers gets paid a dime for spending their own time, testing the betas in their normal workflow and then documenting repro steps and bug reports, and then feeding the information back to Sony.

Obviously, you think you can do a better being a beta tester. I've found a good way to get invited to being a beta tester is to come to these forums and reporting bugs, and then giving step by step repros, so Sony can try those steps and reproduce it. If a bug can be reproduced......it can be fixed. The first part has to come before the second part though. I haven't seen you report any bugs for SF8, and I haven't seen you post any repro steps. I suggest you try giving that a shot, and you may find yourself with an invite in your mail box, because Sony can really use that kind of feedback within a beta tester. Then you can come show the other beta testers how it's REALLY done. The grass is always greener on the other side of the fence as they say.

All the bugs I've seen so far have been minor bugs which have minor work arounds, and are just an annoyance at best. Again though, if you find one and explain how to reproduce the bug, chances are Sony can then reproduce it and it will get fixed in an update.

Oh, and by the way a beta testers free work load is never done, I'm still reporting bugs as I find them to the Sony folks.

Thanks for your encouraging support,
Red

Subject:RE: SF8 GUI is much slower than SF7

Reply by: kryten

Date:4/6/2005 11:30:25 PM

I agree with Red, however, in the old days, SF used to have public betas. I think thru that program, a lot more users reported a lot more bugs before the product went gold, resulting in a lot less bugs when it was finally released. I wish Sony would re-adopt this attitude. I don't remember seeing so many bug reports with any new Sony release since the public betas quit happening. Just my 2 cents.

Subject:RE: SF8 GUI is much slower than SF7

Reply by: Vocalpoint

Date:4/7/2005 7:34:48 AM

"I don't remember seeing so many bug reports with any new Sony release since the public betas quit happening."

Gotta agree on this. I would public beta test with no problem. As it stands tho - it feels like a lot of us are "public beta testing" this thing now after whipping out out credit cards for the privilege...

VP

Subject:RE: SF8 GUI is much slower than SF7

Reply by: Rednroll

Date:4/7/2005 8:54:35 AM

I agree a public beta would help in finding a lot of bugs. The problem with this is that it creates a lot of noise that the developers have to sift through. Use this forum for example, you see people posting bug reports in frustration in here all the time. I read them regularly and try to reproduce the bug on my system, that way I can confirm it and send an email to Sony, stating the steps on how to reproduce it. The majority of posts reporting bugs never give any steps as to what they where doing to create the bug to happen. I can understand that scenario, because a lot of people are in the middle of doing a project where they need to get something done, and don't have the time to stop and figure out exactly what they where doing to reproduce that bug. This has happened to me in the past, and I try to find a work around either by going back to the previous version and completing the job, or trying a different method to achieve the same results. Then later when I have more time I will try to go back and try to reproduce what I was doing, to see if I can make the bug appear, and I will document the exact steps that I found and feed that back to Sony, so they can reproduce it and work on a fix. Now imagine if you where Sony and 90% of the feedback you received didn't help you in fixing the bug. You would be aware there was some kind of bug, and you would spend a lot of time aimlessly walking around in the dark trying to reproduce SOMETHING. It's not a very effecient process for a software developer.

Although, I agree a public beta could be beneficial, but in a sence they are offering everyone a public beta. When they release the software, they normally release a 30 day full functional demo. Thus, if you want to have a public beta, you have one for 30 days and it doesn't cost you a thing. How many of you take advantage of that before pulling out the credit card? If you don't do that, then I think you're making an unwise decision, because to me that's like purchasing a car without even test driving it first.

Maybe a public beta could be beneficial, but it would take some managing on Sony's side. They would need to create a form to fill out, where you HAVE to fill out your system specs, and you have to fill out the steps it took to reproduce the bug. If you didn't fill out the required information, then your report would be ignored, so they could better filter out the noise and spend more time focusing in on the reports that have the required information. How many would be interesting in doing that?

Yesterday, I was in the middle of a project working in Vegas v5.0d. It was a time critical project that needed to be done. The bug I ran into was driving me nuts. I couldn't do a simple task, which was to render my project to a .WAV file. I was going to go back to v4.0 so I could get the project completed. I ended up figuring out a work around and the steps it took to reproduce it, which just happened to be related to MY system setup. It ticked me off tremendously, because it took me an extra 2 hours out of my workflow on a time critical project. Well, I fed the information back to Sony and the exact scenario that caused the bug. I got no reply, probably because they're all working on Vegas 6.0 right now. I highly doubt it's going to get fixed in Vegas 5.0 and in my opinion this is a major bug, but at least I have a hope that it won't be in Vegas 6.0, since they have the steps to try and reproduce it. I guess, I'll be downloading the demo version of Vegas 6, when it's released to be sure, before I invest any money. For the time being I'm going to try going back to v5.0c or use a work around like I did yesterday, because I know I hadn't seen this in earlier versions.

Subject:RE: SF8 GUI is much slower than SF7

Reply by: Vocalpoint

Date:4/7/2005 12:27:09 PM

"Thus, if you want to have a public beta, you have one for 30 days and it doesn't cost you a thing. How many of you take advantage of that before pulling out the credit card? If you don't do that, then I think you're making an unwise decision, because to me that's like purchasing a car without even test driving it first."

Red,

Agreed. However - once those 30 days are up...and the product is still not working up to par - time runs out...the demo is over and quite frankly - I don't really get a warm and fuzzy about investing my coin in the item anymore, ya know?

The point here is - when Sony makes a huge announcement about a new killer version of one of their flagship products and offers me a reasonable upgrade path - I understandably get kinda excited, start making budget plans and really want to "purchase" the product with a feeling that the quality level I expect from the product is all ready to go and I can get right to work with my new purchase. After all - they spent 12-15 months working on this - right?

I (and probably many others) simply don't care about a 30 day timed public beta, if you will. To be completely honest - I reallly wanted to re-join the SF family and make 8.0 my goto app....but about 7 or 8 days into the trial - I got frustrated with all the workarounds and promised fixes and just went back to Wavelab to so I get my work done. Say what you will about WL - it REALLY works well for me and my clients could care less what editor I am using to deliver their stuff.

Like stated I am willing to do what it takes to help get the product ship-shape way BEFORE the big announcement. This release had very high hopes and judging by the responses on these forum...Sony may have blown it by not getting V8 polished enough for prime time.

A public beta may have helped fish out a bunch of stuff before hand...and perhaps made the launch a little more significant.

As it stands now - you have a pile of devoted users waiting on a boatload of fixes with a bad taste in the mouth about purchasing a faulty product. Many of them reaching for their V7 installs as fast as they can to get some semblance of quality back on the desktop.

VP

Subject:RE: SF8 GUI is much slower than SF7

Reply by: Rednroll

Date:4/7/2005 3:12:13 PM

I almost totally agree with you. One point I don't agree with is that the latest release of Wavelab shipped with many bugs also where you saw a lot of users screaming. Sound Forge is on it's first release, things will get addressed in an update, just like they did for Wavelab and you'll be using a solid release. I think it's one of those things that us as users come to expect bugs upon the first release and we need to be prepared to deal with them. Once everyone has had a chance to find everything and things get fixed, we'll all be happy once again. Now in my Vegas bug that I recently found, this seems to be one that snuck in there on me for one of those updates. It probably will never get fixed because Vegas 6 is the focus of attention. Now that upsets me, when something that I consider to be a major bug, will never get fixed and effects my workflow. With Sound Forge 8.0, it's still in it's juvenille stage, and has some updates to go, so be happy with that. I understand the frustrations of having to deal with them in the meantime.....after all I just lived it yesterday with Vegas.

Subject:RE: SF8 GUI is much slower than SF7

Reply by: Sound Samurai

Date:4/7/2005 3:25:43 PM

Thanks for writing, I understand I am not the only one. And as someone mentioned, processing is by no means slower, it is just the GUI and dialogs.

Its really irritating because I keep doing wrong things because I now work faster than the GUI.

One reason I have always enjoyed PCs over Macs is the SPEED at which one could work. Logic and OSX is very very pretty and nice but OH so slow. And now Soundforge manages to attain the same problem.

Good bye Soundforge.

Subject:RE: SF8 GUI is much slower than SF7

Reply by: jorgensen

Date:4/11/2005 1:06:14 AM

I find it strange Sony has chosen to use .NET for an application, where promptness is such an important feature.

.NET is a-kind-of Java layer that improves portability, but slows down things considerable.

Likely, the only way to improve the speed is not to use .NET, and therefore have to start all over from version 7. Interesting to see what Sony will choose.

There is a beta version of .NET, but I doubt it will provide the needed improvements.

Subject:RE: SF8 GUI is much slower than SF7

Reply by: Ben 

Date:4/16/2005 4:24:28 PM

Red - no need to jump down my throat! We go way back on these forums and I don't want to pick a fight with you ;)

The sarcastic comments about beta testers were more meant to be tongue-in-cheek, and certainly weren't supposed to be personal attacks on anyone! More than anything I guess was just relaying my frustration with this release.

What's probably most shocking is that somewhere along the line it seems no one at Sony said: "Hang on, Forge 8 is way slower to work with than it used to be, and we seem to have broken lots of the existing features. We'd better get all this stuff fixed before we even think about passing it to beta testers, let alone releasing it to our professional users".

And I still have to say it <is> weird that none of the beta testers noticed any of this stuff, particularly the "slow motion" GUI. Unless of course they did notice it, Sony was told and bizarrely chose to do nothing. Whatever the case, SF 8 just feels like a huge and strange step backwards to me.

FWIW, I'd theoretically love to do help with beta testing, but not sure I could commit enough time to it.

Ben

Subject:RE: SF8 GUI is much slower than SF7

Reply by: Rednroll

Date:4/18/2005 5:24:43 PM

Ok Ben, no foul. I just take it a bit personal when I do beta test, because I try my hardest to find as much as I can.

As I mentioned previously I did bring this up. It seems to have improved since I brought it up though. One thing I notice is that on one PC I'm running it on ,which is a laptop with Win2k and only 256meg of RAM, on that machine it seems slugish to me. I also have it installed on another PC with WinXP Pro with 1.2Gig of RAM and on that machine it doesn't feel slugish to me, so I'm assuming it might be system specific. What are your system specs?

Subject:RE: SF8 GUI is much slower than SF7

Reply by: Ben 

Date:4/18/2005 6:06:32 PM

Just added my system specs to my profile. Pretty damn fast - just built a new machine. Running great in everything but SF 8!

Maybe sluggish isn't the best word then, unresponsive perhaps... doesn't feel as 'solid' as it did. As I said, the lack of instanteous play when I hit space is the thing I find most disturbing - compared with every other Forge versions.

Subject:RE: SF8 GUI is much slower than SF7

Reply by: Rednroll

Date:4/18/2005 9:54:19 PM

yeah, that's actually exactly what I observed on my laptop, when I pointed it out. So I do believe your statements are correct, I just haven't been able to figure out why it hesitates on that machine and SF7 doesn't, but then on my other machine it doesn't hesitate for SF7 or SF8. I even reformated my laptop and reinstalled the OS and it still seems hesitant like you describe. It did improve from the first betas like I mentioned, but chalked it up to being due to running an updated version on an older slower machine. So of course as software expands, I expect it to start to run slower as previous versions. Your system shouldn't have anything holding it back though.

Subject:RE: SF8 GUI is much slower than SF7

Reply by: _TJ

Date:4/22/2005 8:41:37 PM

Sound Forge 8.0 doesn't use .NET for anything other than scripting. Starting up the script support does impact that launch time a bit, but other than that, any slowness you are seeing is not .NET. it's something else.

tj

Subject:RE: SF8 GUI is much slower than SF7

Reply by: Andreas S.

Date:4/22/2005 10:04:28 PM

My first project with SF8 was an 8 minute voice over track. Scrolling was slow, dialogs seemed slower; the same things others are noticing.

It was recorded in studio: stereo interview setup. Couldn't convert the channels properly (bug / undocumented change/feature).

Okay, so it's not .NET, but then what's the result of the sluggishness? On a 2.5GHz box with 2GB of RAM running JUST SF8...and it burps and farts its way to...other assorted problems.

Like so many others I've switched back to SF7 to keep the workflow...working.

(and I really hate the interface of Audition 1.5, with 2 weeks left in the demo, I'm not sure what to do).

Subject:RE: SF8 GUI is much slower than SF7

Reply by: jorgensen

Date:4/23/2005 1:09:43 AM

If it is not NET, what is it then - got curious, and installed SF8 to check it out on a super fast computer.

Couldn’t find any change in the normal screen operation from SF7, and the Task Manager/TaskInfo didn’t show extensive load on the CPU. Only the Plug-in chainer seems to load a little slower.

If the screen interface feels slow, I would try to disable all the Windows screen effect, and disable 'Enable Windows XP Theme support' in Preference.

However, it is correct that working on the wave, there is a small noticeable delay compared to SF7 when starting on something.

Looked extensively for the ‘Preload buffer setting’, and it wasn’t there. Tried in internal and only found some preview setting, that didn’t make sense to me. Finally I found the ‘Playback buffering’ in the Audio tab, and played with it.

Bingo I – I manage to have SF8 respond faster than SF7, by change it from 0.1 (100mS) to 0.04 (40mS). Below that point, the sound got distorted, so 0.04 is the limit on my computer.

Bingo II – I have started using mouse-clicking to jump around the wave while in playback mode. This is possible by selecting ‘Loop Playback’ in the Transport. In SF7 the cursor went off the wave window without scrolling, but with SF8 the scrolling is there. And the response was faster than SF7 with the 0.04 setting.

Using the audio controls in the process/effect and some plug-in dialogs has a much longer response time than SF7 in the preview mode – haven’t figured out if it can be changes by a preference setting. I find this to be a major disadvantage when compared to SF7.

The so-called Scrub control, is somewhat strange, but holding down the Ctrl key while dragging improves the ‘scrubbing’ somewhat. But I get a lot of annoying noise/distortion at some speeds, and using the mouse wheel for ‘scrubbing’ doesn’t work for me.

Having default monitoring on recording, is a big mistake – and the selection is not in the recording window.

Note:
It seems like the ‘Playback buffering’ is a fixed preload buffer setting, and by making it small, there is a risk for dropouts – and obvious distortion. The buffering should definitely be dynamic, by starting with a small amount for fast response, and then increase while playback to avoid dropout/distortion.
In the Audio tab there is a sub dialog for Advanced settings, and maybe some of these settings can avoid possible droupout. Havn't yet figured out what all these are for.

Have later found out, that there is a problem with the 0.04 setting for some plug-ins.

Subject:RE: SF8 GUI is much slower than SF7

Reply by: _TJ

Date:4/25/2005 10:48:50 PM

Also, there is a bug in 8.0 such that if you don't have the PlugIn explorer open, AND you have lots of plugins, we were repeatedly rebuilding the plugin list in case things had changed.

The constant rebuilding isn't visible except as a slowdown of the GUI in general.

So you may find that you get better GUI performance if you leave the PlugIn explorer window open.

This bug will be fixed in 8.0a

tj

Subject:RE: SF8 GUI is much slower than SF7

Reply by: kbruff

Date:4/26/2005 7:48:22 AM

Me either...

I have since returned to SF7, but I still use Wavelab. I like SF alot, but these issues are so annoying. Well I continue to wait it out, because I know that So-So-Fo has to fix these issues in order to remain strong in market where there is high need.

Dont get me wrong, I have every intention of being So-So-Fo user, I just need to keep working and not trying to figure out why something does not work.

-
Kevin