JWL - On a pc we can see the hidden files and there is an install log for the LCC. It actually isn’t too difficult to do a restore on the boot drive. We have backups from just before the problem. The restore process is just time consuming, would take most of a day to complete, and (we think) probably wouldn’t solve the problem. We don’t want to do anything on our own here while waiting for further instructions from VSL or Syncrosoft.

Christian - it’s a NAGAMI board with A8N-LA. This PC was new out of the box about three months ago. I would assume the phoenix bios is simply a product of HP production schedules. We followed Paul’s request three times. We installed 5.0.2.4, then 5.0.4.0. We then did the uninstall a third time, verified against the install log that files had been removed, and did a registry edit to remove the persistent registry entries. We then reinstalled 5.0.4.0. None of this had any effect. We also had initially installed VI on another pc - an Intel P4, that was still at LCC 5.0.2.4. When we reinstalled 5.0.2.4, we put the key in that machine and got the same message. We also tried installing everything from scratch on another AMD K8, and the install process stopped with the “you need these licenses” message.

What this tells me is that there is a Syncrosoft-level decryption routine that is still working, and there is a VSL-level decryption routine that is corrupted, and that this corruption is resident on the key itself. Syncrosoft isn’t going to hand me information about fixing their encryption routines, so I just have to wait until they figure out how to create a fix when they don‘t know what the corruption is. Hope that makes sense. I’m keeping my fingers crossed that transferring licenses to a new key will be an answer. But since the uninstall/reinstall approach didn’t work, there is a probability the corruption will transfer itself to the new key. It won’t get here until quite late Monday and I’ll post results then. If it doesn’t work, I’ll be asking VSL again to change its policy on handing out new software.

Thanks both of you for looking at this.

it is the single most buggy copy protection plan I have ever seen since starting on the Mac in 1986. Really, it is that bad. When we have spent this kind of cash, you expect more.

Long live iLOK, which has never once given me a problem on any software that I use.

TH

I agree -- I had to restart my Mac yesterday, and it took 16 minutes to reopen my D. Perf file because of the license scans. Really can't work this way, especially under deadlines. Add that to the 15 minutes of initial bootup and you've got a half hour wasted. Please consider signing a contract with iLok, or using some other method. It seems like Syncosoft has had more than enough time to get their act together, and nothing has really changed with VI first-time boot up.

Peregrine, this might not help you, but did you get the error message with the Library Installer 1.0.3 ? If so, try using a previous version of the Library installer.

Jerome

I got the key early this afternoon, transferred one of the licenses, and it didn't fix the problem. As I thought, the corrupted file from Syncrosoft transferred itself to the new key. This is just total garbage.

VSL can't fix this, and won't send new software.

Syncrosoft doesn't know how to fix this, and is probably on vacation somewhere.

I've got $3000 worth of software that doesn't think I own it.

This is just total garbage.

If possible, you should return the software.

I mean, you spend $3000 and can't use it. What are you supposed to do?

Jerome

peregrine, i feel for you. i really love the whole vsl team and think they've a great vibe going on (and a stonking product!), but i hope to dear god they're reading all the various forums, because they're losing serious money with the number of people who aren't buying it because of syncrosoft.i've downloaded the latets license key on my dual 2.5 gig mac, but it's still buggy as hell. i repeat, it's not anything to do with disliking copy protection, i just don't want to be constantly praying it's going to work. i don't want to be aware of it. why oh why didn't they go with ilok??

Just a little extra support... I've also had a variety of problems since installing the VIs, and suspect these to be Syncrosoft-related as well; hard freezes, achingly long VI launches which have ended in nothing at all being launched, Vienna Keys which at one moment fail to see any licenses then in the next happily launch my VIs. Way too buggy. I have, thus far, been lucky to have got away with simply re-installing the LCC software and the VI software, which (on my system anyway) seems to get things up and running again.

Terribly impressed by the VIs, but terribly unimpressed with Syncrosoft.

I also use MaxMSP regularly, which is Pace/iLok. I don't have an iLok key, rather using the Challenge/Response system, but based on the general lack of iLok complaints on the cycling74 forum, I'd vote to switch to iLok as well. (I wouldn't, however, be too pleased if asked to pay for new iLok keys... however, if pushed, I'd still pay to switch.) I've had to do one archive and install already, after a hard freeze (and subsequent forced reboot) thoroughly mangled my disk directory. No actual data loss, fortunately.

I should also mention that I completely support VSL's efforts to protect the enormous investment they've put into their products. But when copy-protection has such a clearly negative impact on registered users, I find it difficult to see the benefits... Ultimately, this is costing them money, not saving it.

I hope you get your system up and running, Peregrine; the VIs really are a joy to use. Even if the process of getting them running, and keeping them running, is somewhat Purgatorial!

J.

No one can argue the need for copy protection, and once its operational, VI produces great musical results. Thats why this is so completely frustrating. I'm literally begging this company to use their product, and they're telling me there's nothing they can do. So we're all just sitting around waiting for Syncrosoft to create a solution. Since they're focused on the wrong problem, thats going to take a long time.

The problem here is that I have five library licenses that have been corrupted by Syncrosoft. The answer is for VSL to give me replacement licenses. It seems to me that should be easy and it would cost them absolutely nothing. I've already been told they can't do that. They could also send me an additional library so I could get working again while waiting for a fix. That would also cost them absolutely nothing. I've already been told they can't do that. They can't give me a global fix to get around reading the key because that would compromise the security system. They can't give me a specific fix because they don't know the actual nature of the corruption. I think I have a right to be a little indignant.

peregrine, i've emailed you some considerations about a blocked port on your machine(s) - we had this issue with an overzealous AV-app once ...
christian

That was the answer. Christian I can't thank you enough. Herb, give him a big raise.

For anybody else experiencing this problem, you might try enabling local access on TCP port 6179.

Man. I'm not even a PC user and I was cheering to read that a solution had been found.

TCP port 6197. Who would have thought it?

problem is that some AV / firewall applications think they have to block even local communication using the TCP stack ... not the best possible idea.
if not really neccessary for an important reason i'd generally recommend to use AV software sparingly on DAWs. also the time needed opening/installing files can increase dramatically with such software running.
christian

i have no idea what the heck any of that means, but hoorah! good old TCP port 619 [:D]

@paul lm said:

i have no idea what the heck any of that means, but hoorah! good old TCP port 619 [:D]

Oh, yeah. EVERYONE knows about that port. LOL!!

I mean, it is a very clever solution, but I'm clearly outgeeked on this one.

Weeee!

Syncrosoft just came up with some error about a problem with the Oboe Ensemble. I unplugged/re-plugged the key, then it finished off with a "decryption failure" window. How grand! Launch that app, then cross your fingers...

On a brighter note, it looks like killing synsopos, vsl-daemon, and vsl-server in the Terminal, then re-launching the standalone does the trick... or at least it did this time... I would _love_ to be a beta-tester for VSL, but to pay n-thousand for the privalege to beta-test for syncrosoft? Sorry...

If I have to go through this every day I'm going to tear my own face off.

J.

JWL, as mentioned above ... i think nowhere it is recommended to run an AV app on a DAW ... side effects might be the result which are out of our (VSL's) control.

jbm, we always have to look at the complete picture - in case of a complex audio workstation this can get rather large and it is not really possible to pick out a detail and view it isolated from other components.

the existence of this thread shows us one more time that a tiny detail can screw up your whole system and it's often hard to find the definite reason for misbehaviour. i for myself had to face a simple electrical problem with a USB-connector on a brand-new system some time ago. you can't call me a hardware-moron, but it took me some time to track the problem down ....
christian

cm,

I do understand what you're saying. However, accessing registration data from a USB dongle doesn't really qualify as a complex hardware operation, IMO. I'm trying to be quite clear in pointing the finger at Syncrosoft, not VSL. In fact, I'd be curious to know how simple and reliable the VIs have been internally, where I'd imagine there are non-syncrosoft versions used for development. I'm guessing they're a lot more reliable... which is to say, that I'm sure VSL has done their job well! Also, please understand that I'm _very_ impressed with the VIs themselves.

I realize you must assume the position of endorsing Syncrosoft's product, but I am under no such obligation. My feeling about the whole issue is that copy-protection methods which inhibit the stability and proper-functioning of a piece of software are "putting the cart before the horse", so to speak, and I actually find it insulting. Perhaps that's neurotic of me, but that's how I feel. The fact is that, once paid for and registered/authorized, copy-protection should be _completely_ transparent to the end-user.

The current xskey has not been cracked, AFAIK, and I've never had a problem with it; Logic always launches without issue. Sorry for complaining, but I've budgeted a huge portion of my income to VSL products over the past few years, and it is really that commitment which I feel is thrown into question by Syncrosoft's bloated and obviously poorly-designed copy-protection scheme.

J.

jbm, be assured also we can understand your considerations.
apple's XSkey has a kind of advantage: the hardware, the operating system, the audio program and the protection device is from the same company [;)]
we noticed very few problems with XSkeys and AFAIK the VSL performance tool was the only thirdparty plugin ever allowed to be authorized on the XSkey - for obvious reasons this protection method was not available for the vienna instruments ....
i'm convinced we will get ironed out all remaining inconveniances soon
christian

Christian,

No worries. I suppose you have the added difficulty of involving a 3rd party in the whole system which is only concerned with copy-protection. I'd imagine it makes things more complicated when the authorization system needs to be platform, hardware, _and_ software independent... Obviously, it would have been a waste of time and money for VSL to develop their own protection system, so I understand it must be quite complex. Nevertheless, I'm still of the mind that, whatever S-soft is doing, there must be simpler way!

On a slight tangent, I accidentally discovered something you might want to know about. I've divided my instruments between the Mac and PC, with Chamber Strings and Brass I on the PC and Solo Strings and Woodwinds I on the Mac. I was creating custom patches on the Mac, then moving the .matrix files over to the PC (due to the different .aupreset and .fxb issues). I had the PC's key in the Mac while I created the Ch Str and Brass patches, then moved the key (and .matrix files) back to the PC when I was done. However, I found that the Brass patches I'd created would still run on my Mac, even after I moved the key over to the PC. If this is the intended behavior then I'd be very pleased, since it allows me more options over how my instruments are distributed, but I have a feeling this is an oversight. Just thought you might want to know.

cheers,

J.