Re: [PD] How to declare custom libraries in abstractions
2018-04-13 17:03 GMT-03:00 José Rafael Subía Valdez : > > > so if let's say "cyclone" decides to compile it into one file, I am not > sure if objects created with [library/object] in a patch will > successfully create. > ok, so, as of now, cyclone officially needs to be loaded only as a library, but all this does is that it automatically adds cyclone's path to Pd's search paths, so you can load the majority of objects without the "cyclone/" prefix. Please note the commonly neglected fact that cyclone needs to load as a library in order to load the non alphanumeric objects. Having said all that, I can say cyclone won't likely ever decide to compile as a single file, I think we reached the perfect spot here. cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] How to declare custom libraries in abstractions
2018-04-14 17:39 GMT-03:00 IOhannes m zmölnig : > On 04/14/2018 03:16 AM, Alexandre Torres Porres wrote: > > Gem is special, as it adds its own path to Pd's search path and the user > shouldn't manually do that. > Wow! Nice to know you can do that. I guess we can figure that out and do the same for cyclone, so we can instruct people to only add it to the startup or using [declare -lib cyclone] and not worry about adding to the path. Any hints on how to do that are welcome. thanks ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] How to declare custom libraries in abstractions
On 04/14/2018 03:16 AM, Alexandre Torres Porres wrote: > If a library like GEM has abstractions, you need to both add it to the > paths AND as a a library. Gem is special, as it adds its own path to Pd's search path and the user shouldn't manually do that. fgmards 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] How to declare custom libraries in abstractions
Sure, I guess I didn't expressed well myself. By being either "one or another", I meant that you'd only need to either add it to the path or load it as a library. If a library like GEM has abstractions, you need to both add it to the paths AND as a a library. As it is, it wouldn't make sense to compile all code in cyclone as a single binary, for the sake of making things simpler, as you'd still need to install in the same way, by including it in the path and as a library. 2018-04-13 22:06 GMT-03:00 Christof Ressi : > > For now, the only way for cyclone to pick a format would be to compile > it as a single library > > (which implies turning the current abstractions into compiled code) > > all the popular single binary libraries I know (GEM, iemlib and zexy) also > include abstractions. > > > Gesendet: Samstag, 14. April 2018 um 02:17 Uhr > Von: "Alexandre Torres Porres" > An: "José Rafael Subía Valdez" > Cc: "PD list" > Betreff: Re: [PD] How to declare custom libraries in abstractions > > > > 2018-04-13 17:03 GMT-03:00 José Rafael Subía Valdez < > jsubiaval...@gmail.com[mailto:jsubiaval...@gmail.com]>: > Hello list, > > I have a couple of questions or more like "views" on this too. > > 1. the problem with using [library/object] method (when libraries compiled > as one single file) is that you must always include the complete external > library and this, as Liam said, may cause a 2 mb project to extend to 35mb, > to give an example. > > well, when externals are compiled as one single binary pack (a.k.a. > "library"), you cannot load it as "[library/object]", so I don't understand > this point. > > > 2. I am more worried if some libraries are going to change or not to a > single compiled file, in this case, the [library/object] I think becomes > obsolete as the library must be loaded independently. making patches that > were using an old version of the library to cause "couldn't create" error. > > hmm, I guess the common practice nowadays is to offer separate binaries, > and I can't see much motivation for someone who distributes them separately > to change the deal and pack them up together. > > > so if let's say "cyclone" decides to compile it into one file, I am not > sure if objects created with [library/object] in a patch will > successfully create. > > Ok, Cyclone seems to be a unique case. Originally, it was a "library", you > could load the "hammer" library (only control/MAX objects), the "sickle" > library (only signal/MSP objects) or "cyclone" (which loaded both > hammer/sickle plus a set of objects with non alphanumeric names - such as > +=~). In Pd Extended, cyclone got split into separate binaries, although it > still carried the hammer/sickle/cyclone library binaries. In this process, > the non alphanumeric names got a bit "lost to oblivion", as you could load > them if you loaded the "cyclone" library. > > Well, currently, Cyclone keeps the separate binaries but still needs a > "sub library" to load this subset of externals, as it's the only way to > safely load non alphanumeric object names in vanilla. In fact, as it is > now, it has this sub-library, a majority of compiled single binary objects > and also a few abstractions. And abstractions, on the other hand, cannot be > loaded as a "library". Hence, as of now, cyclone cannot be either just a > set of separate binaries or a single binary pack. > > I don't know if there are other hybrid cases like this in the Pd world. > And in my opinion, it would be easier and desirable if a library wasn't > hybrid, just either a binary pack or a set of objects. Unless we have a way > in the future to safely load non alphanumeric objects in Pd vanilla (I > would personally love this as it would "fix" everything). For now, the only > way for cyclone to pick a format would be to compile it as a single library > (which implies turning the current abstractions into compiled code). But I > don't think there are big chances for this to happen. > > cheers > ___ Pd-list@lists.iem.at > mailing list UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list[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] How to declare custom libraries in abstractions
> For now, the only way for cyclone to pick a format would be to compile it as > a single library > (which implies turning the current abstractions into compiled code) all the popular single binary libraries I know (GEM, iemlib and zexy) also include abstractions. Gesendet: Samstag, 14. April 2018 um 02:17 Uhr Von: "Alexandre Torres Porres" An: "José Rafael Subía Valdez" Cc: "PD list" Betreff: Re: [PD] How to declare custom libraries in abstractions 2018-04-13 17:03 GMT-03:00 José Rafael Subía Valdez mailto:jsubiaval...@gmail.com]>: Hello list, I have a couple of questions or more like "views" on this too. 1. the problem with using [library/object] method (when libraries compiled as one single file) is that you must always include the complete external library and this, as Liam said, may cause a 2 mb project to extend to 35mb, to give an example. well, when externals are compiled as one single binary pack (a.k.a. "library"), you cannot load it as "[library/object]", so I don't understand this point. 2. I am more worried if some libraries are going to change or not to a single compiled file, in this case, the [library/object] I think becomes obsolete as the library must be loaded independently. making patches that were using an old version of the library to cause "couldn't create" error. hmm, I guess the common practice nowadays is to offer separate binaries, and I can't see much motivation for someone who distributes them separately to change the deal and pack them up together. so if let's say "cyclone" decides to compile it into one file, I am not sure if objects created with [library/object] in a patch will successfully create. Ok, Cyclone seems to be a unique case. Originally, it was a "library", you could load the "hammer" library (only control/MAX objects), the "sickle" library (only signal/MSP objects) or "cyclone" (which loaded both hammer/sickle plus a set of objects with non alphanumeric names - such as +=~). In Pd Extended, cyclone got split into separate binaries, although it still carried the hammer/sickle/cyclone library binaries. In this process, the non alphanumeric names got a bit "lost to oblivion", as you could load them if you loaded the "cyclone" library. Well, currently, Cyclone keeps the separate binaries but still needs a "sub library" to load this subset of externals, as it's the only way to safely load non alphanumeric object names in vanilla. In fact, as it is now, it has this sub-library, a majority of compiled single binary objects and also a few abstractions. And abstractions, on the other hand, cannot be loaded as a "library". Hence, as of now, cyclone cannot be either just a set of separate binaries or a single binary pack. I don't know if there are other hybrid cases like this in the Pd world. And in my opinion, it would be easier and desirable if a library wasn't hybrid, just either a binary pack or a set of objects. Unless we have a way in the future to safely load non alphanumeric objects in Pd vanilla (I would personally love this as it would "fix" everything). For now, the only way for cyclone to pick a format would be to compile it as a single library (which implies turning the current abstractions into compiled code). But I don't think there are big chances for this to happen. cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[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] How to declare custom libraries in abstractions
2018-04-13 17:03 GMT-03:00 José Rafael Subía Valdez : > Hello list, > > I have a couple of questions or more like "views" on this too. > > 1. the problem with using [library/object] method (when libraries compiled > as one single file) is that you must always include the complete external > library and this, as Liam said, may cause a 2 mb project to extend to 35mb, > to give an example. > well, when externals are compiled as one single binary pack (a.k.a. " library"), you cannot load it as "[library/object]", so I don't understand this point. 2. I am more worried if some libraries are going to change or not to a > single compiled file, in this case, the [library/object] I think becomes > obsolete as the library must be loaded independently. making patches that > were using an old version of the library to cause "couldn't create" error. > hmm, I guess the common practice nowadays is to offer separate binaries, and I can't see much motivation for someone who distributes them separately to change the deal and pack them up together. > so if let's say "cyclone" decides to compile it into one file, I am not > sure if objects created with [library/object] in a patch will > successfully create. > Ok, Cyclone seems to be a unique case. Originally, it was a "library", you could load the "hammer" library (only control/MAX objects), the "sickle" library (only signal/MSP objects) or "cyclone" (which loaded both hammer/sickle plus a set of objects with non alphanumeric names - such as +=~). In Pd Extended, cyclone got split into separate binaries, although it still carried the hammer/sickle/cyclone library binaries. In this process, the non alphanumeric names got a bit "lost to oblivion", as you could load them if you loaded the "cyclone" library. Well, currently, Cyclone keeps the separate binaries but still needs a "sub library" to load this subset of externals, as it's the only way to safely load non alphanumeric object names in vanilla. In fact, as it is now, it has this sub-library, a majority of compiled single binary objects and also a few abstractions. And abstractions, on the other hand, cannot be loaded as a "library". Hence, as of now, cyclone cannot be either just a set of separate binaries or a single binary pack. I don't know if there are other hybrid cases like this in the Pd world. And in my opinion, it would be easier and desirable if a library wasn't hybrid, just either a binary pack or a set of objects. Unless we have a way in the future to safely load non alphanumeric objects in Pd vanilla (I would personally love this as it would "fix" everything). For now, the only way for cyclone to pick a format would be to compile it as a single library (which implies turning the current abstractions into compiled code). But I don't think there are big chances for this to happen. cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] How to declare custom libraries in abstractions
nice tune :) 2018-04-13 16:51 GMT-03:00 Lucas Cordiviola : > Hi Liam, > > Take a look at this example: ---> http://lucarda.com.ar/lucarda2010b.rar > > I distribute externals in the "externals" folder and also their licenses > (see: data/externals/Licenses/readme.html). > > I only do [declare -path %%]. I'm using some objects from Zexy but from > the v00-extended (single binary ones). > > In this example I only use [ggee/image] and the rest of the externals are > not used. This externals package is what i require for other "Pd Albums" > available on my site. (This is just my unified pkg ) > > PS: Last month I did an especial w64 folder with self-compiled externals > for windows 64-bit. I was lucky that my unified pkg has few externals (and > sources available) and it was easy to compile them with pd-lib-builder. > > Hope it helps, > Lucarda. > > > -- > > Mensaje telepatico asistido por maquinas. > > On 4/13/2018 2:41 PM, Liam Goodacre wrote: > > Thanks Alex, you've pretty much answered all my questions. I have a bit of > confusion though, because for me, [declare] in 0.48 does seem to add custom > search paths (see attached screenshot). Doesn't this contradict what you > said? > > As to whether I should do it or not, I have users telling me that I should > and developers telling me that I shouldn't, which puts me in a bit of a > bind. Ultimately, I'm worried that a complex install process will scare a > lot of new users off, which is why I'm looking for a solution. I've given > up on many computer programs before simply because I couldn't get them to > work in the first 5 minutes; haven't you? > > The previous thread from 2017 seemed to arrive at the conclusion that > there was a compromise to be found by distributing two versions of Context, > one with and one without externals. I've modified this a little in that I > was planning to release one package with externals included and a simple > way of disabling them. The reason for this is simply so that I can avoid > the complication of handling two packages, but I'm willing to be talked > back into the two-package solution if there are compelling reasons. > > Now that you have clarified the difference between declaring via paths and > via [declare], I have another idea. What if I do the following: > >1. Go back to using [library/object] everywhere and [declare] nowhere >(save for Zexy); >2. Include a "cyclone" and "zexy" etc. folder with the relevant >objects in the main Context folder, not in a special "ctx_externals" >folder. > > This way, Context will find the local externals by default, meaning that > the user doesn't have to bother with downloading them. The readme file then > provides simple instructions that if the user doesn't want to use the local > externals, s/he can simply delete the given folders. All of the external > objects in the Context patch, which are given as [library/object], proceed > to search for the relevant object in "PD documents". This seems about as > simple as it ever could be. Or am I wrong? > > Liam > > > *From:* Alexandre Torres Porres > *Sent:* 13 April 2018 15:43 > *To:* Liam Goodacre > *Cc:* PD list > *Subject:* Re: [PD] How to declare custom libraries in abstractions > > 2018-04-13 8:21 GMT-03:00 Alexandre Torres Porres : > > > > 2018-04-13 4:10 GMT-03:00 Liam Goodacre : > > > distributing externals along with an abstraction is bad form like you > said, in my opinion > > >1. Assuming that there is something wrong with the method outlined >above, what is the proper use of [declare] in this instance?* [declare >-lib ctx_externals/zexy -path ctx_externals/cyclone -path >ctx_externals/else ...]* seems to work for me here, but I know that >the use of -path and -lib is changing, so I just want to be sure. > > current behaviour of [declare -path] works for objects in paths related to > the patch, so yeah, this works. And this won't change > > > > So, when do you want to use "libname/external" and when should you just > use "external"? I think this is important to mention and is related to this > question. First, how should you use it? You need to have the parent folder > where the external folders are included to be added to the search path. > Since Pd 0.48, Pd creates a "Pd documents" folder for you and also an > "externals" folder in there, and this folder is automatically added to the > search paths (that is if you just agree to Pd's suggestions when opening > the application for the first ti
Re: [PD] How to declare custom libraries in abstractions
Hello list, I have a couple of questions or more like "views" on this too. 1. the problem with using [library/object] method (when libraries compiled as one single file) is that you must always include the complete external library and this, as Liam said, may cause a 2 mb project to extend to 35mb, to give an example. 2. I am more worried if some libraries are going to change or not to a single compiled file, in this case, the [library/object] I think becomes obsolete as the library must be loaded independently. making patches that were using an old version of the library to cause "couldn't create" error. so if let's say "cyclone" decides to compile it into one file, I am not sure if objects created with [library/object] in a patch will successfully create. so for a while now I have been using declare for my projects, and loading the libs on startup. I always have subfolders in my project that are declared with -path and usually copy externals needed in there. my two cents On Fri, Apr 13, 2018 at 6:41 PM, Liam Goodacre wrote: > Thanks Alex, you've pretty much answered all my questions. I have a bit of > confusion though, because for me, [declare] in 0.48 does seem to add custom > search paths (see attached screenshot). Doesn't this contradict what you > said? > > As to whether I should do it or not, I have users telling me that I should > and developers telling me that I shouldn't, which puts me in a bit of a > bind. Ultimately, I'm worried that a complex install process will scare a > lot of new users off, which is why I'm looking for a solution. I've given > up on many computer programs before simply because I couldn't get them to > work in the first 5 minutes; haven't you? > > The previous thread from 2017 seemed to arrive at the conclusion that > there was a compromise to be found by distributing two versions of Context, > one with and one without externals. I've modified this a little in that I > was planning to release one package with externals included and a simple > way of disabling them. The reason for this is simply so that I can avoid > the complication of handling two packages, but I'm willing to be talked > back into the two-package solution if there are compelling reasons. > > Now that you have clarified the difference between declaring via paths and > via [declare], I have another idea. What if I do the following: > >1. Go back to using [library/object] everywhere and [declare] nowhere >(save for Zexy); >2. Include a "cyclone" and "zexy" etc. folder with the relevant >objects in the main Context folder, not in a special "ctx_externals" > folder. > > This way, Context will find the local externals by default, meaning that > the user doesn't have to bother with downloading them. The readme file then > provides simple instructions that if the user doesn't want to use the local > externals, s/he can simply delete the given folders. All of the external > objects in the Context patch, which are given as [library/object], proceed > to search for the relevant object in "PD documents". This seems about as > simple as it ever could be. Or am I wrong? > > Liam > > > *From:* Alexandre Torres Porres > *Sent:* 13 April 2018 15:43 > *To:* Liam Goodacre > *Cc:* PD list > *Subject:* Re: [PD] How to declare custom libraries in abstractions > > 2018-04-13 8:21 GMT-03:00 Alexandre Torres Porres : > > > > 2018-04-13 4:10 GMT-03:00 Liam Goodacre : > > > distributing externals along with an abstraction is bad form like you > said, in my opinion > > >1. Assuming that there is something wrong with the method outlined >above, what is the proper use of [declare] in this instance?* [declare >-lib ctx_externals/zexy -path ctx_externals/cyclone -path >ctx_externals/else ...]* seems to work for me here, but I know that >the use of -path and -lib is changing, so I just want to be sure. > > current behaviour of [declare -path] works for objects in paths related to > the patch, so yeah, this works. And this won't change > > > > So, when do you want to use "libname/external" and when should you just > use "external"? I think this is important to mention and is related to this > question. First, how should you use it? You need to have the parent folder > where the external folders are included to be added to the search path. > Since Pd 0.48, Pd creates a "Pd documents" folder for you and also an > "externals" folder in there, and this folder is automatically added to the > search paths (that is if you just agree to Pd's suggestions when opening > the application for t
Re: [PD] How to declare custom libraries in abstractions
Hi Liam, Take a look at this example: ---> http://lucarda.com.ar/lucarda2010b.rar I distribute externals in the "externals" folder and also their licenses (see: data/externals/Licenses/readme.html). I only do [declare -path %%]. I'm using some objects from Zexy but from the v00-extended (single binary ones). In this example I only use [ggee/image] and the rest of the externals are not used. This externals package is what i require for other "Pd Albums" available on my site. (This is just my unified pkg ) PS: Last month I did an especial w64 folder with self-compiled externals for windows 64-bit. I was lucky that my unified pkg has few externals (and sources available) and it was easy to compile them with pd-lib-builder. Hope it helps, Lucarda. -- Mensaje telepatico asistido por maquinas. On 4/13/2018 2:41 PM, Liam Goodacre wrote: Thanks Alex, you've pretty much answered all my questions. I have a bit of confusion though, because for me, [declare] in 0.48 does seem to add custom search paths (see attached screenshot). Doesn't this contradict what you said? As to whether I should do it or not, I have users telling me that I should and developers telling me that I shouldn't, which puts me in a bit of a bind. Ultimately, I'm worried that a complex install process will scare a lot of new users off, which is why I'm looking for a solution. I've given up on many computer programs before simply because I couldn't get them to work in the first 5 minutes; haven't you? The previous thread from 2017 seemed to arrive at the conclusion that there was a compromise to be found by distributing two versions of Context, one with and one without externals. I've modified this a little in that I was planning to release one package with externals included and a simple way of disabling them. The reason for this is simply so that I can avoid the complication of handling two packages, but I'm willing to be talked back into the two-package solution if there are compelling reasons. Now that you have clarified the difference between declaring via paths and via [declare], I have another idea. What if I do the following: 1. Go back to using [library/object] everywhere and [declare] nowhere (save for Zexy); 2. Include a "cyclone" and "zexy" etc. folder with the relevant objects in the main Context folder, not in a special "ctx_externals" folder. This way, Context will find the local externals by default, meaning that the user doesn't have to bother with downloading them. The readme file then provides simple instructions that if the user doesn't want to use the local externals, s/he can simply delete the given folders. All of the external objects in the Context patch, which are given as [library/object], proceed to search for the relevant object in "PD documents". This seems about as simple as it ever could be. Or am I wrong? Liam From: Alexandre Torres Porres <mailto:por...@gmail.com> Sent: 13 April 2018 15:43 To: Liam Goodacre Cc: PD list Subject: Re: [PD] How to declare custom libraries in abstractions 2018-04-13 8:21 GMT-03:00 Alexandre Torres Porres mailto:por...@gmail.com>>: 2018-04-13 4:10 GMT-03:00 Liam Goodacre mailto:liamg...@hotmail.com>>: distributing externals along with an abstraction is bad form like you said, in my opinion 1. Assuming that there is something wrong with the method outlined above, what is the proper use of [declare] in this instance? [declare -lib ctx_externals/zexy -path ctx_externals/cyclone -path ctx_externals/else ...] seems to work for me here, but I know that the use of -path and -lib is changing, so I just want to be sure. current behaviour of [declare -path] works for objects in paths related to the patch, so yeah, this works. And this won't change So, when do you want to use "libname/external" and when should you just use "external"? I think this is important to mention and is related to this question. First, how should you use it? You need to have the parent folder where the external folders are included to be added to the search path. Since Pd 0.48, Pd creates a "Pd documents" folder for you and also an "externals" folder in there, and this folder is automatically added to the search paths (that is if you just agree to Pd's suggestions when opening the application for the first time). In macOS, for instance, this is ~/Documents/Pd/externals So, for whatever libraries you include in that folder, for example, you can use the "libname/external" method and it will work. Cause it'll search inside ~/Documents/Pd/externals for the "libname/" subfolder and then the external. Now, if you also add the "libname/" path, even though you already have ~/Documents/Pd/externals as a search path, what you
Re: [PD] How to declare custom libraries in abstractions
Thanks Alex, you've pretty much answered all my questions. I have a bit of confusion though, because for me, [declare] in 0.48 does seem to add custom search paths (see attached screenshot). Doesn't this contradict what you said? As to whether I should do it or not, I have users telling me that I should and developers telling me that I shouldn't, which puts me in a bit of a bind. Ultimately, I'm worried that a complex install process will scare a lot of new users off, which is why I'm looking for a solution. I've given up on many computer programs before simply because I couldn't get them to work in the first 5 minutes; haven't you? The previous thread from 2017 seemed to arrive at the conclusion that there was a compromise to be found by distributing two versions of Context, one with and one without externals. I've modified this a little in that I was planning to release one package with externals included and a simple way of disabling them. The reason for this is simply so that I can avoid the complication of handling two packages, but I'm willing to be talked back into the two-package solution if there are compelling reasons. Now that you have clarified the difference between declaring via paths and via [declare], I have another idea. What if I do the following: 1. Go back to using [library/object] everywhere and [declare] nowhere (save for Zexy); 2. Include a "cyclone" and "zexy" etc. folder with the relevant objects in the main Context folder, not in a special "ctx_externals" folder. This way, Context will find the local externals by default, meaning that the user doesn't have to bother with downloading them. The readme file then provides simple instructions that if the user doesn't want to use the local externals, s/he can simply delete the given folders. All of the external objects in the Context patch, which are given as [library/object], proceed to search for the relevant object in "PD documents". This seems about as simple as it ever could be. Or am I wrong? Liam From: Alexandre Torres Porres Sent: 13 April 2018 15:43 To: Liam Goodacre Cc: PD list Subject: Re: [PD] How to declare custom libraries in abstractions 2018-04-13 8:21 GMT-03:00 Alexandre Torres Porres mailto:por...@gmail.com>>: 2018-04-13 4:10 GMT-03:00 Liam Goodacre mailto:liamg...@hotmail.com>>: distributing externals along with an abstraction is bad form like you said, in my opinion 1. Assuming that there is something wrong with the method outlined above, what is the proper use of [declare] in this instance? [declare -lib ctx_externals/zexy -path ctx_externals/cyclone -path ctx_externals/else ...] seems to work for me here, but I know that the use of -path and -lib is changing, so I just want to be sure. current behaviour of [declare -path] works for objects in paths related to the patch, so yeah, this works. And this won't change So, when do you want to use "libname/external" and when should you just use "external"? I think this is important to mention and is related to this question. First, how should you use it? You need to have the parent folder where the external folders are included to be added to the search path. Since Pd 0.48, Pd creates a "Pd documents" folder for you and also an "externals" folder in there, and this folder is automatically added to the search paths (that is if you just agree to Pd's suggestions when opening the application for the first time). In macOS, for instance, this is ~/Documents/Pd/externals So, for whatever libraries you include in that folder, for example, you can use the "libname/external" method and it will work. Cause it'll search inside ~/Documents/Pd/externals for the "libname/" subfolder and then the external. Now, if you also add the "libname/" path, even though you already have ~/Documents/Pd/externals as a search path, what you have now is the option to not worry about using "libname". But I like using "libname/external" because: 1) it makes it explicit where this object comes from. 2) It avoids possible nameclashes with other externals that have the same name and might be called eariler in the search priority. 3) It doesn't need [declare] in the patch. Currently [declare] doesn't work if you want to call paths from user added paths anyway, so you can't use it if you want to call externals from there. But if https://github.com/pure-data/pure-data/pull/205 is merged, then this changes, and [declare -path] will be able to include subfolders relative to user added paths. For me, this is a crucial feature, as it basically makes [declare] useless for me right now, when I'm including all my externals in ~/Documents/Pd/externals - so I either have to use "libname/external&q
Re: [PD] How to declare custom libraries in abstractions
2018-04-13 8:21 GMT-03:00 Alexandre Torres Porres : > > > 2018-04-13 4:10 GMT-03:00 Liam Goodacre : > >> >> distributing externals along with an abstraction is bad form like you > said, in my opinion > >> >>1. Assuming that there is something wrong with the method outlined >>above, what is the proper use of [declare] in this instance?* [declare >>-lib ctx_externals/zexy -path ctx_externals/cyclone -path >>ctx_externals/else ...]* seems to work for me here, but I know that >>the use of -path and -lib is changing, so I just want to be sure. >> >> current behaviour of [declare -path] works for objects in paths related to > the patch, so yeah, this works. And this won't change > So, when do you want to use "libname/external" and when should you just use "external"? I think this is important to mention and is related to this question. First, how should you use it? You need to have the parent folder where the external folders are included to be added to the search path. Since Pd 0.48, Pd creates a "Pd documents" folder for you and also an "externals" folder in there, and this folder is automatically added to the search paths (that is if you just agree to Pd's suggestions when opening the application for the first time). In macOS, for instance, this is ~/Documents/Pd/externals So, for whatever libraries you include in that folder, for example, you can use the "libname/external" method and it will work. Cause it'll search inside ~/Documents/Pd/externals for the "libname/" subfolder and then the external. Now, if you also add the "libname/" path, even though you already have ~/Documents/Pd/externals as a search path, what you have now is the option to not worry about using "libname". But I like using "libname/external" because: 1) it makes it explicit where this object comes from. 2) It avoids possible nameclashes with other externals that have the same name and might be called eariler in the search priority. 3) It doesn't need [declare] in the patch. Currently [declare] doesn't work if you want to call paths from user added paths anyway, so you can't use it if you want to call externals from there. But if https://github.com/pure-data/pure-data/pull/205 is merged, then this changes, and [declare -path] will be able to include subfolders relative to user added paths. For me, this is a crucial feature, as it basically makes [declare] useless for me right now, when I'm including all my externals in ~/Documents/Pd/externals - so I either have to use "libname/external" or add the external subfolder as well to the user added paths. > I expect that some of you will bring up the point that distributing >> externals along with an abstraction is bad form, as it might interfere >> with the user's own versions of the same externals. The solution we >> arrived at in the last thread was to let the user decide whether to have >> Context provide its own externals (basic), or whether to provide them >> manually (advanced). This is what I intend to achieve,. >> > Yeah, it might interfere with other versions and stuff, but the point here maybe is how we want to handle dependencies. And all in one, it just looks like a hideous kludgy and counterproductive strategy, to me. I think ideally we should have an external manager that install missing dependencies, and this has been discussed here. Like, Pd could sense a patch wants an external from cyclone and, if you don't have it, it asks you if you want to download or install it. Yeah, but I don't see anything like that coming right away, maybe something like it, in this direction, some time later. So what to do for now? Well, another deal is that it should be clear for Pd users to handle dependencies and installing externals, so all you need to say is this requires libraries "a, b, c", and they should know how to easily do it and/or you should provide a nice step by step manual on how they need to proceed. But perhaps a nice and straightforward common practice for installing externals in Pd is not yet consolidated, hence all the questions, debate and proposals for improvement. cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] How to declare custom libraries in abstractions
2018-04-13 4:10 GMT-03:00 Liam Goodacre : > Hi all > > You might remember from last year that I wanted to distribute externals > along with an abstraction library (Context) so that new users can download > and get it working in as few clicks as possible, without having to download > a bunch of extra libraries (see the thread: "[PD] repackaging externals > on Deken"). This is in response to many users struggling with the > installation process, and it would seem important if Context is every going > to go up on Deken. > > This week, I've finally gotten around to trying to implement this, but I'm > getting hopelessly confused, since I don't have a good understanding of how > [declare] works and it's function seems to be changing anyway. I've > attempted to outline my questions as clearly as possible, and I would > appreciate if people could reply to them individually. I'm not trying to be > stubborn, it's just that I'm struggling with my understanding here. > > CURRENT SITUATION: > >1. Context relies heavily on externals, namely zexy, cyclone, else, >iemguts, hcs, list-abs, iemmatrix, and flatgui. >2. I have everywhere called externals using the [library/object] >method, ie. [cyclone/iter], avoiding the use of [declare], because I'm >afraid of it. The only time I've use declare is with [declare -stdlib zexy] > > did you know? there's a way to load zexy in the patch as an external, and no need to use [declare -stdlib/-lib], this woks if there is a compiled external like [zexy] with all classes, this works for cyclone too. But this is not true for every library. > OBJECTIVES: > >1. I want all of Context's externals to be distributed and declared >internally. >2. For efficiency, I want only those externals which are used in the >folder, not the whole library (otherwise it takes up around 38mb). >3. For clarity, I want them organized by library in a special >"ctx_externals" folder. So there will be one "ctx_externals/cyclone" >folder containing only the cyclone externals I use, one "externals/else" >folder, etc. > > > QUESTIONS: > >1. The easiest way to achieve this would just be to declare them in >the object names, ie. [ctx_externals/cyclone/iter]. What is wrong with >doing it this way? > > distributing externals along with an abstraction is bad form like you said, in my opinion > >1. Assuming that there is something wrong with the method outlined >above, what is the proper use of [declare] in this instance?* [declare >-lib ctx_externals/zexy -path ctx_externals/cyclone -path >ctx_externals/else ...]* seems to work for me here, but I know that >the use of -path and -lib is changing, so I just want to be sure. > > current behaviour of [declare -path] works for objects in paths related to the patch, so yeah, this works. And this won't change > >1. Again assuming that 1 is wrong, do I need to remove the "library/" >from each of the objects in the patch after using [declare]? (Ie. so >[cyclone/iter] becomes just [iter]). It seems to work with the path still >specified, but I don't know if this is altering the behavior. Removing the >paths in the objects would be a hassle, but I'll do it if there is a > reason. > > no reason to remove them, no technical issue, and you'd make a mess and mix up all externals, which is bad > >1. How many different versions of each external library do I need to >provide to cover all possible uses? Windows, Linux & Mac = 3 versions. Do I >need to also release one for 32bit and one for 64bit, = 6 versions? > > yeah, as much as you can, which is part of why 1 is bad > >1. Is it OK just to put all of these different versions in the same >folder, so that "ctx_externals/cyclone" contains 3 x each external, one for >each OS? Or will this create problems? > > it is ok > I expect that some of you will bring up the point that distributing > externals along with an abstraction is bad form, as it might interfere > with the user's own versions of the same externals. The solution we > arrived at in the last thread was to let the user decide whether to have > Context provide its own externals (basic), or whether to provide them > manually (advanced). This is what I intend to achieve, which leads me to > the next question: > > 6: If I replace *[declare -lib** ctx_externals/zexy -path** > ctx_externals/cyclone > -path ctx_externals/else ...]* in the main Context file with *[declare > -lib zexy -path cyclone -path else ...]*, will it then abandon the > repackaged externals and look instead for whatever externals the user has > installed? > > it won't work with externals the user has installed... YET, see https://github.com/pure-data/pure-data/pull/205 > If not this, then what use of [declare] will switch back to the standard > behavior? > > > I dont understand this question > Thanks for bearing with me here, > > Liam > > ___
[PD] How to declare custom libraries in abstractions
Hi all You might remember from last year that I wanted to distribute externals along with an abstraction library (Context) so that new users can download and get it working in as few clicks as possible, without having to download a bunch of extra libraries (see the thread: "[PD] repackaging externals on Deken"). This is in response to many users struggling with the installation process, and it would seem important if Context is every going to go up on Deken. This week, I've finally gotten around to trying to implement this, but I'm getting hopelessly confused, since I don't have a good understanding of how [declare] works and it's function seems to be changing anyway. I've attempted to outline my questions as clearly as possible, and I would appreciate if people could reply to them individually. I'm not trying to be stubborn, it's just that I'm struggling with my understanding here. CURRENT SITUATION: 1. Context relies heavily on externals, namely zexy, cyclone, else, iemguts, hcs, list-abs, iemmatrix, and flatgui. 2. I have everywhere called externals using the [library/object] method, ie. [cyclone/iter], avoiding the use of [declare], because I'm afraid of it. The only time I've use declare is with [declare -stdlib zexy] OBJECTIVES: 1. I want all of Context's externals to be distributed and declared internally. 2. For efficiency, I want only those externals which are used in the folder, not the whole library (otherwise it takes up around 38mb). 3. For clarity, I want them organized by library in a special "ctx_externals" folder. So there will be one "ctx_externals/cyclone" folder containing only the cyclone externals I use, one "externals/else" folder, etc. QUESTIONS: 1. The easiest way to achieve this would just be to declare them in the object names, ie. [ctx_externals/cyclone/iter]. What is wrong with doing it this way? 2. Assuming that there is something wrong with the method outlined above, what is the proper use of [declare] in this instance? [declare -lib ctx_externals/zexy -path ctx_externals/cyclone -path ctx_externals/else ...] seems to work for me here, but I know that the use of -path and -lib is changing, so I just want to be sure. 3. Again assuming that 1 is wrong, do I need to remove the "library/" from each of the objects in the patch after using [declare]? (Ie. so [cyclone/iter] becomes just [iter]). It seems to work with the path still specified, but I don't know if this is altering the behavior. Removing the paths in the objects would be a hassle, but I'll do it if there is a reason. 4. How many different versions of each external library do I need to provide to cover all possible uses? Windows, Linux & Mac = 3 versions. Do I need to also release one for 32bit and one for 64bit, = 6 versions? 5. Is it OK just to put all of these different versions in the same folder, so that "ctx_externals/cyclone" contains 3 x each external, one for each OS? Or will this create problems? I expect that some of you will bring up the point that distributing externals along with an abstraction is bad form, as it might interfere with the user's own versions of the same externals. The solution we arrived at in the last thread was to let the user decide whether to have Context provide its own externals (basic), or whether to provide them manually (advanced). This is what I intend to achieve, which leads me to the next question: 6: If I replace [declare -lib ctx_externals/zexy -path ctx_externals/cyclone -path ctx_externals/else ...] in the main Context file with [declare -lib zexy -path cyclone -path else ...], will it then abandon the repackaged externals and look instead for whatever externals the user has installed? If not this, then what use of [declare] will switch back to the standard behavior? Thanks for bearing with me here, Liam ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
