Faster! Faster!

Robin,

We've had this same discussion in a number of threads here, so I'm going to start by responding to you with one of my previous responses to you.

"Changing the hardware in the console isn't going to affect how frequently it crashes.

Changing the hardware on the console would be a *huge* undertaking. If you want hardware that can be installed into existing consoles then we would have to design a custom motherboard, which is an expensive and time consuming project.

All of the resources that would be dedicated to designing, developing, and testing this new hardware are resources that would no longer be available to work on other development projects, including improving the stability of the console."

That fairly well sums things up. The Wholehog 3 uses a custom motherboard. We would not be able to find a motherboard that could retrofit into existing consoles. We would have to design one. Designing a custom motherboard is a far larger project than you seem to understand. In addition to being possibly the most complex hardware component in the product line, it also requires much more firmware to be developed. You also seem convinced that this new hardware would somehow reduce crashing. Crashing is caused by problems within an application. That is currently where our efforts our focused. A new motherboard wouldn't cause us to crash less, it would just allow us to crash faster.

As we have *proven* with the development that has happened in the past 18 months, it is very possible for us to improve performance and stability with software changes to our application. This offers actual solutions to legitimate software bugs rather than throwing faster hardware at the problems and also gives us a solution that our users don't have to spend money to get.

You mention that we should sell this new motherboard for $1000. I have no idea how you've arrived at this number, but as I've mentioned above, I don't think you understand the costs involved in a project like this. Your $1000 price is far less than our current motherboards cost. Remember that we don't have the benefits of the economies of scale that a major PC motherboard manufacturer would have.

I'd like to close by quoting myself in another previous response to you.

"We are constantly working to improve the performance of the console in ways that will have the greatest impact for the majority of our user base, as you can tell by the recent views improvements. If we make hardware changes to the console, we will need to sit down and find the best way to make those improvements available to existing users. This decision will be affected by a number of factors, including cost, mechanical compatibility, and customer needs. I think you're putting the cart in front of the horse here. Keep in mind that we're all happiest when our users are happy and that's what we strive for, but we do need to make feasible business decisions that allow us to continue working to improve the product."

I belive I've "chewed on" everything you said. If my responses don't answer your questions, please feel free to ask for clarification.

Thanks.

Love it, Ok how about 1200 bucks to the cost of the mother of boards

Robin,

It seems that you're not understanding me, but I don't know how I can explain myself any better.

So, I'm going to paraphrase exactly what I've already said, yet again.

a) New hardware isn't going to improve software stability.

b) New hardware is going to take valuable development resources off of existing projects that will provide valuable benefits to the majority of our user base.

c) New hardware is going to be more expensive than you think, because we wouldn't be able to use an off-the-shelf motherboard if we want to be able to retrofit existing consoles. I'm not sure how much our current replacement motherboards cost. It might interest you to check with your local dealer and find out what the current boards cost and use that for perspective.

We all understand that you want a new motherboard. I've tried to explain why we feel that isn't the best use of our resources. As I mentioned before, our primary concern is getting the biggest functional, performance, and stability improvements as efficiently as possible for as much of our user base as possible. You'll have to believe me that we've put lots of time and effort into determining the best way to do this, because there isn't much else that can be said or re-said at this point.

I hope you understand.

Ok tom my old mate , I am see a grate strangenes when I use a macro to change page This is a very cue intence show 90 gobo changes fade one load one ok it like the timeing go's away for a bit it freaks me out then it comes back there is 600 cues in this show and many page changes and every time I change page timing is gone then it catches up what do you think of that.

Robin,

Please send me your show file via the uploader utility upload.highend.com and also send me an email with the detailed information (exact button presses) to reproduce the problem described above.

Also please clarify in the email what you mean when you say "the timeing go's away for a bit". Do you mean the cuelist window, the playback, the screen refresh, etc?

All problems are very important to us and we try to resolve everything in a timely manner. Often problems can only be reproduced with clear reports and show files. Once we reproduce a problem, then we can make headway into fixing it.

thank you for your understanding and continued support of our products,

[quote=teerickson]Kerry,
I'd be curious to hear what folks have to say now that we've released v2.1 with all of its views performance improvements.


I'm into my second show on the 2.1 version with the PC version. I think my only "complaint" is that it appears my CPU usage increases significantly when I have the Output View active.

Eric,

This is to be expected. The output window is driven almost entirely by feedback and this feedback must be prepared and collated for display when the output window is open.

We're currently working on changes that will reduce this impact.

Hi Tom,

