EDIT: I made the rookie mistake of not reading the FAQ properly. Some of my questions have already been answered. However, I think my proposed solution might still be worth considering compared to how replacement devices and license transfers are currently handled.

My top left encoder suffers the problem of not responding unless turned very slowly. This began before I installed Zaquencer so it’s a problem with the unit. I
probably should have seen about having it replaced before installing Zaquencer, but it worked decently enough for what I used it for previously that I could live with it. Turns out it becomes really annoying when trying to do live pattern manipulation in Zaquencer.

I have discovered a possible solution, which I will write a separate post about, but I haven’t tested it properly yet.

Theoretically, my BCR2000 is still under warranty. Technically I voided it when I flashed it, but it’s not as if anyone will know if I flash it with the original firmware before sending it back. It’s a good thing I’ve been too lazy to apply the stickers, hehe.

I’m considering contacting the vendor to see if I can have it replaced, but that brings up a whole different issue: As far as I understand it, the Zaquencer license is not transferrable between devices, correct? I bought Zaquencer only a couple of weeks ago, so I’m not overly interested in purchasing another license just because I needed to have my unit replaced.

I understand the reasons for the single device license, even though I am personally of the opinion that once you buy a piece of software (or hardware for that matter), private use should be unrestricted. I respect the decision of the vendor/developer however.

Where the single device license becomes a real problem with Zaquencer has less to do with business/development philosophies, and more with the fact that it is widely known and accepted that the BCR2000 build quality is notoriously hit-or-miss and that it’s not unheard of for a brand new perfectly working unit to start exhibiting problems within weeks or days if you’re unlucky. I would have been quite pissed off if I had bought a new BCR2000 just for Zaquencer, installed it, and then it started failing a few days later. That would be €92 (including shipping and stickers) straight down the toilet. I can live with only being allowed to run a copy of Zaquencer on one device at a time, but the BCR2000 hardware is just not reliable enough to justify permanently locking Zaquencer to a particular device ID in my opinion. To me it greatly reduces the value of Zaquencer, even though it’s through absolutely no fault at all of zaq.

I’ve been trying to think of an alternative authorization scheme, and I think I have a viable solution.

If the challenge code had a static part based on device ID, and a random part for every installation, new response codes could be required and generated for every installation, and still only be valid for that particular device. It’s really a minor hassle to request a new code, I doubt most users reinstall very often.

De-authorization could be made by a function for generating a de-authorization code in the same way. The de-authorization code would be submitted through a form and the response code would lock the device and present a confirmation code, submitted as proof that the device has been locked. Once this confirmation code is submitted and received, the device is removed from your authorized devices, allowing a new device to be registered and authorized in its place.

There are some possible issues, and solutions to most, with this method:

* Power outage after locking, but before sending the confirmation code.
+ Solution: after locking, the confirmation code is always shown on startup on a locked device.

* Device has been sent for replacement prior to de-authorization, making proof of deactivation impossible.
+ Solution: ???

* Device has suffered catastrophic failure and will not turn on/knobs can’t be operated, making input/deactivation impossible.
+ Solution: Send picture of smashed device with visible serial number (assuming the authorization is based on serial number) as proof of deactivation. Will require manual removal of the authorized device by zaq.

* Device is reinstalled after writing down the confirmation code, but before submitting it, leaving you with a functional, although not reinstallable device.
+ Solution: Disable generation of installation response codes for that device ID when the request for de-authorization is sent until the deactivation confirmation code has been received.

How does that sound?

• This topic was modified 9 years, 7 months ago by  prndrsn.