Greetings,
I'm a first time poster and I hope that this post is found to be constructive. I've used VE Pro at a friend's studio and just purchased the product through Sweetwater. I should have it for my home studio in the next few days. I think it is a great product, (obviously because I've purchased it) however there is one big hole. The EWQL Play engine is still not compatible with VEPro! I posted the following on the EWQL site earlier today. I am reposting it here because it applies to the VS team as much as it does the EWQL team. Just swap EWQL with VSL and Play with VEPro throughout the text!
Greetings to all EWQL team members who read this. Let me first say I am a big fan of your products.
In the spirit of trying to add value for both EWQL and its customers I would like to present to you the concept of COOPETITION and how it applies to the VEPro product.
I've been selling enterprise hardware solutions for over 17 years and one concept that you have to learn to be successful in this industry is coopetition. (You could spell it co-opetition too.) Basically, it means that you have to cooperate with your competition in order to succeed. For instance, in my sales world, IBM hates EMC. IBM has several storage products that compete directly with EMC. EMC hates IBM. They primarily sell disk that competes with IBM disk. Some customers want IBM disk, some want EMC, some want a mix. IBM and EMC have to cooperate to ensure that all of their respective hardware works flawlessly with their competitors. If they don't, they risk losing a sale. For instance, if a customer wants to use EMC storage, but the IBM Intel solution is not compatible with it, the customer could easily turn to HP for the Intel hardware. Take that, reverse it. Now you have coopetition.
Like I said before, if you don't play the coopetition game well, you will not survive in this industry, period. I think the same applies to the sample library industry. Currently, VEPro does not work well with Play. VSL says it's EWQL's fault, EWQL says its VSL's fault. Frankly, as customers we don't give a flying rat's butt who's fault it is. We just want it fixed!
EWQL currently is viewed by many to be the uncooperative party in this situation. I have no idea if it is true or not, but it doesn't really matter. It just needs to be fixed.
It might be that EWQL does not want to cooperate (if they aren't) because they view VEPro as a direct competitor to Play Pro. At least for audio networking they are. However, coopetition should be your motivator to fix the incompatibility between VEPro and Play. Will you lose sales over it? Maybe. Many? I would not think so. Here's why. First, how many people are actually going to purchase Play Pro? I am betting it is less than half of your clients. I could be wrong, but I'm thinking that is a fair guess. Second, how many people will need other features in Play Pro other than the audio networking piece and therefore will purchase Play Pro whether they have VSL Pro or not? I know I will.
My point is this. It is never, ever good to limit options for your customers. Coopetition is a method to keep them happy and keep a positive light on EWQL. Refusing to cooperate with VSL does nothing but put a stain on EWQL. Second, the revenue impact cannot possibly be that big. The vast lions share (currently the entire) of revenue for EWQL is from libraries. Obviously, EWQL is not going to see a 10% surge in revenue due to Play Pro. I'll guess again that it won't even be a 5% increase. So, what is there to lose?
Listen to your customers, guys and gals. We want / need VEPro compatibility with Play. Currently you have nothing to offer and who knows when Play Pro will actually emerge. When it does, most of us will purchase Play Pro whether we have VEPro or not. So do the right thing. Get together with VSL and fix this problem. You will make a whole lot of your customers happy you did so.
Doug Rogers replied with a few thoughts, but no real solutions except that the issue was VSL's fault. (In a proper, professional manner I'll add. Doug is good people as you all know.) When pressed for more details he replied with the following:
Just ask their developers if they have tried to resolve the issue by linking their qt frameworks statically. If they haven't tried that there is nothing we can do to help them, we believe that's the solution, but are open to hearing their ideas. Obviously it's in everyone's interest to solve all technical issues for users.
So, here I am asking. :) Hopefully you will agree that I am trying to ask in a constructive, professional manner to work with EWQL to resolve the issue. Fingerpointing (on both sides) will never resolve a thing. Been there, done that for over 17 years! Will linking your qt frameworks statically resolve the issue? If so, can the fix be implemented in the near future? If not, what other steps need to be taken to resolve the issue?
There are a great deal of unhappy campers due to this issue. We don't want to be. We like both VSL and EWQL and we are just asking that the technology play nice with each other. That can't be too much to ask, right?
All my best,
-Kevin