Vienna Symphonic Library Forum
Forum Statistics

182,569 users have contributed to 42,241 threads and 254,850 posts.

In the past 24 hours, we have 4 new thread(s), 13 new post(s) and 48 new user(s).

  • Hey VSL, Are You Familiar with Coopetition?

    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


  • Hello Vibrato,

    With all due respect, I'll respond to your post.

    Obviously you have had a bad experience with Play and that is unfortunate.  There are certainly others that have had issues also.  However, I think you are generalizing based on your experience and perhaps posts from others on support forums where bugs are supposed to be reported.  Your first sentence about Play being badly designed and unstable is purely a subjective statement and not really useful for this thread. Your comment `Cubase being generally considered the most stable sequencer is out there' is purely conjecture. There are plenty of people I know who would outright laugh at that statement given their experience with Cubase.  Not myself, Cubase has always been stable for me, however there are plenty of others.  The same goes for any other DAW.  The fact is you cannot make a statement like that because there is no way to quantify it.  It is not a useful statement.

    What is useful are facts, or in this case one fact.  VEPro and Play are not yet compatible.

    VEPro is compatible with lots of VIs that is true, however there is also a sizeable list of VIs that it is not compatible with.  Hence, VEPro not being compatible with Play tells me nothing except that they are not compatible.  I was a programmer for about 10 years of my career and I understand that compatability between all VIs and VEPro is not going to be easy.  In fact, it is improbable.  However, compatability with the `big boys' should be a priority and in the case of Play it does not seem to be so.  Otherwise the issue would be being addressed instead of two companies having a fingerpointing fight.

    I do not know exactly how you navigate web pages, however contacting EWQL is very easy.  You click on the Support link that is at the top of every page.  The page you are sent to includes Submit a Ticket, Knowledgebase, TroubleShooter, News, Downloads and a handy list of recent updates below these links.  How exactly is that confusing?

    It is unfortunate that you cannot use the Play libraries.  As a user of Cubase you probably already know that the issue between Cubase and Symphonic Choirs was recently fixed when Cubase was updated.  No update was required on the EWQL side.  My recommendation is that you use the Support link at the top of every soundsonline.com page to submit a troubleticket.  To say that most peole have had similar problems is of course blown heavily out of proportion.  If most people had these issues the Soundsonline forum would be 10 times as busy with frustrated customers than it is.  Some people have issues, just like some Cubase users have issues with Cubase and some VSL users have problems.  After all, it is software and software is always imperfect.

    I for one, along with others, are happy to have EWQL sales going on.  Wouldn't it be nice if you could get a discount on a VSL from time to time?  It amazes me that even when companies provide good offers that some people still find a way to complain.

    I've no idea what EWQL revenue looks like for 2009, however I've no worries about the company's future.  I hear EWQL being used on the radio, TV, in movies, etc.  For the record, the same goes for VSL.  Both companies provide high quality products and will continue to be successful as long as they do.

    Honestly, your post comes off more like a rant than a productive response to my post.  It was the last kind of response I wanted to hear.  As I said in my post, I posted the same thing on the Soundsonline forum and within hours had a direct response from Doug Rogers himself.  He provided an exact issue that he believes needs to be resolved between the two products and I've brought that response to VSL in the hope that the incompatability can be resolved quickly.  This is for the good of both companies and their customers.  I still have hope that VSL will soon provide a similar response and that the compatability issue will soon be resolved.


  • Welcome Kevin,

    while we have very liberal rules in this forum, I ask you to stay away from personal attacks of other forum members. Tanuj's message was as much a rant or a "useful statement" as yours - he was just expressing his personal opinion. And please keep the public discussion about the issues of other companies to a bare minimum. 

    Thanks a lot for your understanding. Kind regards,


    /Dietz - Vienna Symphonic Library
  • I don't see it as a personal attack at all, Kevin gave a very detailed response addressing his points.  Anyway, it's all off topic anyway, the issue at hand is compatibility between the two.

    Could someone at Vienna respond to Doug's statement?  If what he has suggested has been tried and didn't fix the issue, he should be made aware of that.  It does users no good if both sides insist that it's not their fault.

    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.


  • last edited
    last edited

    @Dietz said:

    Welcome Kevin,

    while we have very liberal rules in this forum, I ask you to stay away from personal attacks of other forum members. Tanuj's message was as much a rant or a "useful statement" as yours - he was just expressing his personal opinion. And please keep the public discussion about the issues of other companies to a bare minimum. 

    Thanks a lot for your understanding. Kind regards,

    Hello Dietz,

    My apologies, I don't want to ruffle feathers with a first post! :)  Although not intended to be a personal attack, I can see how they could be looked at that way.  The point that I was trying to make was that in this case personal opinions or any other subjective commentary is not going to help the main topic of this thread.  It will only dilute it.  I'll be more careful in the future!

    I can understand you wanting me to keep the discussion down on other companies and will respect that in the future.

    I have to ask, did my post really come off as a rant?  My hope was that it would come off as a logical, structured message directed as solving what many users consider to be a significant issue.

    Last question - is VSL taking Doug's comments seriously?  How can we as a user community help get this issue resolved?  I could see the issue not being a topic of signicicance if the incompatibility was with a small one off VSTi, but that is clearly not the case.  I would not be posting anything if I felt like the lone person wanting this. 😊

    Just to emphasize, I know I am the new kid on the block here.  One post and I'm already rocking the boat!  Certainly I had hoped to rock the boat, but in a constructive matter.  A potential solution has been given by Doug.  Will this solve the problem?  What can the company share with its customers about the issue?  What can we do to help resolve it?

    Ok, I'm now repeating myself so I will stop.  Thanks for your patience with my first post!

    Alles güte,

    Kevin


  • last edited
    last edited

    @Another User said:

    Just to emphasize, I know I am the new kid on the block here.  One post and I'm already rocking the boat!  Certainly I had hoped to rock the boat, but in a constructive matter.  A potential solution has been given by Doug.  Will this solve the problem?  What can the company share with its customers about the issue?  What can we do to help resolve it?

     

     I doubt that VSL will comment here, but kudos for trying. [;)]

    DG


  • welcome LFO,

    now this sounds like great news, because to my knowledge it has not been to easy in the past to get in touch with their developers and even getting a license was hard  - all iLok keys registered at VSL are locked for PLAY licenses, but probably this is just an administrative error so we are looking forward to find a solution practicable for both parts.

    christian


    and remember: only a CRAY can run an endless loop in just three seconds.
  • I don't understand this, can't you just buy a PLAY library?  Or is EW somehow getting iLok to disable any registration that is bought by VSL (which would seem bizarre, but should be easily worked around, just register under a different name).

    Odd.


  • that's what has been done finally ... agreed: appears bizarre ...


    and remember: only a CRAY can run an endless loop in just three seconds.
  • This comes directly from Doug Rogers himself: "We already told them what to do, they could resolve the crash with PLAY by linking their qt frameworks statically. Understand it's not our software, we can't fix their problems, PLAY works fine with other hosts, it has nothing to do with competition, we cooperate with competitors all day every day, it's the nature of our business. Cheers, - DR" - SO VSL VEP Should be able to run PLAY (Mac OSX) after some framework tweaking, right VSL ? -R-

  • ..And Doug suggests as to ask if VSL support have yet tried this trick: "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. Cheers, - DR" -R-

  • ..ok it seems that this topic has already been opened in "general" section of the forum. -Over and out- -R-

  • I'd still like to hear Vienna's response to this, whichever way it goes.


  • I can assure you that the problem is presently being investigated! We are considering all possible solutions but please understand that we won´t discuss them in our public forum.

    Kind regards,

    Maya VINSON


  •     Just want to say hi to the GREAT VSL TEAM.

    I use VEPro and Play together. Works fine for me. I have Play installed on my host computer and VEPro on my slave and Host.


  • last edited
    last edited

    @LFO said:

    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.

    I'll try to be as detailed as I can about this matter, but it might get technical.

    When we first released VE Pro, the Qt version we were using (4.5) did not allow to link the Qt frameworks statically when compiled with the Mac/Cocoa backend. Since Carbon on Mac does not support 64-bit, we need Cocoa. With the latest public betas, we have switched to Qt 4.6, which according to Nokia/Trolltech allows static linking. Doing this however introduces a number of gui related bugs, which is why we have chosen to keep the dynamic linking for VE Pro on mac. Besides, Play crashes even when our Qt frameworks are statically linked, so there would be no benefit for us.

    All of the VSL plugins which use the Qt libraries (VE Pro connector, Vienna Suite, Vienna Imperial) are linked statically on Mac, and we have gone out of our way to ensure that they don't cause any interaction with other plugins or hosts which use Qt. I have suggested to EastWest developers to try a static linking of Play, but haven't heard any results yet. Using Qt and its QtGui/QApplication parts for AU plugins is very tricky business, and some hacks have to be put in place to get it to work at all. For that reason, VSL has chosen not to use Qt for any plugin guis on Mac.

    Thanks,


  • last edited
    last edited

    Hi everybody,

    Martin Saleteg, main developer of Vienna Ensemble PRO, has actually commented on the status here.

    Best,

    Paul


    Paul Kopf Product Manager VSL
  • Hi Sharon, Have you noticed any problems in PLAY with DXF/Modwheel patches used? When I load several instances of PLAY, I experience dropped notes only on the midi tracks that have DXF patches assigned to them. The notes just cut off at specific points throughout. Also, how many instances of PLAY do you run within one instance of VE Pro, and how many instances of VE Pro do you instantiate. Thanks, j.

  • Martin, thank you for your response, your honesty is most appreciated. Unfortunately, if I am reading your comments correctly, it sounds like most likely no solution will be forthcoming, due to the way each program is coded, and that fixing it could require a major rewrite by either VSL or EWQL (not really a viable option for either company I would strongly suspect).

  • Strangely enough... after upgrading to a new Win 7 x64 computer. VEPro and Play seems to work as long as I only use it on the 32bit server and as along as it is the only instrument there. Fortunately all my other vsts are 64 bit so for the time being it is working... somewhat.

    edit: I must point out that VE-Pro is saving me tons of time not having to reload samples so I must confess its the most usable software after Cubase in my setup. :) My intial post seemed maybe negative towards VE-Pro which is not the case...