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.

thanks for confirming this, although intended, behaviour. if this would not work, it would need a fix.
IIRC this is one of the limitations for the current VI version for intelMacs (public beta) - the customized matrices are not always 100% compatible yet.
christian

I just wanted to make sure I made myself clear. The ability to swap matrices between Mac and PC I assumed would be fine, since the .matrix is your own proprietary format. The point I was trying to make, but which I probably garbled a bit, is that the Brass instruments would still load and run, even though the Vienna Key holding the authorizations had been removed: i.e., the Brass instruments were not, technically, authorized to run on the machine anymore, since I had moved the key back to the PC. I'm assuming this is because the authorization was checked at the first launch, and synsopos, vsl-daemon, and vsl-server had not been re-launched since removing the key. Anyway, if I only need the key attached for the first launch, then that makes it easier to break up the instruments over different machines than I originally thought.

Just making sure that was clear.

thanks,

J.

@cm said:

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 hope it is clear that I am as dumbfounded as anyone, but joking about it. The tiniest things can indeed bring creativity to a screeching halt for weeks, as I have experienced. Not being a PC user, the AV port # was just so unusual and unexpected that it made me wonder what little Teufel may be lurking on my system.

No, you're no hardware moron, but your discovery takes you beyond geekdom into the realm of genius! Thanks!

@jbm said:

I just wanted to make sure I made myself clear. The ability to swap matrices between Mac and PC I assumed would be fine, since the .matrix is your own proprietary format. The point I was trying to make, but which I probably garbled a bit, is that the Brass instruments would still load and run, even though the Vienna Key holding the authorizations had been removed: i.e., the Brass instruments were not, technically, authorized to run on the machine anymore, since I had moved the key back to the PC. I'm assuming this is because the authorization was checked at the first launch, and synsopos, vsl-daemon, and vsl-server had not been re-launched since removing the key. Anyway, if I only need the key attached for the first launch, then that makes it easier to break up the instruments over different machines than I originally thought.

Just making sure that was clear.

thanks,

J.

duh... I figured out what was up; I still had demo starts of Brass I on my Mac key. That's why it would run even though the PC key was removed. [:O]ops: