Thanks for your mail. I do use pd 0.50.0, but you are right: it's not the same deken version with or without the -noprefs flag.
the old deken plugin was in ~/pd-externals the new was in ~/Document/pd/externals I removed the old plugin, now pd find the new one with or without the -noprefs flag.
I was not aware that ~/pd-externals was a default search path even if it's not listed in the preference dialogue and that this path was used even with -noprefs.
There is still something strange : When using pd -noprefs now that I remove the old deken, pd can still find the new deken, so ~/Document/pd/externals is still in the search path. Since this 2 paths are searched with the -noprefs flag, why did the new plugin did not overwrite the old one, just like without this flag?
Anyway, it's working now.
thanks for your help cheers c
Le 25/08/2020 à 09:36, IOhannes m zmoelnig a écrit :
On 24.08.20 17:20, cyrille henry wrote:
i'm on ubuntu linux 18.04 pd 0.51.0
are you sure about the Pd-version?
my interpretation of the issue you see is:
- there has been a single change to the deken package format; the
minimum deken version required for the new package format is deken-0.3.0. luckily, the deken-server knows about this; if it detects that you are using an older version of deken, it will always suggest to upgrade deken first. it tries hard to nudge the user into upgrading deken (without actually forcing them). this is why you get a capital letter warning "MINIMUM VERSION REQUIRED FOR NEW PACKAGES". this is really true: if you are using an old version of deken, you will not see any new-style packages (because deken cannot ectract them anyhow).
- you are using an older version of Pd, that comes with deken<<0.3.1
(sidenote: Ubuntu-18.04 comes with Pd-0.48-1 preinstalled [1]; Pd-0.48-1 includes deken-0.2.4 [2]
- a while ago, you have followed the instructions and installed the
updated deken package. now updating deken does not overwrite the existing source code in the Pd application folder, but instead installs a gui-plugin (in the usual path, where deken installs stuff). when you start Pd, it will first load the included (outdated) deken-plugin, and then load the plugin (there's a version check that prevents an older plugin to overwrite the included one). so you end up with a new and shiny deken plugin that can find and install all the nifty nusmuk packages.
- however, when starting Pd with "-noprefs", you are telling Pd to not
take the "usual" extra-folder into account, where you (or rather: deken) installed the updated deken-plugin. this usual extra folder is probably "~/Documents/Pd" or some self-defined folder (as the usual-usual extra folders like ~/.local/lib/pd/extra are searched regardless of the "-noprefs" flag). so the updated deken-plugin is neither found nor loaded, sending you back to square 1 and you can no longer find the new-style deken packages.
there's a couple of ways to fix the problem:
- include the /path/to/the/deken-plugin/ manually in your start-up flags
(e.g. ~/Documents/Pd/deken-plugin/, so you don't get the full ~/Documents/Pd/ search-path but only the portion that you want)
- manually include an updated version of deken into the
application-specific extra folder (it should go e.g into /usr/lib/pd/extra(deken-plugin/)
to conclude: i don't see this as a bug in deken (nor Pd). (esp. there's nothing *fixable*; new versions of deken (and Pd, which include a newer version of deken) don't have the problem.
gfmasdr IOhannes
[1] https://packages.ubuntu.com/bionic/puredata-gui [2] https://github.com/pure-data/pure-data/blob/0.48-1/tcl/pd_deken.tcl#L62
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list