we are proud to announce a major overhaul of the deken fileformat.
TL;DR to download new deken packages, you will need at least version v0.3.0 of the deken-plugin (Pd-0.48-1 includes deken-v0.2.4). When searching externals with an old (incompatible) version of the plugin, you will always find a suggestion to install the new plugin with something like:
deken-plugin/0.3.0 (Deken externals downloader - REQUIRED FOR NEW PACKAGES)
once you have installed the new version (and/or Pd includes a compatible version), the nagging will stop :-)
# fileformat
the new fileformat fixes a number of issues we had with the existing one. things that are better:
library has a weird name like "a-v12"
# Pd-integration the updated "deken-plugin" has a number of nifty features, you don't want to miss:
successful installation
offering to create those that are missing)
# Developer tools if you are a developer of libraries, we have also updated our 'deken' cmdline tool. things you always wanted to have and which are now free:
if you want to know more, see
i have submitted also submitted a Pull-Request to include the new deken-plugin into Pd proper:
and another Pull-Request for Pd that is required to make the double-precision detection work:
happy patching. fgm,asdr IOhannes
Pd-announce mailing list Pd-announce@lists.iem.at https://lists.puredata.info/listinfo/pd-announce
awesome!
2018-03-08 13:09 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
- (optionally) show a README that is included in the package on
successful installation
Can this be any file format, like a PDF? Or does it have to be .txt or something?
cheers
On 2018-03-08 17:46, Alexandre Torres Porres wrote:
awesome!
2018-03-08 13:09 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
- (optionally) show a README that is included in the package on
successful installation
Can this be any file format, like a PDF? Or does it have to be .txt or something?
it has to be either a .pd, .html or .txt file, must be named: README.deken.pd (or similar) and must live inside the <libraryname>/ folder. so if your package is "cyclonev0.0.dek" this would be "cyclone/README.deken.txt"
fgasdrm IOhannes
Thank you so much for this invaluable (and substantial...) work, which still promises a long life to Pd, allowing everyone to bring his own stone to the building!
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
2018-03-08 17:09 GMT+01:00 IOhannes m zmoelnig zmoelnig@iem.at:
we are proud to announce a major overhaul of the deken fileformat.
TL;DR to download new deken packages, you will need at least version v0.3.0 of the deken-plugin (Pd-0.48-1 includes deken-v0.2.4). When searching externals with an old (incompatible) version of the plugin, you will always find a suggestion to install the new plugin with something like:
deken-plugin/0.3.0 (Deken externals downloader - REQUIRED FOR NEW PACKAGES)
once you have installed the new version (and/or Pd includes a compatible version), the nagging will stop :-)
# fileformat
the new fileformat fixes a number of issues we had with the existing one. things that are better:
- cool filename extension '.dek'
- consistent archival options for all platforms (ZIP!)
- proper detection of the version string for all libraries (even if the
library has a weird name like "a-v12"
- support for double-precision externals (once Pd supports that!)
- extensible
# Pd-integration the updated "deken-plugin" has a number of nifty features, you don't want to miss:
- support for the new fileformat
- support for the old (legacy) fileformat
- (optionally) uninstall libraries before re-installing them
- (optionally) show a README that is included in the package on
successful installation
- set installation path (suggesting Pd's default search paths, and
offering to create those that are missing)
- (optionally) hides the search-results for incompatible platforms
- (optionally) overrides the "compatible" Pd-architecture
- nice preferences
- bugfixes
- much more
# Developer tools if you are a developer of libraries, we have also updated our 'deken' cmdline tool. things you always wanted to have and which are now free:
- support for the new fileformat (default)
- support for the old (legacy) fileformat
- better detection of binary architectures
- better detection of included sources
- (experimental) support for double-precision externals
- pre-compiled & self-contained Windows binaries
- bugfixes
- much more
if you want to know more, see
- http://puredata.info/downloads/deken/releases/0.3.0/
- https://lists.puredata.info/pipermail/pd-dev/2018-02/021513.html
- https://github.com/pure-data/deken/issues/161
i have submitted also submitted a Pull-Request to include the new deken-plugin into Pd proper:
and another Pull-Request for Pd that is required to make the double-precision detection work:
happy patching. fgm,asdr IOhannes
Pd-announce mailing list Pd-announce@lists.iem.at https://lists.puredata.info/listinfo/pd-announce
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On 2018-03-08 17:09, IOhannes m zmoelnig wrote:
[...]
# Pd-integration the updated "deken-plugin" has a number of nifty features, you don't want to miss:
- bugfixes
by now, we are at v0.3.1, which (among other things) works around Microsoft's insistance that zip-files *must* end with .zip.
i've retracted the v0.3.0 release...
dams IOhannes
- set installation path (suggesting Pd's default search paths, and
offering to create those that are missing)
I wouldn't know if, officially, there are such things as "Pd's default search paths". But then it's clear you mean "standard paths", instead of "default search paths", right? Then again, this raises a few issues. Cause, well, under a recent discussion, it was considered that only the "extra" folder was supposed to be the standard folder, so there are not supposed to be other "standard paths". In other words, it ain't *plural*, just a singular *standard path* option, and one that comes always with Pd and doesn't need to be created.
So yeah, what had the need to be created was one folder like that weird and hidden mac folder (~/Library/Pd)... but access to it would still be difficult (as it is invisible). Hence, we have a new folder now (~/Documents/Pd) but that is not a "standard path", just a "regular" path. And I see now "deken" is offering me to create such folders like ~/Library/Pd, after a long discussion that led to the idea we shouldn't use them no more. See this: https://github.com/pure-data/pure-data/pull/139
I know I keep bringing this up here and there, but I think it's a very important detail that can cause many confusions and there is still a lot of inconclusiveness out there, and we're not doing much about it and letting the confusion grow. Now, I was also one of the people who was requesting such a feature several times in Deken, it's all I ever wanted, but the game has really changed because of such recent discussions.
So now we can finally easily create this folder, but it is still invisible and inaccessible to newbies, so not much advantage there. Cause if you need to know how to navigate to that folder, you also know how to create it. So this partially fixes the issue. What was needed there was create it and easily navigate to it, but instead, it was just easier to go to a new folder instead, like ~/Documents/Pd - as we did!
So we have this new standard now that was designed exactly to fix this issue. So this new feature is pointless now, as a new solution (using ~/Documents/Pd) was made, so it is trying to fix an issue (but not in fully fixing it) that has already been fixed and has been in use since 0.48-0! But more importantly, this extra folder has been explicitly declared as a non intentional extra "standard path". See how much confusion this promotes?
So, given all that, I'm even suggesting a Pull Request to clear this up for good, it's here: https://github.com/pure-data/pure-data/pull/183
See also: https://github.com/pure-data/pure-data/issues/184 which discusses the behaviour of [declare] and how we could just use "-path" and forget about "-stdpath"
And leaving "~/Library/Pd" aside, the other extra standard path option here on the mac: "/Library/Pd" doesn't even get created with the new deken plugin, I figure because it may require admin powers, so it doesn't really help either.
Now, I don't know how the plugin works, but I may assume it gets these paths from Pd, so maybe if my Pull Request gets accepted, no change needs to be made in the Deken plugin and it'll just stop showing them...
Anyway, what I see from this update with this issue is that we have added more unnecessary complexity. Things were cleaner and simpler before. But well, I don't consider this a "deken" issue, but a deeper Pd issue that is popping up in deken and other different places.
That is to say that I'm really happy with the new improvements in deken, congratulations, it is quite exciting!
cheers
2018-03-08 13:09 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
we are proud to announce a major overhaul of the deken fileformat.
TL;DR to download new deken packages, you will need at least version v0.3.0 of the deken-plugin (Pd-0.48-1 includes deken-v0.2.4). When searching externals with an old (incompatible) version of the plugin, you will always find a suggestion to install the new plugin with something like:
deken-plugin/0.3.0 (Deken externals downloader - REQUIRED FOR NEW PACKAGES)
once you have installed the new version (and/or Pd includes a compatible version), the nagging will stop :-)
# fileformat
the new fileformat fixes a number of issues we had with the existing one. things that are better:
- cool filename extension '.dek'
- consistent archival options for all platforms (ZIP!)
- proper detection of the version string for all libraries (even if the
library has a weird name like "a-v12"
- support for double-precision externals (once Pd supports that!)
- extensible
# Pd-integration the updated "deken-plugin" has a number of nifty features, you don't want to miss:
- support for the new fileformat
- support for the old (legacy) fileformat
- (optionally) uninstall libraries before re-installing them
- (optionally) show a README that is included in the package on
successful installation
- set installation path (suggesting Pd's default search paths, and
offering to create those that are missing)
- (optionally) hides the search-results for incompatible platforms
- (optionally) overrides the "compatible" Pd-architecture
- nice preferences
- bugfixes
- much more
# Developer tools if you are a developer of libraries, we have also updated our 'deken' cmdline tool. things you always wanted to have and which are now free:
- support for the new fileformat (default)
- support for the old (legacy) fileformat
- better detection of binary architectures
- better detection of included sources
- (experimental) support for double-precision externals
- pre-compiled & self-contained Windows binaries
- bugfixes
- much more
if you want to know more, see
- http://puredata.info/downloads/deken/releases/0.3.0/
- https://lists.puredata.info/pipermail/pd-dev/2018-02/021513.html
- https://github.com/pure-data/deken/issues/161
i have submitted also submitted a Pull-Request to include the new deken-plugin into Pd proper:
and another Pull-Request for Pd that is required to make the double-precision detection work:
happy patching. fgm,asdr IOhannes
Pd-announce mailing list Pd-announce@lists.iem.at https://lists.puredata.info/listinfo/pd-announce
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
At the risk of not being helpful to the issue by adding another opinion, I disagree. Or rather: I do not really follow you. I don't see any problem with deken installing into a hidden folder. It's a pretty common thing on all OSs. Just a have a look at the contents of ~/Library, %AppData%, ~/.local/ .
You say: "Newbies have troubles finding the folder"
I say: "Newbies shouldn't have to know about it all"
Ideally (in my notion of how things would ideally be), there is nothing to be done manually in that folder. Ideally, deken is a management interface for the user to install, enable, disable, remove libraries. It doesn't matter where it does all at. You would install a library and this is enables you to simply do [declare -std[path|lib] yourlib] to use it in your patch. You shouldn't have to know more. It looks like we're getting closer to that with all the efforts done recently.
Roman
On Don, 2018-03-08 at 14:27 -0300, Alexandre Torres Porres wrote:
- set installation path (suggesting Pd's default search paths, and
offering to create those that are missing)
I wouldn't know if, officially, there are such things as "Pd's default search paths". But then it's clear you mean "standard paths", instead of "default search paths", right? Then again, this raises a few issues. Cause, well, under a recent discussion, it was considered that only the "extra" folder was supposed to be the standard folder, so there are not supposed to be other "standard paths". In other words, it ain't plural, just a singular standard path option, and one that comes always with Pd and doesn't need to be created.
So yeah, what had the need to be created was one folder like that weird and hidden mac folder (~/Library/Pd)... but access to it would still be difficult (as it is invisible). Hence, we have a new folder now (~/Documents/Pd) but that is not a "standard path", just a "regular" path. And I see now "deken" is offering me to create such folders like ~/Library/Pd, after a long discussion that led to the idea we shouldn't use them no more. See this: https://github.com/pure -data/pure-data/pull/139
I know I keep bringing this up here and there, but I think it's a very important detail that can cause many confusions and there is still a lot of inconclusiveness out there, and we're not doing much about it and letting the confusion grow. Now, I was also one of the people who was requesting such a feature several times in Deken, it's all I ever wanted, but the game has really changed because of such recent discussions.
So now we can finally easily create this folder, but it is still invisible and inaccessible to newbies, so not much advantage there. Cause if you need to know how to navigate to that folder, you also know how to create it. So this partially fixes the issue. What was needed there was create it and easily navigate to it, but instead, it was just easier to go to a new folder instead, like ~/Documents/Pd - as we did!
So we have this new standard now that was designed exactly to fix this issue. So this new feature is pointless now, as a new solution (using ~/Documents/Pd) was made, so it is trying to fix an issue (but not in fully fixing it) that has already been fixed and has been in use since 0.48-0! But more importantly, this extra folder has been explicitly declared as a non intentional extra "standard path". See how much confusion this promotes?
So, given all that, I'm even suggesting a Pull Request to clear this up for good, it's here: https://github.com/pure-data/pure-data/pull/1 83
See also: https://github.com/pure-data/pure-data/issues/184 which discusses the behaviour of [declare] and how we could just use "- path" and forget about "-stdpath"
And leaving "~/Library/Pd" aside, the other extra standard path option here on the mac: "/Library/Pd" doesn't even get created with the new deken plugin, I figure because it may require admin powers, so it doesn't really help either.
Now, I don't know how the plugin works, but I may assume it gets these paths from Pd, so maybe if my Pull Request gets accepted, no change needs to be made in the Deken plugin and it'll just stop showing them...
Anyway, what I see from this update with this issue is that we have added more unnecessary complexity. Things were cleaner and simpler before. But well, I don't consider this a "deken" issue, but a deeper Pd issue that is popping up in deken and other different places.
That is to say that I'm really happy with the new improvements in deken, congratulations, it is quite exciting!
cheers
2018-03-08 13:09 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
we are proud to announce a major overhaul of the deken fileformat.
TL;DR to download new deken packages, you will need at least version v0.3.0 of the deken-plugin (Pd-0.48-1 includes deken-v0.2.4). When searching externals with an old (incompatible) version of the plugin, you will always find a suggestion to install the new plugin with something like:
deken-plugin/0.3.0 (Deken externals downloader - REQUIRED FOR NEW PACKAGES)
once you have installed the new version (and/or Pd includes a compatible version), the nagging will stop :-)
# fileformat
the new fileformat fixes a number of issues we had with the existing one. things that are better:
- cool filename extension '.dek'
- consistent archival options for all platforms (ZIP!)
- proper detection of the version string for all libraries (even if
the library has a weird name like "a-v12"
- support for double-precision externals (once Pd supports that!)
- extensible
# Pd-integration the updated "deken-plugin" has a number of nifty features, you don't want to miss:
- support for the new fileformat
- support for the old (legacy) fileformat
- (optionally) uninstall libraries before re-installing them
- (optionally) show a README that is included in the package on
successful installation
- set installation path (suggesting Pd's default search paths, and
offering to create those that are missing)
- (optionally) hides the search-results for incompatible platforms
- (optionally) overrides the "compatible" Pd-architecture
- nice preferences
- bugfixes
- much more
# Developer tools if you are a developer of libraries, we have also updated our 'deken' cmdline tool. things you always wanted to have and which are now free:
- support for the new fileformat (default)
- support for the old (legacy) fileformat
- better detection of binary architectures
- better detection of included sources
- (experimental) support for double-precision externals
- pre-compiled & self-contained Windows binaries
- bugfixes
- much more
if you want to know more, see
- http://puredata.info/downloads/deken/releases/0.3.0/
- https://lists.puredata.info/pipermail/pd-dev/2018-02/021513.html
- https://github.com/pure-data/deken/issues/161
i have submitted also submitted a Pull-Request to include the new deken-plugin into Pd proper:
and another Pull-Request for Pd that is required to make the double-precision detection work:
happy patching. fgm,asdr IOhannes
Pd-announce mailing list Pd-announce@lists.iem.at https://lists.puredata.info/listinfo/pd-announce
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list
2018-03-08 17:44 GMT-03:00 Roman Haefeli reduzent@gmail.com:
At the risk of not being helpful to the issue by adding another opinion, I disagree. Or rather: I do not really follow you.
That's quite possible, when it comes to me :/
I don't see any problem with deken installing into a hidden folder. It's a pretty common thing on all OSs. Just a have a look at the contents of ~/Library, %AppData%, ~/.local/ .
Yeah, that's not really the point. Perhaps this needs yet more contextualization. The idea that deken should create non existing (but needed/relevant) folders is old. It comes from a resistance that Pd should create such folders automatically, so, as a solution, you could do that inside Deken, and Pd wouldn't impose the creation of such folders.
A further aggravating factor is that one of such supposedly needed/relevant folders, in macOS, became hidden since 10.6, and this would be " ~/Library/Pd". So it became quite inconvenient and counterproductive, so we needed a better default place to keep externals.
Now, well, does Pd have files somewhere inside ~/Library? Yeah, but where? In ~/Library/Preferences. Does Pd need a "Pd" folder inside ~/Library for its documents? No, to the extent that Pd doesn't even create a folder there on its own there...
And do we need Pd documents and externals in hidden places? Does it have any advantage? No, it doesn't. And in fact, such folder wasn't chosen because it was hidden. It became hidden and inconvenient. It's not that having a hidden folder for externals in macOS was intended by design and principle in the first place.
You say: "Newbies have troubles finding the folder"
I say: "Newbies shouldn't have to know about it all"
What is the advantage of keeping externals in a hidden folder so people can not even have a look at it and browse through them?
Ideally (in my notion of how things would ideally be), there is nothing
to be done manually in that folder. Ideally, deken is a management interface for the user to install, enable, disable, remove libraries.
But it doesn't do all that, for instance, it doesn't delete/remove libraries. And maybe it doesn't have to. Why does it have to do everything, if there are many things you can easily do manually, like a simple thing such as delete a folder. What would be the advantage of hiding it and having a framework to do it for you?
And if you want to have a hidden folder if you wish, you can. Just configure Pd and deken to use a hidden folder of your choice. It's just that there is nothing special about ~/Library/Pd, it's quite arbitrary...
And anyway, what came out of an old discussion is that we should indeed have a new and visible folder for externals. Hence ~/Documents/Pd, a visible and easily accessible folder, instead of ~/Library/Pd, an inconvenient hidden one. Again, this solved all the issues. We've been through all that before. Same concern about Pd not adding ~/Documents/Pd automatically was solved by now prompting the user when it is first launched, and then creates it for you.
So why are we giving this step back? Why are we concerned in making it easier to manage that hidden folder that Pd doesn't create for you? What is special about it? If we're going for friendliness, my point was not that we should avoid, by principle, hidden folders, it was just that this had already been sorted and we do have a new, better, and user friendly procedure since 0.48-0! Doing this now only adds up complexity and confusion, and it isn't even a full solution. Ok, so now you can at least create the folder, but how can you access it? If we're going to that direction, maybe deken should open that folder too for us...
There's no point in trying to fix something that has been already fixed again in a different way. And please understand that I was one that was asking for such a deken feature in the first place, it's just that things have changed and we already have a different outcome.
Unless... unless such a folder is indeed needed and special by design. But it isn't. We've also been through that. I also thought it was supposed to be special, namely an additional "standard path", and that Pd needed and had such standard paths, but it turns out it doesn't! the "standard path" should be only one, the "extra" folder.
So there's really nothing about this that makes sense, as I see it. This is just an ugly kludge, this is just more noise into the system.
You would install a library and this is enables you to simply do [declare
-std[path|lib] yourlib] to use it in your patch.
You're using the "-std" prefix, giving the idea we should install in "standard path", and this is also a confusing topic. We shouldn't, we can pretty much, and should, just use -path and -lib.
It looks like we're getting closer to that with all the efforts done recently.
Yes we are, and I don't wanna sound negative, I'm really glad and excited with all the developments. Like I said before, I consider this to be an issue that's beyond deken. It is an issue that affects deken. Until we're all pretty confused about "standard paths" and "paths", and how to use [declare], and which folder should we install our externals too, deken will also be equally confusing. But I hope we can take this opportunity and sort this out once and for all and get rid of the kludge.
cheers
2018-03-08 14:27 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
Now, I don't know how the plugin works, but I may assume it gets these paths from Pd, so maybe if my Pull Request gets accepted, no change needs to be made in the Deken plugin and it'll just stop showing them...
Yes, that is correct, I tried the Pull Request with the new plugin and it just didn't prompt me for these additional standard paths, so this can be discussed completely in parallel. And by the way, I closed the old one and have a new Pull Request for that - https://github.com/pure-data/pure-data/pull/321
cheers and congratulations again for the great work on Deken
On Thu, 8 Mar 2018 17:09:02 +0100 IOhannes m zmoelnig zmoelnig@iem.at wrote:
we are proud to announce a major overhaul of the deken fileformat.
This is nice.
I have uploaded a few deks now. How do I make them show up in Pd?
I try to send objects.txt by deken upload. It says this: 'jpcex-v0.1-objects.txt' is not an externals archive!
What to do next? (is this file actually needed anymore?) Do I just wait for the server side to index my package?
Thanks
On 03/08/2018 06:39 PM, JP Cimalando via Pd-list wrote:
On Thu, 8 Mar 2018 17:09:02 +0100 IOhannes m zmoelnig zmoelnig@iem.at wrote:
we are proud to announce a major overhaul of the deken fileformat.
This is nice.
I have uploaded a few deks now. How do I make them show up in Pd?
I try to send objects.txt by deken upload. It says this: 'jpcex-v0.1-objects.txt' is not an externals archive!
was this (uploading -objects.txt file with deken) ever possible?
pease file a feature request on https://github.com/pure-data/deken
What to do next? (is this file actually needed anymore?) Do I just wait for the server side to index my package?
no, you still need to manually upload the file. also, i forgot to mention that the object-list files are now supposed to have the extension ".dek.txt" (rather than "-objects.txt").
gfsdr IOhannes
On Fri, 9 Mar 2018 12:43:54 +0100 IOhannes m zmölnig zmoelnig@iem.at wrote:
no, you still need to manually upload the file. also, i forgot to mention that the object-list files are now supposed to have the extension ".dek.txt" (rather than "-objects.txt").
The txt file is to upload by web interface, I have realized that since posting. I used the legacy naming and it still accepted my package happily.
Is the precise naming convention supposed to be: name[version].dek.txt ?
Thanx for the people involved in the dev of this plugin. It is cool to have such a plugin to manage externals.
A few remark on my configuration (Ubuntu 17.10, Pd version 0.48.1) :
large to be handle by my monitor so i can't see the last lines. I need to move the window by pressing the window key.
disappears. I need to make the window bigger to see the button again.
++
Jack
Le 08/03/2018 à 17:09, IOhannes m zmoelnig a écrit :
we are proud to announce a major overhaul of the deken fileformat.
TL;DR to download new deken packages, you will need at least version v0.3.0 of the deken-plugin (Pd-0.48-1 includes deken-v0.2.4). When searching externals with an old (incompatible) version of the plugin, you will always find a suggestion to install the new plugin with something like:
deken-plugin/0.3.0 (Deken externals downloader - REQUIRED FOR NEW PACKAGES)
once you have installed the new version (and/or Pd includes a compatible version), the nagging will stop :-)
# fileformat
the new fileformat fixes a number of issues we had with the existing one. things that are better:
- cool filename extension '.dek'
- consistent archival options for all platforms (ZIP!)
- proper detection of the version string for all libraries (even if the
library has a weird name like "a-v12"
- support for double-precision externals (once Pd supports that!)
- extensible
# Pd-integration the updated "deken-plugin" has a number of nifty features, you don't want to miss:
- support for the new fileformat
- support for the old (legacy) fileformat
- (optionally) uninstall libraries before re-installing them
- (optionally) show a README that is included in the package on
successful installation
- set installation path (suggesting Pd's default search paths, and
offering to create those that are missing)
- (optionally) hides the search-results for incompatible platforms
- (optionally) overrides the "compatible" Pd-architecture
- nice preferences
- bugfixes
- much more
# Developer tools if you are a developer of libraries, we have also updated our 'deken' cmdline tool. things you always wanted to have and which are now free:
- support for the new fileformat (default)
- support for the old (legacy) fileformat
- better detection of binary architectures
- better detection of included sources
- (experimental) support for double-precision externals
- pre-compiled & self-contained Windows binaries
- bugfixes
- much more
if you want to know more, see
- http://puredata.info/downloads/deken/releases/0.3.0/
- https://lists.puredata.info/pipermail/pd-dev/2018-02/021513.html
- https://github.com/pure-data/deken/issues/161
i have submitted also submitted a Pull-Request to include the new deken-plugin into Pd proper:
and another Pull-Request for Pd that is required to make the double-precision detection work:
happy patching. fgm,asdr IOhannes
Pd-announce mailing list Pd-announce@lists.iem.at https://lists.puredata.info/listinfo/pd-announce
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 03/09/2018 02:46 PM, Jack wrote:
Thanx for the people involved in the dev of this plugin. It is cool to have such a plugin to manage externals.
A few remark on my configuration (Ubuntu 17.10, Pd version 0.48.1) :
- When I click the button "Preferences", the preferences window is to
large to be handle by my monitor so i can't see the last lines. I need to move the window by pressing the window key.
hmm, well. either you have a very small screen, or you have many many Pd search paths added. i think the later indicates an issue with your workflow (though i guess that this is because deken keeps asking you to add libraries to your search path; which is *really* an issue, although it is just a workaround for Pd issue)
in any case, the paths section should get a vertical scrollbar to prevent such issues.
- If the mouse cursor goes over results, the preferences button
disappears. I need to make the window bigger to see the button again.
you could also just wait. the status output (which hides the preferences button) disappears after a couple of seconds.
but yes, this is an issue.
please file (separate) bug-reports for both issues on https://github.com/pure-data/deken/issues
gfamrds IOhannes
Le 09/03/2018 à 20:37, IOhannes m zmölnig a écrit :
On 03/09/2018 02:46 PM, Jack wrote:
Thanx for the people involved in the dev of this plugin. It is cool to have such a plugin to manage externals.
A few remark on my configuration (Ubuntu 17.10, Pd version 0.48.1) :
- When I click the button "Preferences", the preferences window is to
large to be handle by my monitor so i can't see the last lines. I need to move the window by pressing the window key.
hmm, well. either you have a very small screen, or you have many many Pd search paths added.
Yep, the last option is good.
i think the later indicates an issue with your workflow (though i guess that this is because deken keeps asking you to add libraries to your search path; which is *really* an issue, although it is just a workaround for Pd issue)
Maybe, i have to clean my .pdsettings.
in any case, the paths section should get a vertical scrollbar to prevent such issues.
Yes !
- If the mouse cursor goes over results, the preferences button
disappears. I need to make the window bigger to see the button again.
you could also just wait. the status output (which hides the preferences button) disappears after a couple of seconds.
OK, just test it and you are right, but 5 seconds it's very long !
but yes, this is an issue.
please file (separate) bug-reports for both issues on https://github.com/pure-data/deken/issues
OK, done. ++
Jack
gfamrds IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 09/03/18 00:09, IOhannes m zmoelnig wrote:
we are proud to announce a major overhaul of the deken fileformat.
Great work, thanks for your efforts!
Cheers,
Chris.