How do you define "defective product"?

Comments

Kit wrote on 5/12/2014, 6:26 PM
If I own a "product" that depends upon other "products" to function properly, and two "products" don't work together, which one is at fault?

If you have bought one product after being assured that it will work with the other then that seller is at fault. Basic fitness for use concept and not much philosophy required.

If companies deliberately do lie they should be heavily fined with perhaps penalties in part coming out of the personal pockets of management. Just a thought.
Kit wrote on 5/12/2014, 6:31 PM
I don't completely buy the argument about near-infinite variety of hardware and OS. There are no where near infinite relevant combinations. Software like Vegas is written for one specific type of OS - Windows 64 bit. But I do agree being in software development is a headache.
richard-amirault wrote on 5/12/2014, 6:39 PM
people forget that some of us are old enough to remember when software was tested first, then delivered without bugs. YES, it DID happen.

Back then computers were *much* simpler ... with fewer operating systems ... fewer drivers ... fewer additional programs (without who knows what kind of programming) ... fewer accessories.

Today it is impossible to fully test a program on every possible computer that it might be run on.
wwjd wrote on 5/12/2014, 6:44 PM
wow this thread grew more legs than I was expecting! :D
larry-peter wrote on 5/13/2014, 9:46 AM
@ kit,
I'll take back my inaccurate statement. No finite number is "near-infinite." But possible configurations begin with (64 bit capable CPUs) X (compatible motherboards) X (possible memory configurations - brands and amounts) X (available GPUs) X (available drivers for each GPU) X (possible combinations of Windows updates selected to be installed by a user). That's before we get into memory timings, codecs, other software, additional cards.

It's obvious this thread is about Vegas, but my comments were generalities to all software. I don't believe there is necessarily wrong information being given, just not enough, in my opinion. With SCS's claims about what the software can do, and our expectations of what it should do, I think SCS should give tighter specs on the environment it needs to meet these expectations, and we should accept the possibility that it might not perform well in our existing HW/SW environment.

I only see "requirements" and "recommendations" on the tech specs page. I can't find any "assurances" listed. Unless they build our system for us and we don't touch the configuration, I doubt that any assurances are possible. I'd simply like to see the configurations in detail that it was successfully tested on - down to CPUs/motherboards, GPU/drivers, neighboring software and memory timings.

I do believe users share responsibility with programmers in making any software work properly, and more information makes a better experience for everyone. Marketing obviously wants to expand the potential user base as wide as possible, but my experience over 25 years has taught me - build the system for the software you're going to use. NLE software companies used to give us a lot of very detailed help in that department.

It seems VP13 has made good strides in stability, but some users will have issues. Until Vegas becomes fool-proof on every computer running a Win x64 OS, (not holding my breath for that for any software of this complexity) they could provide the information to allow users to do what needs to be done on our end to make things better.
Former user wrote on 5/13/2014, 11:53 AM
Vegas was always a strong NLE because it was pretty hardware agnostic. It did not rely upon specific video cards or processors or memory.

But people kept demanding that it utilize GPUs for faster rendering. Now they have done that and people complain that it doesn't work on every GPU available.

If you look at the history of other NLEs, they all required specific hardware/drivers AND software even down to specific versions of quicktime and OS builds. This is the only way you can be sure that software will perform as designed, and even this was iffy at times.

Sometimes a seemingly benign piece of software can cause a problem when not even related to the NLE software just because it was written poorly.