Re: [PD] deken and pd -noprefs
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: 0. 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). 1. 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] 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. 3. 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 signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] deken and pd -noprefs
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: 0. 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). 1. 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] 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. 3. 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] deken and pd -noprefs
On 25.08.20 10:35, cyrille henry wrote: > why did the new plugin did not overwrite the old one, just like without > this flag? iirc, there's some logic built into Pd to prevent double loading of plugins. (this does not effect the built-in deken, as it comes under a slightly different filename and/or because the "built-in plugins" bypass the protection) gfmnasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] deken and pd -noprefs
ah! I just realise that the deken plugin in ~/Documents/pd is also useless with pd 0.50.0. Cheers c Le 25/08/2020 à 12:08, IOhannes m zmoelnig a écrit : On 25.08.20 10:35, cyrille henry wrote: why did the new plugin did not overwrite the old one, just like without this flag? iirc, there's some logic built into Pd to prevent double loading of plugins. (this does not effect the built-in deken, as it comes under a slightly different filename and/or because the "built-in plugins" bypass the protection) gfmnasdr IOhannes ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] pd~ binary for max/msp
Em seg., 24 de ago. de 2020 às 20:21, Miller Puckette via Pd-list < pd-list@lists.iem.at> escreveu: > does anyone out there know if Max 7 externs work on Max 8 as well? someone in the max facebook group tells me some work absolutely fine and some don't work at all... i'll try and ask why and how to make it run on both ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] pd~ binary for max/msp
but you can go ahead try and make it run on 7 and we can test to see if it works in 8 Em ter., 25 de ago. de 2020 às 11:36, Alexandre Torres Porres < por...@gmail.com> escreveu: > Em seg., 24 de ago. de 2020 às 20:21, Miller Puckette via Pd-list < > pd-list@lists.iem.at> escreveu: > >> does anyone out there know if Max 7 externs work on Max 8 as well? > > > someone in the max facebook group tells me some work absolutely fine and > some don't work at all... i'll try and ask why and how to make it run on > both > > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] pd~ binary for max/msp
Thanks - that tells me exactly what I needed to know :) M On Tue, Aug 25, 2020 at 01:55:57PM -0300, James Correa wrote: > If the externals are 64bits they work on Max 7-8, but if they are 32 bits > only on Max 7. > > James > > On Tue, 25 Aug 2020 at 11:39, Alexandre Torres Porres > wrote: > > > but you can go ahead try and make it run on 7 and we can test to see if it > > works in 8 > > > > Em ter., 25 de ago. de 2020 ??s 11:36, Alexandre Torres Porres < > > por...@gmail.com> escreveu: > > > >> Em seg., 24 de ago. de 2020 ??s 20:21, Miller Puckette via Pd-list < > >> pd-list@lists.iem.at> escreveu: > >> > >>> does anyone out there know if Max 7 externs work on Max 8 as well? > >> > >> > >> someone in the max facebook group tells me some work absolutely fine and > >> some don't work at all... i'll try and ask why and how to make it run on > >> both > >> > >> > > ___ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!R9tRLYvWqzLGMVt7nQ74voOXjLypts3aIVfsxRHLkMG18syfuc6yeTwBE23R$ > > > > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] pd~ binary for max/msp
If the externals are 64bits they work on Max 7-8, but if they are 32 bits only on Max 7. James On Tue, 25 Aug 2020 at 11:39, Alexandre Torres Porres wrote: > but you can go ahead try and make it run on 7 and we can test to see if it > works in 8 > > Em ter., 25 de ago. de 2020 às 11:36, Alexandre Torres Porres < > por...@gmail.com> escreveu: > >> Em seg., 24 de ago. de 2020 às 20:21, Miller Puckette via Pd-list < >> pd-list@lists.iem.at> escreveu: >> >>> does anyone out there know if Max 7 externs work on Max 8 as well? >> >> >> someone in the max facebook group tells me some work absolutely fine and >> some don't work at all... i'll try and ask why and how to make it run on >> both >> >> > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list