Hi!

Could anyone tell me how to get the cyclone library working again on PD Vanilla/Windows 10? I've been using the Vanilla version happily with cyclone working for months now - yet suddenly today the cyclone library stopped loading. When I first started with Vanilla, I installed the library simply through 'find externals' and it was up and running, but now it keeps saying that "no writeable directory found". I mean...what on earth could have happened between last night and now?

Thanks for any help! I've searched through previous posts here on the same topic but none of the solutions seems very clear to me (I'm not too versed with the technical side of PD yet).

@ingox That's the thing, it doesn't show anything in preferences > startup (just blank fields) even if it had saved my entries, which I have no way of knowing.

The only error message on startup I get is "WARNING: Font family 'DejaVu Sans Mono' not found, using default (courier)".

@ilpoj sorry forgot about that...
have you installed the newest version?

@ingox yes, the 0.47-1 one.

@ilpoj I think the loadlib keys..... 1 2 3 etc..... are the libraries declared, at install, or by deken, or found in the "extra" folder.
The paths should be those declared in "preferences".
It seems Pd is not looking in the right place at load?
Unless you have the -nostdpath flag somewhere I don't understand this.
Are the read permissions ok as well in the registry?

Would you please try starting Pd by creating a shortcut, and then adding -stdpath to the end of the shortcut path to Pd, although I wonder if the value of -stdpath has been changed from "the path to -extra-".
You could also try adding -path "path to cyclone folder" to the shortcut......
David.

@ilpoj As [cyclone/counter] works,

[declare -path c:/.../extra/cyclone]
[counter]

should also work after reopening the patch. So you wouldn't need to change all the objects.

Edit: In the help file of declare you can see that for windows paths it reads c:/something, so with a single slash, which i believe is correct, because it is consistent with what i read about how tcl handles paths. Could be worth to keep that in mind...

Another thing you could try is:

• open this patch: add_path3.pd and click on the bang
• Look at Preferences > Path...
• Restart Pd
• Look at Preferences > Path... again

In a working Pd installation it should have the entry 'test' in Preferences > Path... in the second and the last step.

But i suspect it doesn't work, as it basically does the same thing as the Preferences > Path... dialog. You could look in the registry if it added an entry 'test', which would mean that Pd can at least write to the registry.

@whale-av said:

-stdpath

Yes the read permissions are ok in the registry.

Hey, adding the -path "path to cyclone folder" to the shortcut did the trick! Now the objects in the cyclone folder are loading normally upon startup. Thanks so much for the advice! I just still wonder what caused the problem in the first place, and why Pd needs to be a sort of separately reminded of the externals... anyway I'm happy it works now.

@ilpoj That's good news!
Out of interest, are they working now if you open a patch by double-clicking the file? Or only if you use the shortcut to open Pd first?
I.e. has it forced Pd to repair it's corruption permanently?
David.

@ingox I've tried the [declare] but it doesn't seem to work, I just get the error message "unknown declaration" (and I've checked for any typos). But yes in theory it should work.

With add_path3 it records the entry 'test' in the second step but doesn't show up after restarting. In the registry it has added 'test' to path1 though.

@whale-av They seem to work only when I open Pd through the shortcut. Which is good enough for me (at least for now).

@ilpoj you could also try to make another shortcut and add -prefs instead of -path. This forces Pd to read the preferences set in the registry. Usually this is the default behavior and therefor not necessary, but maybe worth giving it a shot...

Edit: 'test' should show up in Preferences > Path...

@ilpoj It could be a widows10 update.
tcl ........ pd_guiprefs.tcl performs the read/writes through the "registry" object.
On a 64-bit system 32-bit apps write to the "VirtualStore" in the registry.
What is 64-bit and what is 32-bit in Pd and Tcl/Tk?
Maybe it's writing to one and reading from the other?
Tcl........ Tcl 8.6 recommended........
https://stackoverflow.com/questions/31432958/tcl-unable-to-read-variables-of-32-bit-registry-hierarchy-on-a-64-bit-machine
Widows........ Microsoft intend to bin VirtualStore and force app compatibility.....
...... have they just started this process?
https://msdn.microsoft.com/en-us/library/windows/desktop/aa965884(v=vs.85).aspx
Other software identical problem.......
http://knowledgebase.progress.com/articles/Article/UACvirtualisation
Pd_guiprefs.tcl on-going work....... 16 days ago.... maybe time to post a bug?
https://github.com/pure-data/pure-data/tree/master/tcl

Again..... Tcl 8.6 recommended.......
https://community.activestate.com/node/11350
and....
http://www.tcl.tk/cgi-bin/tct/tip/362.html
David.

@ingox Thanks, but when I add -prefs, it doesn't actually open Pd at all.

@whale-av Thanks for the info and the links! I'll have a better look at these if this becomes an issue - so far it's working fine, with the -path in the shortcut.