Hello
I haven’t used VCV for some time and yesterday when I start it again, it appear than some of my files wouldn’t open. See the error message on the picture.
To be sure I installed VCV on windows where the files open normally. After investigation it turns out that the WT-VCO and WT-LFO modules are the source of the problem.
If I create a new WT module on mac, save it and reopen it, there is no problem.
If I create a fresh new file with just a WT-VCO or LFO module on windows, and then I open it on mac, I get the error message again.
The problem is that I have quite a bunch of files including these files, and my platform is the mac.
As it is all I can do is delete the modules on window, bring the files back to mac and recreate these modules, wich is is pretty annoying.
I haven’t done any system update.
Is anyone experiment this kind of problem ?
And more so, do you have any idea to solve the problem ?
Happened to me a few times. Fix is, close Rack, go via Terminal to ~/Documents/Rack2/autosave, and make the modules folder in there read-write again, as it flipped to read-only (it does here for some bizarre yet unbeknownst reason). Maybe something to do with Ventura and Rosetta, which Rack2 runs under. Not a permanent fix though, seems to come and go, or most of my patches have no module writing any runtime data into that dir. Report to VCV report email. Another user facing this, as I already have
What exact version of macOS? What exact version of VCV Rack? VCV Rack downloaded from VCV Rack 2 - Virtual Eurorack Studio or self-compiled? Did you copy over all the files under …/Documents/Rack2/ from a backup or from Windows, or did you login to the library inside Rack and fetched all your plugins from inside Rack?
If you’re on the very latest version of macOS (I’m not) try and open system settings and go through the security features and see if there’s anything to do with “protecting document folders” or some such that you can try and turn off. Both Windows and I’m sensing macOS too are becoming quite aggressive about protecting your document folders against applications, and so are doing things that make legit applications fail. I know it’s because of the ransomware scourge but still…
Hello
Thank you for your answers
Firstly I am on El capitan and I was on the version 2.0.6 of vcv.
The problem appeared suddenly, and the only thing that has been updated are the modules.
I installed the latest version of vcv but it didn’t change anything.
@fractalgee
Thanks, that did the trick. However I have to repeat the operation for each file containing one of these two modules.
It works for a while, but since I don’t even have to quit vcv to change permissions (it’s work for me) it’s not too annoying. I just put the autosave folder back in write mode, reload the file and it works.
I noticed that as soon as you load a file, the folder (and its hierarchy) returns to read only mode. But this does not affect the files that have been “unlocked”.
The files may or may not work independently of each other, regardless of the authorization setting !
@Larsbjerreggaard
I’m on El capitan 10.11.6
vcv 2.1.2 dowloaded from the site, and I fetch my plugin from inside vcv.
@Squinky
As since the last opening of vcv about two weeks ago absolutely nothing has changed on my machine, apart from the update of the vcv modules, I don’t see what else, apart from a module, can generate the problem.
Now it may be another module that causes the problem, but unfortunately I did not note the list of modules that have been updated.
I will phrase it differently. Maybe it’s not these modules that generate the bug, but rather that, before the updates, they were able to manage the authorizations in the autosave folder, and that afterwards, whatever the source of the problem, they can’t do it anymore.
I just verified my reported issue is due to same. Easy to repro: empty patch: add WT VCO and or LFO and as soon as autosave has happened you can watch the modules folder magically going from Read/Write, to which I had set it again, to read-only, MacOS Ventura (13.0.1) M1 Mini here
I seem to only see it when adding and then autosave has to happen. The folder it created insides the modules folder stays read/write but the modules folder goes read-only. weird this is, indeed!
What exactly do you mean by “the modules folder”? Do you mean /Users/SOMEONE/Documents/Rack2/autosave/modules/ ? Can you list the full path to it please?
And can you list the output of ls -Rla autosave when standing in Documents/Rack2/
yes, the autosave/modules folder in the Rack2 Documents folder. Right now it seems not to repro for again some unbeknownst reason, makes less and less sense to me. right now autosave/modules is writable by me, will. post when I see it again.
One other thing, when I didn’t save patch after last time it did repro earlier today and opened a new one, the folder it had made inside the autosave/modules folder vanished.
Should it be possible to delete a directory from a read-only directory? Seems wrong to me from a +NIX-y viewpoint, doesn’t it?
From what I understand after some observations with the terminal, it is normal that the autosave and modules folders are in read only mode. It is VCV that sets these permissions this way. You can see this here.
Initially I set everything to read-write mode (the autosave folder and all the included elements).
Mac-Pro-de-lozzec :autosave JohnDoe$ cd /Users/JohnDoe/Documents/Rack2/autosave
Mac-Pro-de-lozzec :autosave JohnDoe$ ls -Rl
total 8
drwxrwxr-x 11 JohnDoe staff 374 21 nov 21:39 modules
-rw-r--r-- 1 JohnDoe staff 180 21 nov 21:41 patch.json
./modules:
total 0
drwxrwxr-x 2 JohnDoe staff 68 21 nov 21:39 1749530006158264
drwxrwxr-x 2 JohnDoe staff 68 21 nov 21:39 1878679374588749
drwxrwxr-x 2 JohnDoe staff 68 21 nov 21:39 2927619628667208
drwxrwxr-x 2 JohnDoe staff 68 21 nov 21:39 3269226139377210
drwxrwxr-x 2 JohnDoe staff 68 21 nov 21:39 4099646330616141
drwxrwxr-x 2 JohnDoe staff 68 21 nov 21:39 7476733893097503
drwxrwxr-x 2 JohnDoe staff 68 21 nov 21:39 76258374204980
drwxrwxr-x 2 JohnDoe staff 68 21 nov 21:39 7949297009881657
drwxrwxr-x 2 JohnDoe staff 68 21 nov 21:39 836237481908555
As soon as you open a new file (whatever it is) the permissions immediatly go back to read only mode.
Mac-Pro-de-lozzec :autosave JohnDoe$ cd /Users/JohnDoe/Documents/Rack2/autosave
Mac-Pro-de-lozzec :autosave JohnDoe$ ls -Rl
total 8
dr-xr-xr-x 11 JohnDoe staff 374 21 nov 21:54 modules
-rw-r--r-- 1 JohnDoe staff 952 21 nov 21:55 patch.json
./modules:
total 0
dr-xr-xr-x 2 JohnDoe staff 68 21 nov 21:54 1749530006158264
dr-xr-xr-x 2 JohnDoe staff 68 21 nov 21:54 1878679374588749
dr-xr-xr-x 2 JohnDoe staff 68 21 nov 21:54 2927619628667208
dr-xr-xr-x 2 JohnDoe staff 68 21 nov 21:54 3269226139377210
dr-xr-xr-x 2 JohnDoe staff 68 21 nov 21:54 4099646330616141
dr-xr-xr-x 2 JohnDoe staff 68 21 nov 21:54 7476733893097503
dr-xr-xr-x 2 JohnDoe staff 68 21 nov 21:54 76258374204980
dr-xr-xr-x 2 JohnDoe staff 68 21 nov 21:54 7949297009881657
dr-xr-xr-x 2 JohnDoe staff 68 21 nov 21:54 836237481908555
I don’t know the mechanism but it’s VCV that should allow writing if needed. This mechanism does not work well with the two WT modules.
What is curious is that when you set the permissions in read-write mode the time to open a file containing say WT-VCO it can be opened a number of times while the permissions are returned in read only mode.
Well, as I hope I documented above, not on my machine.
Assuming that by “you open a new file (whatever it is)” you mean “I’m opening a new patch in Rack” - right, I can see that read-only mode is now set on those module directories, but not on the patch file. This does not happen on my machine. My guess is that it would be due to:
El Capitan having introduced more aggressive protections of HOME directories. Try and find it in settings and turn it off. I wouldn’t know since I’m on Sierra.
You’re running some kind of “security software”. Turn it off, or better, un-install it. They only cause pain.
If I were you I would write to support@vcvrack.com with your observations and details about OS version.
I have been using vcv for over a year and everything was working fine until about two weeks ago when everything was still working fine.
I don’t have any security software, and apple’s security settings are set as low as I know.
I have contacted the support but in the meantime I have observed this strange behaviour a little more closely.
I test it with four files.
each on containing just one WT-VCO or LFO module
WT-VCO only.vcv (from a file created with vcv 2.0.6 before the problem appears)
WT-LFO only.vcv (from a file created with vcv 2.0.6 before the problem appear)
WT-VCO fresh mac.vcv (a new file with a new fresh module created in vcv 2.1.2 after the problem appear)
WT-VCO win.vcv (a new file with a new fresh module created in vcv 2.1.2 after the problem appear but on windows)
As we know the problem comes from the modules folder (/Users/fl/Documents/Rack2/autosave/modules) which switches to read only mode when opening a patch containing one of the two modules.
If I set the permission to read-write, I can open a patch containing a WT module again, but the folder immediately goes back to read-only mode.
If I put it back in read write mode and open a patch that does NOT contain WT-VCO|LFO the folder status does not change and remains in read/write mode.
As soon as I open a patch containing WT-VCO|LFO the folder returns to read only mode.
If I want to open say “WT-VCO only.vcv” I set the module folder to read/write mode and it works, however the folder immediately returns to read only mode.
But I can continue to open this file without problems.
Now if I want to open say “WT-LFO only.vcv” I have to set the module folder to read/write mode again and it works again.
BUT “WT-VCO only.vcv” does not open anymore. And so on.
However the patch “WT-VCO fresh mac.vcv” continues to open without any problem → a fresh new patch with a fresh new module WT is no problem.
But, opening this patch still puts the modules folder in read only mode.
Obviously I tried to recreate the WT-VCO|LFO modules in some old patches, but it doesn’t work.
Basically only a new patch with a new WT module does not cause problems.
The patches created before the problem appeared, or the patches created under windows are a problem, even if one tries to replace the faulty modules, and by making a save as.