I have some feed back for you regarding the updated Hog software that included performance enhancements. To review, we were talking about monitor resolution, color depth, and how available memory limitiations were affected by the current available technology at the time of motherboard design. I was reminded of this thread when I went to update my Hog from v.2.0 to 2.2. When I originally attempted the update I was unable to move from v2.0 to 2.2 because the Hog would not accept the new software. Long story short I had to go back to the original software that shipped with the console (v1.4 I think). With help from tech support, I eventually got v2.2 running.

Having delt with that, I was able to compare the performance speed more easily due to the short time between using both v1.4 and v2.2. Overall, it seems as though v2.2 runs at roughly the same speed as v1.4 with 2 noticable differences. First, and I noticed this on v2.0, there seems to be what I will call a 'floating flicker' on both internal and external monitors. Sorta kinda what CRT monitors look like in older movies where you could see the CRTs refreshing themselves. Not all monitors at the same time or not a whole monitor at once though. It seems to be a occuring at a random spot on a random monitor. It's annoying, but I have almost stopped noticing.

The second thing I have noticed is that is takes what seems to be forever to get to the Record Option window if I am writing over a Group, Scene or Cue. That's been somewhat more difficult to work with.

The other thing I'd like to add about v2.2 it that it seems to be good deal more stable. My Hog crashes less now. That's good times.

I hope this is useful.

Thanks,
Kerry

Kerry,

Thanks for the update. I'm definitely glad to hear that you're feeling like the console is more stable.

The v2.1 release had the most impact on console performance, as it included some *significant* changes to how we draw data on the screens. In most cases, and most specifically the output window, performance was significantly improved. There were a couple of areas, specifically the effects engine spreadsheet and the colour picker, that suffered a slight performance decrease, but we've improved these areas in releases since v2.1.

I'd like to know how you're gauging the console performance. There are two areas where I'd expect you to see improvements:

1) Refresh rates in the output window are consistently higher than they were previously. This is particularly noticable when running crossfades or effects.

2) When lots of windows are open that require constant redrawing based on feedback (output, cuelist, etc.), and there is lots of data, the responsiveness of the front panel and command line should be improved. In addition to making drawing to the screen more efficient, we've also basically limited it to a percentage of total CPU time so that there is always processing power available to handle user input.

Thanks.

Useing exturnal monitors still slows things down,
Tom

All,

As Tom said v2.1 marked a big change in views. We are continuing to improve the views, refresh, etc and elected to implement these changes in steps instead of waiting to add them all at once. Of the planned improvements in this area about 1/3 have been implemented. Our development team is continuing to rewrite much of this code and you will see over the course of the next few releases more and more improvements in this area.

In addition these improvements not only increase speed they allow for implementation of future GUI features and enhancments. So the work not only improves the current system, but opens avenues for newer functionalites to be added with much greater ease.

We understand the desire to have faster views and we are working to satisfy all the users needs as quickly as possible. Thank you all for your patience and understanding.

Tom,

Thanks for getting back. As far as how I am gauging performance here's what I can tell you...

I have 1 external 19" LCD monitor that runs natively at 1280x1024.

When patching (I forgot about this during my last post), I'm generally only looking at the patch window. I think I see the worst lag when patching. I usually have to wait for the console to catch up after pressing the '@' key and then have to wait again after pressing 'enter'. It gets really bad when patching 3 digit DMX addresses into 3 digit channel numbers.

When I'm programming, I am looking at the cuelist, output, programmer and group windows. That's certainly a heavy load as far as displays go but the funny thing is that if I add patching to this, there does not appear to be a disceranble increase (or decrease) in lag time.

In all instances I cannot tell if the console is slow to display changes or slow to execute the commands. I'll have to play around a but to find out if its one or the other.

Kerry

Robin,

Using external monitors will always have some degree of impact on performance because it's lots of additional pixels that need to be painted and usually means additional windows that we need to keep track of.

Kerry,

I don't believe that we made any changes specific to the patch window, but I'll let our test department know that you're feeling like this speed in this window is holding you and they can look into this report.

Thanks.

Hi there,

I just wanted to pick this thread up as the last post is probably my single biggest annoyance with my WH3 console to date. 4 years have passed since the above post and still when I hit Ch***@, there is about a 1 second delay in opening the patch window. On my iPC it is instant. Patching on the WH3 takes far too long, as I keep making errors because of entering in the information faster than the console can react.

Could this be looked at again please?

Cheers

Colin

Colin, maybe try running HogPC on another Windows CPU (something inexpensive like a netbook works great) and log your WH3 onto it as a client. I and others also find this is a VERY stable configuration for the network. And I think it's faster....not sure, though. (This thread is old, yes, subsequent builds of the WH3 have been much snappier. What version are you on?)