Hi all
I'm starting to think about how to distribute the Context sequencer when it is ready (hopefully the day is not very far away). Context is an abstraction, but it relies heavily on externals*. Ideally, I want it up on Deken, but I'm not sure what to do about the external packages. Is it feasible / acceptable to bundle all the externals I'm using into a folder and distribute them along with the main Context package? I'm hoping that this way the whole thing could be downloaded and installed in one click, but I want to make sure that there aren't any complications or license issues. Has external repackaging been done before?
*The external libraries I'm using are:
-cyclone
-zexy
-iemguts (including initbang)
-moocow
-flatgui
-list-abs
Hi Liam,
Hi all,
I'm starting to think about how to distribute the Context sequencer when it is ready (hopefully the day is not very far away). Context is an abstraction, but it relies heavily on externals*. Ideally, I want it up on Deken, but I'm not sure what to do about the external packages. Is it feasible / acceptable to bundle all the externals I'm using into a folder and distribute them along with the main Context package? I'm hoping that this way the whole thing could be downloaded and installed in one click, but I want to make sure that there aren't any complications or license issues. Has external repackaging been done before?
Probably, but it is not very common. In the days of Pd-extended it wasn't very necessary. You could just say; 'works with with pd-extended' and be done with.
Nowadays you have to deal with users which already have some or all of the externals you depend on and others who haven't and don't know how to get them. The luxurious solution would be to make two packages, one with and one without externals. Just all used object binaries in one folder would be ok, as it is not mandatory for the usual licenses to include sources, as long as you clearly specify where to find them and how each is licensed.
Just my opinion, of course, YMMV,
Greetings,
Fred Jan
*The external libraries I'm using are:
-cyclone -zexy -iemguts (including initbang) -moocow -flatgui -list-abs
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi all,
On 20/01/17 03:19, Fred Jan Kraan wrote:
I'm starting to think about how to distribute the Context sequencer when it is ready (hopefully the day is not very far away). Context is an abstraction, but it relies heavily on externals*. Ideally, I want it up on Deken, but I'm not sure what to do about the external packages.
The best solution to this is currently vapourware.
It would work like Python's requirements.txt, Node's package.json, Ruby's gemspec etc. where you could specify the other packages (externals/abstractions) that your package depends on. This could be done in a pd META patch or a textfile or whatever.
A user can then choose to install those dependencies into the directory of their current patch, or to their pd-externals directory.
As for your situation - I would like the dependencies somewhere obvious and tell the user they will need to install them.
Cheers,
Chris.
On 01/20/2017 03:50 AM, Chris McCormick wrote:
The best solution to this is currently vapourware.
It would work like Python's requirements.txt
right.
in the meantime i was thinking about extended deken to display a README (if present) after unzipping the package. this would at least allow to communicate the need to install additional libraries to the end user.
dmas IOhannes
On 21/01/17 02:30, IOhannes m zmölnig wrote:
in the meantime i was thinking about extended deken to display a README
Sounds cool. Or it could open "README.pd".
Cheers,
Chris.
In the early days of Raspberry Pi I has a need to redistribute a few externals with PicoJockey, an ARMv6 targeted version of SliceJockey, because Pd-extended did not explicitly support the platform. PicoJockey includes a source tree with subsets of some external libraries plus a custom build system, and a binary build for ARMv6.
This was in the pre-deken era, and while it would be technically possible to distribute PicoJockey (or any Pd project) in such a format via deken, I seriously doubt whether that it is a good idea. Libraries in deken are versioned, and so would be a project that depends on libraries. A project can only specify it's own version in the deken interface. Now imagine a project silently installs unspecified versions of other packages, or subsets thereof? Even when they reside in a subtree of the project, they will conflict with 'official' versions if not identical. This can be a source of confusion and frustration no matter how well you know Pd.
I perfectly understand your desire for a 'one click buy', Liam. That's what I wanted for SliceJockey and PicoJockey as well. It's good for your project and also for the reputation of Pd when things work out of the box. But we have to recognize the fragility of a dependency chain. Even in the heyday of Pd-extended a library update could wreck your 'one click' project and leave people puzzled why it stopped working. In my experience, a Pd project with 'app convenience' is an illusion that can hold for only a while. When a project suggests to be self-containing, users are unaware of dependencies and clueless if something breaks.
Externals are plugins no matter how they are distributed. Be sure to accurately and conspiciously document all dependencies of your project, on your project page and in the distribution. Then if something breaks, people will hopefully remember to check dependencies and come back to your project page for info or updates. Some dependencies are more susceptible to break than others (e.g. unmaintained / orphaned / complicated / debated / forked libs).
You could use various distribution methods according to target audience and release cycle. Why not start with an alpha test release for vanilla + deken? If your project provides clear dependency statements and include mechanisms like [declare] objects, your alpha testers should be settled with a few deken clicks instead of just one. If not... oh yeah... now I remember your problem with one external not being up to date in deken. Is that a consideration for 'repackaging'?
Katja
On Wed, Jan 18, 2017 at 5:12 AM, Liam Goodacre liamg_uw@hotmail.com wrote:
Hi all
I'm starting to think about how to distribute the Context sequencer when it is ready (hopefully the day is not very far away). Context is an abstraction, but it relies heavily on externals*. Ideally, I want it up on Deken, but I'm not sure what to do about the external packages. Is it feasible / acceptable to bundle all the externals I'm using into a folder and distribute them along with the main Context package? I'm hoping that this way the whole thing could be downloaded and installed in one click, but I want to make sure that there aren't any complications or license issues. Has external repackaging been done before?
*The external libraries I'm using are:
-cyclone
-zexy
-iemguts (including initbang)
-moocow
-flatgui
-list-abs
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Dear all:
Thanks for the detailed responses. My main interest here is, as Katja mentioned, the desire for a one-click-buy option (minus the "buy"). A secondary concern is that some future release of an external will change somehow break the patch, although this doesn't seem likely, given how slowly externals tend to move and the general commitment to backwards compatibility.
I like Fred's idea of distributing two packages, one with- and one without externals*. However, I take Katja's point seriously that forcing two versions of the same file on the same disk could become problematic. A quick and dirty solution to this might be to rename all the external files that are uploaded in the Context deken package (ie. "demux.pd_linux" --> "demux2.pd_linux"). This would solve the problem as far as I can see, although it seems somehow wrong. What are people's thoughts about this?
Two other points that are worth mentioning:
Context depends on [initbang] from iemguts 0.2.1. Last time I checked, the deken package for this was only available for Windows, not Linux or Mac.
I haven't used the [declare] object at all, given the warning in the help file against using it in abstractions. Instead, each external is declared in the object name.
*Actually, four versions: one for Windows, Linux Mac, and one without externals.
Liam
From: katja katjavetter@gmail.com Sent: 20 January 2017 15:29 To: Liam Goodacre Cc: PD list Subject: Re: [PD] repackaging externals on Deken
In the early days of Raspberry Pi I has a need to redistribute a few externals with PicoJockey, an ARMv6 targeted version of SliceJockey, because Pd-extended did not explicitly support the platform. PicoJockey includes a source tree with subsets of some external libraries plus a custom build system, and a binary build for ARMv6.
This was in the pre-deken era, and while it would be technically possible to distribute PicoJockey (or any Pd project) in such a format via deken, I seriously doubt whether that it is a good idea. Libraries in deken are versioned, and so would be a project that depends on libraries. A project can only specify it's own version in the deken interface. Now imagine a project silently installs unspecified versions of other packages, or subsets thereof? Even when they reside in a subtree of the project, they will conflict with 'official' versions if not identical. This can be a source of confusion and frustration no matter how well you know Pd.
I perfectly understand your desire for a 'one click buy', Liam. That's what I wanted for SliceJockey and PicoJockey as well. It's good for your project and also for the reputation of Pd when things work out of the box. But we have to recognize the fragility of a dependency chain. Even in the heyday of Pd-extended a library update could wreck your 'one click' project and leave people puzzled why it stopped working. In my experience, a Pd project with 'app convenience' is an illusion that can hold for only a while. When a project suggests to be self-containing, users are unaware of dependencies and clueless if something breaks.
Externals are plugins no matter how they are distributed. Be sure to accurately and conspiciously document all dependencies of your project, on your project page and in the distribution. Then if something breaks, people will hopefully remember to check dependencies and come back to your project page for info or updates. Some dependencies are more susceptible to break than others (e.g. unmaintained / orphaned / complicated / debated / forked libs).
You could use various distribution methods according to target audience and release cycle. Why not start with an alpha test release for vanilla + deken? If your project provides clear dependency statements and include mechanisms like [declare] objects, your alpha testers should be settled with a few deken clicks instead of just one. If not... oh yeah... now I remember your problem with one external not being up to date in deken. Is that a consideration for 'repackaging'?
Katja
On Wed, Jan 18, 2017 at 5:12 AM, Liam Goodacre liamg_uw@hotmail.com wrote:
Hi all
I'm starting to think about how to distribute the Context sequencer when it is ready (hopefully the day is not very far away). Context is an abstraction, but it relies heavily on externals*. Ideally, I want it up on Deken, but I'm not sure what to do about the external packages. Is it feasible / acceptable to bundle all the externals I'm using into a folder and distribute them along with the main Context package? I'm hoping that this way the whole thing could be downloaded and installed in one click, but I want to make sure that there aren't any complications or license issues. Has external repackaging been done before?
*The external libraries I'm using are:
-cyclone
-zexy
-iemguts (including initbang)
-moocow
-flatgui
-list-abs
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list Info Pagehttps://lists.puredata.info/listinfo/pd-list lists.puredata.info Pd (standing for Pure Data) is a Max-like graphical realtime-computermusic language, written by Miller S. Puckette (et al.) This mailinglist is meant as a platform ...
On 01/20/2017 05:22 PM, Liam Goodacre wrote:
A quick and dirty solution to this might be to rename all the external files that are uploaded in the Context deken package (ie. "demux.pd_linux" --> "demux2.pd_linux"). This would solve the problem as far as I can see, although it seems somehow wrong. What are people's thoughts about this?
- appending "2"? and for those objects that already have a "2" appended
(e.g because you took them from a package that included a 3rd party lib), just increment it to "3".hmm...
- renaming the file will just render it unusable: Pd looks for a
specific symbol within the file, and the symbol must match the filename.
Two other points that are worth mentioning:
- Context depends on [initbang] from iemguts 0.2.1. Last time I checked, the deken package for this was only available for Windows, not Linux or Mac.
it's available via Debian for about 19 differenct architectures. and there is a pd-deken-apt package that allows one to install Debian packages via deken (on a Debian system).
anyhow, the reason why i never bothered to upload it was that i figured it would be trivial enough to compile it yourself on anything but w32.
- I haven't used the [declare] object at all, given the warning in the help file against using it in abstractions. Instead, each external is declared in the object name.
then you should upgrade to Pd-0.47 (-1?) and re-read the help-patch.
mgdsar IOhannes
Liam,
Choosing a unique name for an external is indeed the best warranty to avoid conflicts. Not only a future release of a dependency has the potential to break your patch. An old release with a bug or missing feature can do that too! It seems there's no way to force Pd loading the executable that sits in your project tree (I would be very happy if someone can prove me wrong).
So if you're concerned about versions of externals breaking your patch, you could preventively fork them under a different and very specific name. Like 'contxt_demux', 'contxt_initbang'. I won't advise against it because the issue of name clash in pd is serious enough to consider all strategies, but be aware that forking is a bit more involved than simply renaming an existing binary (which won't do the trick as IOhannes has already mentioned).
In either case (modified class names or not) a redistribution of GPL licensed software should include the sources, and when you redistribute a subset you need a customized build system.
Note that I'm not advertising to redistribute, just detailing the consequences. I learn from this discussion too.
Katja
On Fri, Jan 20, 2017 at 5:22 PM, Liam Goodacre liamg_uw@hotmail.com wrote:
Dear all:
Thanks for the detailed responses. My main interest here is, as Katja mentioned, the desire for a one-click-buy option (minus the "buy"). A secondary concern is that some future release of an external will change somehow break the patch, although this doesn't seem likely, given how slowly externals tend to move and the general commitment to backwards compatibility.
I like Fred's idea of distributing two packages, one with- and one without externals*. However, I take Katja's point seriously that forcing two versions of the same file on the same disk could become problematic. A quick and dirty solution to this might be to rename all the external files that are uploaded in the Context deken package (ie. "demux.pd_linux" --> "demux2.pd_linux"). This would solve the problem as far as I can see, although it seems somehow wrong. What are people's thoughts about this?
Two other points that are worth mentioning:
- Context depends on [initbang] from iemguts 0.2.1. Last time I checked,
the deken package for this was only available for Windows, not Linux or Mac.
- I haven't used the [declare] object at all, given the warning in the
help file against using it in abstractions. Instead, each external is declared in the object name.
*Actually, four versions: one for Windows, Linux Mac, and one without externals.
Liam
*From:* katja katjavetter@gmail.com *Sent:* 20 January 2017 15:29 *To:* Liam Goodacre *Cc:* PD list *Subject:* Re: [PD] repackaging externals on Deken
In the early days of Raspberry Pi I has a need to redistribute a few externals with PicoJockey, an ARMv6 targeted version of SliceJockey, because Pd-extended did not explicitly support the platform. PicoJockey includes a source tree with subsets of some external libraries plus a custom build system, and a binary build for ARMv6.
This was in the pre-deken era, and while it would be technically possible to distribute PicoJockey (or any Pd project) in such a format via deken, I seriously doubt whether that it is a good idea. Libraries in deken are versioned, and so would be a project that depends on libraries. A project can only specify it's own version in the deken interface. Now imagine a project silently installs unspecified versions of other packages, or subsets thereof? Even when they reside in a subtree of the project, they will conflict with 'official' versions if not identical. This can be a source of confusion and frustration no matter how well you know Pd.
I perfectly understand your desire for a 'one click buy', Liam. That's what I wanted for SliceJockey and PicoJockey as well. It's good for your project and also for the reputation of Pd when things work out of the box. But we have to recognize the fragility of a dependency chain. Even in the heyday of Pd-extended a library update could wreck your 'one click' project and leave people puzzled why it stopped working. In my experience, a Pd project with 'app convenience' is an illusion that can hold for only a while. When a project suggests to be self-containing, users are unaware of dependencies and clueless if something breaks.
Externals are plugins no matter how they are distributed. Be sure to accurately and conspiciously document all dependencies of your project, on your project page and in the distribution. Then if something breaks, people will hopefully remember to check dependencies and come back to your project page for info or updates. Some dependencies are more susceptible to break than others (e.g. unmaintained / orphaned / complicated / debated / forked libs).
You could use various distribution methods according to target audience and release cycle. Why not start with an alpha test release for vanilla + deken? If your project provides clear dependency statements and include mechanisms like [declare] objects, your alpha testers should be settled with a few deken clicks instead of just one. If not... oh yeah... now I remember your problem with one external not being up to date in deken. Is that a consideration for 'repackaging'?
Katja
On Wed, Jan 18, 2017 at 5:12 AM, Liam Goodacre liamg_uw@hotmail.com wrote:
Hi all
I'm starting to think about how to distribute the Context sequencer when
it
is ready (hopefully the day is not very far away). Context is an abstraction, but it relies heavily on externals*. Ideally, I want it up
on
Deken, but I'm not sure what to do about the external packages. Is it feasible / acceptable to bundle all the externals I'm using into a folder and distribute them along with the main Context package? I'm hoping that this way the whole thing could be downloaded and installed in one click,
but
I want to make sure that there aren't any complications or license
issues.
Has external repackaging been done before?
*The external libraries I'm using are:
-cyclone
-zexy
-iemguts (including initbang)
-moocow
-flatgui
-list-abs
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list Info Page https://lists.puredata.info/listinfo/pd-list lists.puredata.info Pd (standing for Pure Data) is a Max-like graphical realtime-computermusic language, written by Miller S. Puckette (et al.) This mailinglist is meant as a platform ...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Le 21/01/2017 à 11:50, katja a écrit :
Liam,
Choosing a unique name for an external is indeed the best warranty to avoid conflicts. Not only a future release of a dependency has the potential to break your patch. An old release with a bug or missing feature can do that too! It seems there's no way to force Pd loading the executable that sits in your project tree (I would be very happy if someone can prove me wrong).
you can put binary and abstraction in a directory with unique name. if you want to use a [counter] object, you can put it : project_folder/unique_directory_name/counter
for patch that are located in the project_folder, you can load [unique_directory_name/counter]. this way your can be sure that you will not load any "counter" that came with any other lib.
For "egregore source", we choose to start a script with "pd -noprefs", and declare only the mandatory path (that are in our project tree), so that user configuration did not mess our patch.
cyrille
So if you're concerned about versions of externals breaking your patch, you could preventively fork them under a different and very specific name. Like 'contxt_demux', 'contxt_initbang'. I won't advise against it because the issue of name clash in pd is serious enough to consider all strategies, but be aware that forking is a bit more involved than simply renaming an existing binary (which won't do the trick as IOhannes has already mentioned).
In either case (modified class names or not) a redistribution of GPL licensed software should include the sources, and when you redistribute a subset you need a customized build system.
Note that I'm not advertising to redistribute, just detailing the consequences. I learn from this discussion too.
Katja
On Fri, Jan 20, 2017 at 5:22 PM, Liam Goodacre <liamg_uw@hotmail.com mailto:liamg_uw@hotmail.com> wrote:
Dear all: Thanks for the detailed responses. My main interest here is, as Katja mentioned, the desire for a one-click-buy option (minus the "buy"). A secondary concern is that some future release of an external will change somehow break the patch, although this doesn't seem likely, given how slowly externals tend to move and the general commitment to backwards compatibility. I like Fred's idea of distributing two packages, one with- and one without externals*. However, I take Katja's point seriously that forcing two versions of the same file on the same disk could become problematic. A quick and dirty solution to this might be to rename all the external files that are uploaded in the Context deken package (ie. "demux.pd_linux" --> "demux2.pd_linux"). This would solve the problem as far as I can see, although it seems somehow wrong. What are people's thoughts about this? Two other points that are worth mentioning: 1. Context depends on [initbang] from iemguts 0.2.1. Last time I checked, the deken package for this was only available for Windows, not Linux or Mac. 2. I haven't used the [declare] object at all, given the warning in the help file against using it in abstractions. Instead, each external is declared in the object name. *Actually, four versions: one for Windows, Linux Mac, and one without externals. Liam ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ *From:* katja <katjavetter@gmail.com <mailto:katjavetter@gmail.com>> *Sent:* 20 January 2017 15:29 *To:* Liam Goodacre *Cc:* PD list *Subject:* Re: [PD] repackaging externals on Deken In the early days of Raspberry Pi I has a need to redistribute a few externals with PicoJockey, an ARMv6 targeted version of SliceJockey, because Pd-extended did not explicitly support the platform. PicoJockey includes a source tree with subsets of some external libraries plus a custom build system, and a binary build for ARMv6. This was in the pre-deken era, and while it would be technically possible to distribute PicoJockey (or any Pd project) in such a format via deken, I seriously doubt whether that it is a good idea. Libraries in deken are versioned, and so would be a project that depends on libraries. A project can only specify it's own version in the deken interface. Now imagine a project silently installs unspecified versions of other packages, or subsets thereof? Even when they reside in a subtree of the project, they will conflict with 'official' versions if not identical. This can be a source of confusion and frustration no matter how well you know Pd. I perfectly understand your desire for a 'one click buy', Liam. That's what I wanted for SliceJockey and PicoJockey as well. It's good for your project and also for the reputation of Pd when things work out of the box. But we have to recognize the fragility of a dependency chain. Even in the heyday of Pd-extended a library update could wreck your 'one click' project and leave people puzzled why it stopped working. In my experience, a Pd project with 'app convenience' is an illusion that can hold for only a while. When a project suggests to be self-containing, users are unaware of dependencies and clueless if something breaks. Externals are plugins no matter how they are distributed. Be sure to accurately and conspiciously document all dependencies of your project, on your project page and in the distribution. Then if something breaks, people will hopefully remember to check dependencies and come back to your project page for info or updates. Some dependencies are more susceptible to break than others (e.g. unmaintained / orphaned / complicated / debated / forked libs). You could use various distribution methods according to target audience and release cycle. Why not start with an alpha test release for vanilla + deken? If your project provides clear dependency statements and include mechanisms like [declare] objects, your alpha testers should be settled with a few deken clicks instead of just one. If not... oh yeah... now I remember your problem with one external not being up to date in deken. Is that a consideration for 'repackaging'? Katja On Wed, Jan 18, 2017 at 5:12 AM, Liam Goodacre <liamg_uw@hotmail.com <mailto:liamg_uw@hotmail.com>> wrote: > Hi all > > > I'm starting to think about how to distribute the Context sequencer when it > is ready (hopefully the day is not very far away). Context is an > abstraction, but it relies heavily on externals*. Ideally, I want it up on > Deken, but I'm not sure what to do about the external packages. Is it > feasible / acceptable to bundle all the externals I'm using into a folder > and distribute them along with the main Context package? I'm hoping that > this way the whole thing could be downloaded and installed in one click, but > I want to make sure that there aren't any complications or license issues. > Has external repackaging been done before? > > > *The external libraries I'm using are: > > > -cyclone > > -zexy > > -iemguts (including initbang) > > -moocow > > -flatgui > > -list-abs > > > _______________________________________________ > Pd-list@lists.iem.at <mailto: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 Info Page <https://lists.puredata.info/listinfo/pd-list> lists.puredata.info <http://lists.puredata.info> Pd (standing for Pure Data) is a Max-like graphical realtime-computermusic language, written by Miller S. Puckette (et al.) This mailinglist is meant as a platform ... > _______________________________________________ Pd-list@lists.iem.at <mailto: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
On 2017-01-21 15:11, cyrille henry wrote:
for patch that are located in the project_folder, you can load [unique_directory_name/counter]. this way your can be sure that you will not load any "counter" that came with any other lib.
however, as a side-effectm aby [counter] object loaded afterwards will eventually be the one you shipped.
fgamsr IOhannes
Thanks Katja. I tried renaming an external and indeed it does not work!What would be involved in forking an external and would this process be accessible to someone with no coding experience?
Also, can you elaborate on your second-last paragraph? I don't follow this.
From: katja katjavetter@gmail.com Sent: 21 January 2017 10:50 To: Liam Goodacre Cc: PD list Subject: Re: [PD] repackaging externals on Deken
Liam,
Choosing a unique name for an external is indeed the best warranty to avoid conflicts. Not only a future release of a dependency has the potential to break your patch. An old release with a bug or missing feature can do that too! It seems there's no way to force Pd loading the executable that sits in your project tree (I would be very happy if someone can prove me wrong).
So if you're concerned about versions of externals breaking your patch, you could preventively fork them under a different and very specific name. Like 'contxt_demux', 'contxt_initbang'. I won't advise against it because the issue of name clash in pd is serious enough to consider all strategies, but be aware that forking is a bit more involved than simply renaming an existing binary (which won't do the trick as IOhannes has already mentioned).
In either case (modified class names or not) a redistribution of GPL licensed software should include the sources, and when you redistribute a subset you need a customized build system.
Note that I'm not advertising to redistribute, just detailing the consequences. I learn from this discussion too.
Katja
On Fri, Jan 20, 2017 at 5:22 PM, Liam Goodacre <liamg_uw@hotmail.commailto:liamg_uw@hotmail.com> wrote:
Dear all:
Thanks for the detailed responses. My main interest here is, as Katja mentioned, the desire for a one-click-buy option (minus the "buy"). A secondary concern is that some future release of an external will change somehow break the patch, although this doesn't seem likely, given how slowly externals tend to move and the general commitment to backwards compatibility.
I like Fred's idea of distributing two packages, one with- and one without externals*. However, I take Katja's point seriously that forcing two versions of the same file on the same disk could become problematic. A quick and dirty solution to this might be to rename all the external files that are uploaded in the Context deken package (ie. "demux.pd_linux" --> "demux2.pd_linux"). This would solve the problem as far as I can see, although it seems somehow wrong. What are people's thoughts about this?
Two other points that are worth mentioning:
Context depends on [initbang] from iemguts 0.2.1. Last time I checked, the deken package for this was only available for Windows, not Linux or Mac.
I haven't used the [declare] object at all, given the warning in the help file against using it in abstractions. Instead, each external is declared in the object name.
*Actually, four versions: one for Windows, Linux Mac, and one without externals.
Liam
From: katja <katjavetter@gmail.commailto:katjavetter@gmail.com> Sent: 20 January 2017 15:29 To: Liam Goodacre Cc: PD list Subject: Re: [PD] repackaging externals on Deken
In the early days of Raspberry Pi I has a need to redistribute a few externals with PicoJockey, an ARMv6 targeted version of SliceJockey, because Pd-extended did not explicitly support the platform. PicoJockey includes a source tree with subsets of some external libraries plus a custom build system, and a binary build for ARMv6.
This was in the pre-deken era, and while it would be technically possible to distribute PicoJockey (or any Pd project) in such a format via deken, I seriously doubt whether that it is a good idea. Libraries in deken are versioned, and so would be a project that depends on libraries. A project can only specify it's own version in the deken interface. Now imagine a project silently installs unspecified versions of other packages, or subsets thereof? Even when they reside in a subtree of the project, they will conflict with 'official' versions if not identical. This can be a source of confusion and frustration no matter how well you know Pd.
I perfectly understand your desire for a 'one click buy', Liam. That's what I wanted for SliceJockey and PicoJockey as well. It's good for your project and also for the reputation of Pd when things work out of the box. But we have to recognize the fragility of a dependency chain. Even in the heyday of Pd-extended a library update could wreck your 'one click' project and leave people puzzled why it stopped working. In my experience, a Pd project with 'app convenience' is an illusion that can hold for only a while. When a project suggests to be self-containing, users are unaware of dependencies and clueless if something breaks.
Externals are plugins no matter how they are distributed. Be sure to accurately and conspiciously document all dependencies of your project, on your project page and in the distribution. Then if something breaks, people will hopefully remember to check dependencies and come back to your project page for info or updates. Some dependencies are more susceptible to break than others (e.g. unmaintained / orphaned / complicated / debated / forked libs).
You could use various distribution methods according to target audience and release cycle. Why not start with an alpha test release for vanilla + deken? If your project provides clear dependency statements and include mechanisms like [declare] objects, your alpha testers should be settled with a few deken clicks instead of just one. If not... oh yeah... now I remember your problem with one external not being up to date in deken. Is that a consideration for 'repackaging'?
Katja
On Wed, Jan 18, 2017 at 5:12 AM, Liam Goodacre <liamg_uw@hotmail.commailto:liamg_uw@hotmail.com> wrote:
Hi all
I'm starting to think about how to distribute the Context sequencer when it is ready (hopefully the day is not very far away). Context is an abstraction, but it relies heavily on externals*. Ideally, I want it up on Deken, but I'm not sure what to do about the external packages. Is it feasible / acceptable to bundle all the externals I'm using into a folder and distribute them along with the main Context package? I'm hoping that this way the whole thing could be downloaded and installed in one click, but I want to make sure that there aren't any complications or license issues. Has external repackaging been done before?
*The external libraries I'm using are:
-cyclone
-zexy
-iemguts (including initbang)
-moocow
-flatgui
-list-abs
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list Info Pagehttps://lists.puredata.info/listinfo/pd-list lists.puredata.infohttp://lists.puredata.info Pd (standing for Pure Data) is a Max-like graphical realtime-computermusic language, written by Miller S. Puckette (et al.) This mailinglist is meant as a platform ...
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2017-01-23 05:00, Liam Goodacre wrote:
What would be involved in forking an external
I don't think there is any good fool-proof, one-click solution.
but i do think that forking the source code for the sake of distributing is the worst solution.
i would probably:
- specify the requirements in the README
- bundle my library without any dependencies.
- as an *alternative*, bundle my library with a current version of the
3rd-party dependencies in a subfolder of the project.
- use [declare -path ...] to make these libraries usable within my
patches (but make them overridable from outside).
katja is correct that there might be unexpected behaviour if the user installed other versions of your bundled libraries. but i think that in practice this might turn out to be not such a big issue ("let's cross the bridge when we are there").
fgamsdr IOhannes
On Mon, Jan 23, 2017 at 5:00 AM, Liam Goodacre liamg_uw@hotmail.com wrote:
Also, can you elaborate on your second-last paragraph? I don't follow this.
I'm sorry that this discussion got complicated but I may not have grasped your intention. From your original mail:
"Is it feasible / acceptable to bundle all the externals I'm using into a folder and distribute them along with the main Context package?"
That made me think you want to redistribute parts of libraries (only the externals you need), in which case you'd need modified build systems that don't try to build the omitted externals. Or do you mean to bundle complete libraries pre-built for one or more platforms? Or binaries without source & build system (which is not encouraged, see https://github.com/pure-data/deken/issues/88)?
In any case, I still think for an alpha test release you need not realize the one click all inclusive dream yet. Feedback from alpha testers may give you more insights about dependency caveats than you can get from a hypothetical viewpoint. Did you successfully build the missing iemguts libraries? If so you can upload them as deken packages in their own right.
Katja
From: katja katjavetter@gmail.com Sent: 21 January 2017 10:50
To: Liam Goodacre Cc: PD list Subject: Re: [PD] repackaging externals on Deken
Liam,
Choosing a unique name for an external is indeed the best warranty to avoid conflicts. Not only a future release of a dependency has the potential to break your patch. An old release with a bug or missing feature can do that too! It seems there's no way to force Pd loading the executable that sits in your project tree (I would be very happy if someone can prove me wrong).
So if you're concerned about versions of externals breaking your patch, you could preventively fork them under a different and very specific name. Like 'contxt_demux', 'contxt_initbang'. I won't advise against it because the issue of name clash in pd is serious enough to consider all strategies, but be aware that forking is a bit more involved than simply renaming an existing binary (which won't do the trick as IOhannes has already mentioned).
In either case (modified class names or not) a redistribution of GPL licensed software should include the sources, and when you redistribute a subset you need a customized build system.
Note that I'm not advertising to redistribute, just detailing the consequences. I learn from this discussion too.
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:
- Context relies heavily on externals, namely zexy, cyclone, else, iemguts, hcs, list-abs, iemmatrix, and flatgui.
- 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:
- I want all of Context's externals to be distributed and declared internally.
- For efficiency, I want only those externals which are used in the folder, not the whole library (otherwise it takes up around 38mb).
- 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:
- 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?
- 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.
- 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.
- 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?
- 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
2018-04-13 4:10 GMT-03:00 Liam Goodacre liamg_uw@hotmail.com:
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:
- 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:
- 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:
- 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
- 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
- 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
- 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
- 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-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
2018-04-13 8:21 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2018-04-13 4:10 GMT-03:00 Liam Goodacre liamg_uw@hotmail.com:
distributing externals along with an abstraction is bad form like you
said, in my opinion
- 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
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:
- Go back to using [library/object] everywhere and [declare] nowhere (save for Zexy);
- 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 porres@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 <porres@gmail.commailto:porres@gmail.com>:
2018-04-13 4:10 GMT-03:00 Liam Goodacre <liamg_uw@hotmail.commailto:liamg_uw@hotmail.com>:
distributing externals along with an abstraction is bad form like you said, in my opinion
- 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
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:
- Go back to using [library/object] everywhere and [declare] nowhere (save for Zexy);
- 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 porres@gmail.commailto:porres@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 <porres@gmail.commailto:porres@gmail.com>:
2018-04-13 4:10 GMT-03:00 Liam Goodacre <liamg_uw@hotmail.commailto:liamg_uw@hotmail.com>:
distributing externals along with an abstraction is bad form like you said, in my opinion
- 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.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
nice tune :)
2018-04-13 16:51 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.com:
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:
- 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 porres@gmail.com porres@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 porres@gmail.com:
2018-04-13 4:10 GMT-03:00 Liam Goodacre liamg_uw@hotmail.com:
distributing externals along with an abstraction is bad form like you said, in my opinion
- 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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Hello list,
I have a couple of questions or more like "views" on this too.
- 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.
- 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 liamg_uw@hotmail.com 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:
- 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 porres@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 porres@gmail.com:
2018-04-13 4:10 GMT-03:00 Liam Goodacre liamg_uw@hotmail.com:
distributing externals along with an abstraction is bad form like you said, in my opinion
- 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
2018-04-13 17:03 GMT-03:00 José Rafael Subía Valdez jsubiavaldez@gmail.com :
Hello list,
I have a couple of questions or more like "views" on this too.
- 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.
- 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
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" porres@gmail.com An: "José Rafael Subía Valdez" jsubiavaldez@gmail.com Cc: "PD list" pd-list@lists.iem.at Betreff: Re: [PD] How to declare custom libraries in abstractions
2018-04-13 17:03 GMT-03:00 José Rafael Subía Valdez <jsubiavaldez@gmail.com[mailto:jsubiavaldez@gmail.com]>: Hello list, I have a couple of questions or more like "views" on this too.
- 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.
- 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%5Bhttps://lists.puredata.info/l...]
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 christof.ressi@gmx.at:
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" porres@gmail.com An: "José Rafael Subía Valdez" jsubiavaldez@gmail.com Cc: "PD list" pd-list@lists.iem.at Betreff: Re: [PD] How to declare custom libraries in abstractions
2018-04-13 17:03 GMT-03:00 José Rafael Subía Valdez < jsubiavaldez@gmail.com[mailto:jsubiavaldez@gmail.com]>: Hello list,
I have a couple of questions or more like "views" on this too.
- 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.
- 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%5Bhttps:// lists.puredata.info/listinfo/pd-list]
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
2018-04-14 17:39 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
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
2018-04-13 17:03 GMT-03:00 José Rafael Subía Valdez jsubiavaldez@gmail.com :
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
2018-04-13 14:41 GMT-03:00 Liam Goodacre liamg_uw@hotmail.com:
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?
I don't really know what you have there. Let me restate what I sad anyway and show you a screenshot of mine. The [declare] object wth the "-path" flag cannot add a path relative to the user added search paths. By "user added search paths" I mean the paths you manually add in Pd => Preferences.
For example, see my screenshot below (also attached). I have "cyclone" at ~/Documents/Pd/externals/cyclone and I have ~/Documents/Pd/externals as a user added path, so if I do [declare -path cyclone] it can't find it.
Now, if this actually works for you, I don't know.
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?
yup, you're right, this is a good motivation.
Lucarda's way of doing this seems to be the choice you want to go for.
cheers
I figured out what the difference was between mine and Alex's screenshots. In my case, the "custom search location" was also the folder that the patch was saved into. So it was loading an external relative to this, not the custom search folder.
I've uploaded a draft of Context with externals which I hope will work "out of the box". The idea is that if a user wants to use their own externals, they simply delete the relevant folders from the main Context folder, and then the patch goes back to searching for the externals in the regular places. This is based on the assumption that PD searches for externals in the PD folder BEFORE searching in Documents/PD/externals or anywhere else. This appears to be the case on my Linux and Windows machines, but can I count on it always working?
Lucas, thanks for pointing me towards the old Extended binaries for Zexy. I didn't realized that they existed, and it helps to keep the file size small. The Context folder currently has 6mb of binary externals (Linux, Windows & OS), which seems to me like an acceptable cost.
If anyone wants to test it, I'd really appreciate it, in case I've made a mistake. You can download the test branch here, then follow the instruction in the file "externs-test.pd".
https://github.com/LGoodacre/context-sequencer/tree/externs [https://avatars2.githubusercontent.com/u/22167643?s=400&v=4]https://github.com/LGoodacre/context-sequencer/tree/externs
LGoodacre/context-sequencerhttps://github.com/LGoodacre/context-sequencer/tree/externs context-sequencer - Context, a modular sequencer for PD github.com
From: Alexandre Torres Porres porres@gmail.com Sent: 14 April 2018 00:49 To: Liam Goodacre Cc: PD list Subject: Re: [PD] How to declare custom libraries in abstractions
2018-04-13 14:41 GMT-03:00 Liam Goodacre <liamg_uw@hotmail.commailto:liamg_uw@hotmail.com>: 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?
I don't really know what you have there. Let me restate what I sad anyway and show you a screenshot of mine. The [declare] object wth the "-path" flag cannot add a path relative to the user added search paths. By "user added search paths" I mean the paths you manually add in Pd => Preferences.
For example, see my screenshot below (also attached). I have "cyclone" at ~/Documents/Pd/externals/cyclone and I have ~/Documents/Pd/externals as a user added path, so if I do [declare -path cyclone] it can't find it.
[cid:ii_jfylllyv2_162c1641806563a3]
Now, if this actually works for you, I don't know.
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?
yup, you're right, this is a good motivation.
Lucarda's way of doing this seems to be the choice you want to go for.
cheers
Hi Liam,
Amazing patching!
1: When you open this patch, are there any "couldn't create" messages in the console? If so, tell me!
There are not "couldn't create" on "externs-test.pd" but I found:
cyclone/tanh~ ... couldn't create
going through examples that use [docfiles/glock~].
On "12_overlay_examples.pd" & "13_embedding_(takes_several_minutes_to_load!).pd" i get:
<~ ... couldn't create &&~ ... couldn't create <~ ... couldn't create &&~ ... couldn't create <~ ... couldn't create &&~ ... couldn't create
2: Does Context seem to be working correctly? Try resizing it and shifting toggle floats to see.;
Resizing seems to work. I don't know what you mean with "shifting toggle floats to see".
Notes: when using "externs-test.pd" if I click on the *lower left toggle* i get:
0-crxyoff: no such object 0-roff: no such object 0-notsafe: no such object 0-roff2: no such object 0-crxyoff: no such object
But is not the case if I create a new patch and a new [context].
3: If the following objects have created correctly, can you call the helpfiles?
I can not open the help files.
Note: I have temporarily switched off my normal externals folder.
I can not open "00_first_time_tutorial.pd" it crashes Pd.
--
Mensaje telepatico asistido por maquinas.
On 4/14/2018 9:10 AM, Liam Goodacre wrote: I figured out what the difference was between mine and Alex's screenshots. In my case, the "custom search location" was also the folder that the patch was saved into. So it was loading an external relative to this, not the custom search folder.
I've uploaded a draft of Context with externals which I hope will work "out of the box". The idea is that if a user wants to use their own externals, they simply delete the relevant folders from the main Context folder, and then the patch goes back to searching for the externals in the regular places. This is based on the assumption that PD searches for externals in the PD folder BEFORE searching in Documents/PD/externals or anywhere else. This appears to be the case on my Linux and Windows machines, but can I count on it always working?
Lucas, thanks for pointing me towards the old Extended binaries for Zexy. I didn't realized that they existed, and it helps to keep the file size small. The Context folder currently has 6mb of binary externals (Linux, Windows & OS), which seems to me like an acceptable cost.
If anyone wants to test it, I'd really appreciate it, in case I've made a mistake. You can download the test branch here, then follow the instruction in the file "externs-test.pd".
https://github.com/LGoodacre/context-sequencer/tree/externs [https://avatars2.githubusercontent.com/u/22167643?s=400&v=4]https://github.com/LGoodacre/context-sequencer/tree/externs
LGoodacre/context-sequencerhttps://github.com/LGoodacre/context-sequencer/tree/externs context-sequencer - Context, a modular sequencer for PD github.com
Hi Lucas, thanks for testing!
cyclone/tanh~ ... couldn't create
Thanks for spotting this. To avoid needing yet another external, and since this is just a part of the demo, I've replaced this object with [expr~ tanh($v1)].
<~
... couldn't create
&&~
... couldn't create
Again, well spotted. Since I've loaded zexy objects individually, these binops objects don't work. I've found a workaround using [cyclone/lessthan~] and [*~].
0-crxyoff: no such object 0-roff: no such object 0-notsafe: no such object 0-roff2: no such object 0-crxyoff: no such object
This is because I didn't set up some objects in the test file correctly, and it's no worth pursuing.
I can not open "00_first_time_tutorial.pd" it crashes Pd.
That's alarming! Can you try to open the three files that I'm attaching? It's the same patch, but with various objects disabled. If you can get one of them to open then it will narrow down the source of the problem. I'm guessing that test-1.pd will open and the others won't.
context-sequencer - Context, a modular sequencer for PD github.com
On 4/15/2018 5:53 AM, Liam Goodacre wrote:
I'm guessing that test-1.pd will open and the others won't.
Kind of strange:
I can open test-1 so then I try test-2 and it crashes. So I reopen Pd and try test-2 and here it works. (What?) test-3 always crashes.
win8.1:
Problem Event Name: APPCRASH Application Name: pd.com Application Version: 0.0.0.0 Application Timestamp: 00006310 Fault Module Name: crtdll.dll Fault Module Version: 4.0.1183.1 Fault Module Timestamp: 30c91e2d
--
Mensaje telepatico asistido por maquinas.
So Context relies on a share patch which loads with the first instance of Context that you create. It's mostly there just to store certain arrays, but it can sometimes cause confusing behavior like this. Could you try closing PD, opening it again, then opening test-1, closing it, then opening it again? Then close PD and try the same thing with test-2. See if you can spot any patterns.
TBH I don't have much of a clue what is going wrong here. The only thing I can think of is that it's the [textbox] object, as I don't use that very often, basically in this helpfile. Are other help and example files loading correctly? ________________________________ From: Lucas Cordiviola lucarda27@hotmail.com Sent: 15 April 2018 11:52 To: Liam Goodacre; PD list Subject: Re: [PD] CONTEXT V3.0.2 tests. (was: How to declare custom libraries in abstractions)
On 4/15/2018 5:53 AM, Liam Goodacre wrote:
I'm guessing that test-1.pd will open and the others won't.
Kind of strange:
I can open test-1 so then I try test-2 and it crashes. So I reopen Pd and try test-2 and here it works. (What?) test-3 always crashes.
win8.1:
Problem Event Name: APPCRASH Application Name: pd.com Application Version: 0.0.0.0 Application Timestamp: 00006310 Fault Module Name: crtdll.dll Fault Module Version: 4.0.1183.1 Fault Module Timestamp: 30c91e2d
--
Mensaje telepatico asistido por maquinas.
Ok I'll try.
TBH I don't have much of a clue what is going wrong here.
It can be the case that is just this machine (win8.1 not receiving updates), I will try on a win10 with "updates" ASAP. I guess you are not having this issue on your windows and linux machines.
--
Mensaje telepatico asistido por maquinas.
On 4/16/2018 5:11 AM, Liam Goodacre wrote: So Context relies on a share patch which loads with the first instance of Context that you create. It's mostly there just to store certain arrays, but it can sometimes cause confusing behavior like this. Could you try closing PD, opening it again, then opening test-1, closing it, then opening it again? Then close PD and try the same thing with test-2. See if you can spot any patterns.
TBH I don't have much of a clue what is going wrong here. The only thing I can think of is that it's the [textbox] object, as I don't use that very often, basically in this helpfile. Are other help and example files loading correctly? ________________________________ From: Lucas Cordiviola lucarda27@hotmail.commailto:lucarda27@hotmail.com Sent: 15 April 2018 11:52 To: Liam Goodacre; PD list Subject: Re: [PD] CONTEXT V3.0.2 tests. (was: How to declare custom libraries in abstractions)
On 4/15/2018 5:53 AM, Liam Goodacre wrote:
I'm guessing that test-1.pd will open and the others won't.
Kind of strange:
I can open test-1 so then I try test-2 and it crashes. So I reopen Pd and try test-2 and here it works. (What?) test-3 always crashes.
win8.1:
Problem Event Name: APPCRASH Application Name: pd.com Application Version: 0.0.0.0 Application Timestamp: 00006310 Fault Module Name: crtdll.dll Fault Module Version: 4.0.1183.1 Fault Module Timestamp: 30c91e2d
--
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Could you try closing PD, opening it again, then opening test-1, closing it, then opening it again?
This works OK both times.
Then close PD and try the same thing with test-2. See if you can spot any patterns.
This works only the first time.
--
Mensaje telepatico asistido por maquinas.
On 4/16/2018 7:30 AM, Lucas Cordiviola wrote:
Ok I'll try.
TBH I don't have much of a clue what is going wrong here.
It can be the case that is just this machine (win8.1 not receiving updates), I will try on a win10 with "updates" ASAP. I guess you are not having this issue on your windows and linux machines.
--
Mensaje telepatico asistido por maquinas.
On 4/16/2018 5:11 AM, Liam Goodacre wrote: So Context relies on a share patch which loads with the first instance of Context that you create. It's mostly there just to store certain arrays, but it can sometimes cause confusing behavior like this. Could you try closing PD, opening it again, then opening test-1, closing it, then opening it again? Then close PD and try the same thing with test-2. See if you can spot any patterns.
TBH I don't have much of a clue what is going wrong here. The only thing I can think of is that it's the [textbox] object, as I don't use that very often, basically in this helpfile. Are other help and example files loading correctly? ________________________________ From: Lucas Cordiviola lucarda27@hotmail.commailto:lucarda27@hotmail.com Sent: 15 April 2018 11:52 To: Liam Goodacre; PD list Subject: Re: [PD] CONTEXT V3.0.2 tests. (was: How to declare custom libraries in abstractions)
On 4/15/2018 5:53 AM, Liam Goodacre wrote:
I'm guessing that test-1.pd will open and the others won't.
Kind of strange:
I can open test-1 so then I try test-2 and it crashes. So I reopen Pd and try test-2 and here it works. (What?) test-3 always crashes.
win8.1:
Problem Event Name: APPCRASH Application Name: pd.com Application Version: 0.0.0.0 Application Timestamp: 00006310 Fault Module Name: crtdll.dll Fault Module Version: 4.0.1183.1 Fault Module Timestamp: 30c91e2d
--
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Confirmed. I have the same behaviour on an updated win10 machine.
--
Mensaje telepatico asistido por maquinas.
On 4/16/2018 7:36 AM, Lucas Cordiviola wrote: Could you try closing PD, opening it again, then opening test-1, closing it, then opening it again?
This works OK both times.
Then close PD and try the same thing with test-2. See if you can spot any patterns.
This works only the first time.
--
Mensaje telepatico asistido por maquinas.
On 4/16/2018 7:30 AM, Lucas Cordiviola wrote:
Ok I'll try.
TBH I don't have much of a clue what is going wrong here.
It can be the case that is just this machine (win8.1 not receiving updates), I will try on a win10 with "updates" ASAP. I guess you are not having this issue on your windows and linux machines.
--
Mensaje telepatico asistido por maquinas.
On 4/16/2018 5:11 AM, Liam Goodacre wrote: So Context relies on a share patch which loads with the first instance of Context that you create. It's mostly there just to store certain arrays, but it can sometimes cause confusing behavior like this. Could you try closing PD, opening it again, then opening test-1, closing it, then opening it again? Then close PD and try the same thing with test-2. See if you can spot any patterns.
TBH I don't have much of a clue what is going wrong here. The only thing I can think of is that it's the [textbox] object, as I don't use that very often, basically in this helpfile. Are other help and example files loading correctly? ________________________________ From: Lucas Cordiviola lucarda27@hotmail.commailto:lucarda27@hotmail.com Sent: 15 April 2018 11:52 To: Liam Goodacre; PD list Subject: Re: [PD] CONTEXT V3.0.2 tests. (was: How to declare custom libraries in abstractions)
On 4/15/2018 5:53 AM, Liam Goodacre wrote:
I'm guessing that test-1.pd will open and the others won't.
Kind of strange:
I can open test-1 so then I try test-2 and it crashes. So I reopen Pd and try test-2 and here it works. (What?) test-3 always crashes.
win8.1:
Problem Event Name: APPCRASH Application Name: pd.com Application Version: 0.0.0.0 Application Timestamp: 00006310 Fault Module Name: crtdll.dll Fault Module Version: 4.0.1183.1 Fault Module Timestamp: 30c91e2d
--
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Ah, now I get the same behavior! It looks like it's something to do with [msgfile], whose behavior must have changed between the old version of Zexy that I'm using and the current one. Now that I can see it, I should be able to fix it... ________________________________ From: Lucas Cordiviola lucarda27@hotmail.com Sent: 16 April 2018 11:53 To: Liam Goodacre; PD list Subject: Re: [PD] CONTEXT V3.0.2 tests.
Confirmed. I have the same behaviour on an updated win10 machine.
--
Mensaje telepatico asistido por maquinas.
On 4/16/2018 7:36 AM, Lucas Cordiviola wrote: Could you try closing PD, opening it again, then opening test-1, closing it, then opening it again?
This works OK both times.
Then close PD and try the same thing with test-2. See if you can spot any patterns.
This works only the first time.
--
Mensaje telepatico asistido por maquinas.
On 4/16/2018 7:30 AM, Lucas Cordiviola wrote:
Ok I'll try.
TBH I don't have much of a clue what is going wrong here.
It can be the case that is just this machine (win8.1 not receiving updates), I will try on a win10 with "updates" ASAP. I guess you are not having this issue on your windows and linux machines.
--
Mensaje telepatico asistido por maquinas.
On 4/16/2018 5:11 AM, Liam Goodacre wrote: So Context relies on a share patch which loads with the first instance of Context that you create. It's mostly there just to store certain arrays, but it can sometimes cause confusing behavior like this. Could you try closing PD, opening it again, then opening test-1, closing it, then opening it again? Then close PD and try the same thing with test-2. See if you can spot any patterns.
TBH I don't have much of a clue what is going wrong here. The only thing I can think of is that it's the [textbox] object, as I don't use that very often, basically in this helpfile. Are other help and example files loading correctly? ________________________________ From: Lucas Cordiviola lucarda27@hotmail.commailto:lucarda27@hotmail.com Sent: 15 April 2018 11:52 To: Liam Goodacre; PD list Subject: Re: [PD] CONTEXT V3.0.2 tests. (was: How to declare custom libraries in abstractions)
On 4/15/2018 5:53 AM, Liam Goodacre wrote:
I'm guessing that test-1.pd will open and the others won't.
Kind of strange:
I can open test-1 so then I try test-2 and it crashes. So I reopen Pd and try test-2 and here it works. (What?) test-3 always crashes.
win8.1:
Problem Event Name: APPCRASH Application Name: pd.com Application Version: 0.0.0.0 Application Timestamp: 00006310 Fault Module Name: crtdll.dll Fault Module Version: 4.0.1183.1 Fault Module Timestamp: 30c91e2d
--
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2018-04-16 13:15, Liam Goodacre wrote:
Ah, now I get the same behavior! It looks like it's something to do with [msgfile], whose behavior must have changed between the old version of Zexy that I'm using and the current one. Now that I can see it, I should be able to fix it...
the only significant change in [msgfile] in the last few years, would be this one:
Author: IOhannes m zmölnig zmoelnig@users.sourceforge.net Date: Tue Oct 6 13:17:38 2015 +0000
write to canvas-local directory
in sync with [textfile]. the previous use of canvas_makefilename() was for nuffing
could that be the problem? (i haven't followed the actual problem)
fasdrm IOhannes
Yeah, it was something to do with [msgfile] crashing when it was asked to read from the disk. Not worth pursuing anyway, since this is a completely depricated version of Zexy (how frustrating!) I just replaced it with [text] and the problem is solved. I also found that the same problem was occurring in another, much more important part of the patch, so I'm glad we spotted this now.
What other problems have you spotted? I'm eager for feedback! ________________________________ From: Pd-list pd-list-bounces@lists.iem.at on behalf of IOhannes m zmoelnig zmoelnig@iem.at Sent: 16 April 2018 12:42 To: pd-list@lists.iem.at Subject: Re: [PD] CONTEXT V3.0.2 tests.
On 2018-04-16 13:15, Liam Goodacre wrote:
Ah, now I get the same behavior! It looks like it's something to do with [msgfile], whose behavior must have changed between the old version of Zexy that I'm using and the current one. Now that I can see it, I should be able to fix it...
the only significant change in [msgfile] in the last few years, would be this one:
Author: IOhannes m zmölnig zmoelnig@users.sourceforge.net Date: Tue Oct 6 13:17:38 2015 +0000
write to canvas-local directory
in sync with [textfile]. the previous use of canvas_makefilename() was for nuffing
could that be the problem? (i haven't followed the actual problem)
fasdrm IOhannes
2018-04-15 5:53 GMT-03:00 Liam Goodacre liamg_uw@hotmail.com:
Hi Lucas, thanks for testing!
*cyclone/tanh~* *... couldn't create*
Thanks for spotting this. To avoid needing yet another external, and since this is just a part of the demo, I've replaced this object with [expr~ tanh($v1)].
*<~*
*... couldn't create*
*&&~*
*... couldn't create *
Again, well spotted. Since I've loaded zexy objects individually, these binops objects don't work. I've found a workaround using [cyclone/lessthan~] and [*~].
you can also use [expr~ with ">~" and "&&" and stuff
Hi,
I might be late for the answer... I didn't know Context, but I just had a quick look about it and seems interesting concept. I am trying "externs-test.pd". I am using Macbook Pro 2012 with OS X 10.10.5 Yosemite and pd-vanilla 0.48-1
I don't have any "couldn't create" on load
I don't really know yet how to "resizing and shifting toggle floats"
The 4 objects seems to create but none of their help-files open with
"right-click > Help"
- I quit pd, renamed the 8 libraries folder as "_OUT_libraryname/" and
re-opened "externs-test.pd" :
1B. Now I have a lot of "couldn't create" on load :
- demux
- l2s
- sort
- mux
- urn
- else/break &
- msgfile
- iemguts/initbang
- else/fromany
- else/toany
- else/routeall
- s2l
- time
- iemmatrix/matrix
- iemmatrix/mtx_check
... and a few chords that couldn't be created, and missing arrays (0-IDshare)
2B : still don't know how to "resize and shift toggle floats"
3B : [s2l] and [else/toany] don't create. The other two do open their help-patches with "right-click > Help"
NB : i don't have else library installed originally
Hope this helps !
cheers,
Raphaël
2018-04-15 6:26 GMT+02:00 Lucas Cordiviola lucarda27@hotmail.com:
Hi Liam,
Amazing patching!
1: When you open this patch, are there any "couldn't create" messages in the console? If so, tell me!
There are not "couldn't create" on "externs-test.pd" but I found:
- cyclone/tanh~*
*... couldn't create*
going through examples that use [docfiles/glock~].
On "12_overlay_examples.pd" & "13_embedding_(takes_several_minutes_to_load!).pd" i get:
- <~*
*... couldn't create*
- &&~*
*... couldn't create*
- <~*
*... couldn't create*
- &&~*
*... couldn't create*
- <~*
*... couldn't create*
- &&~*
*... couldn't create*
2: Does Context seem to be working correctly? Try resizing it and shifting toggle floats to see.;
Resizing seems to work. I don't know what you mean with "shifting toggle floats to see".
Notes: when using "externs-test.pd" if I click on the *lower left toggle* i get:
*0-crxyoff: no such object* *0-roff: no such object* *0-notsafe: no such object* *0-roff2: no such object* *0-crxyoff: no such object*
But is not the case if I create a new patch and a new [context].
3: If the following objects have created correctly, can you call the helpfiles?
I can not open the help files.
Note: I have temporarily switched off my normal externals folder.
I can not open "00_first_time_tutorial.pd" it crashes Pd.
--
Mensaje telepatico asistido por maquinas.
On 4/14/2018 9:10 AM, Liam Goodacre wrote:
I figured out what the difference was between mine and Alex's screenshots. In my case, the "custom search location" was also the folder that the patch was saved into. So it was loading an external relative to this, not the custom search folder.
I've uploaded a draft of Context with externals which I hope will work "out of the box". The idea is that if a user wants to use their own externals, they simply delete the relevant folders from the main Context folder, and then the patch goes back to searching for the externals in the regular places. This is based on the assumption that PD searches for externals in the PD folder BEFORE searching in Documents/PD/externals or anywhere else. This appears to be the case on my Linux and Windows machines, but can I count on it always working?
Lucas, thanks for pointing me towards the old Extended binaries for Zexy. I didn't realized that they existed, and it helps to keep the file size small. The Context folder currently has 6mb of binary externals (Linux, Windows & OS), which seems to me like an acceptable cost.
If anyone wants to test it, I'd really appreciate it, in case I've made a mistake. You can download the test branch here, then follow the instruction in the file "externs-test.pd".
https://github.com/LGoodacre/context-sequencer/tree/externs https://github.com/LGoodacre/context-sequencer/tree/externs LGoodacre/context-sequencer https://github.com/LGoodacre/context-sequencer/tree/externs context-sequencer - Context, a modular sequencer for PD github.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Thanks Raphaël. It's especially good to know that Context works on Mac, since I haven't tested it there myself.
It looks like you don't have the zexy, iemguts or else installed. You can get them from Help-->Find Externals if you want, but the important thing is that Context works with the built in externals.
If you want to understand about resizing and shifting toggle floats, you can look at helpfiles/GUI_manioulation.pd
Let me know if you have any questions or suggestions!
Liam ________________________________ From: Raphaël Ilias phae.ilias@gmail.com Sent: 19 April 2018 12:56 Cc: Liam Goodacre; PD list Subject: Re: [PD] CONTEXT V3.0.2 tests. (was: How to declare custom libraries in abstractions)
Hi,
I might be late for the answer... I didn't know Context, but I just had a quick look about it and seems interesting concept. I am trying "externs-test.pd". I am using Macbook Pro 2012 with OS X 10.10.5 Yosemite and pd-vanilla 0.48-1
I don't have any "couldn't create" on load
I don't really know yet how to "resizing and shifting toggle floats"
The 4 objects seems to create but none of their help-files open with "right-click > Help"
I quit pd, renamed the 8 libraries folder as "_OUT_libraryname/" and re-opened "externs-test.pd" :
1B. Now I have a lot of "couldn't create" on load :
- demux
- l2s
- sort
- mux
- urn
- else/break &
- msgfile
- iemguts/initbang
- else/fromany
- else/toany
- else/routeall
- s2l
- time
- iemmatrix/matrix
- iemmatrix/mtx_check
... and a few chords that couldn't be created, and missing arrays (0-IDshare)
2B : still don't know how to "resize and shift toggle floats"
3B : [s2l] and [else/toany] don't create. The other two do open their help-patches with "right-click > Help"
NB : i don't have else library installed originally
Hope this helps !
cheers,
Raphaël
2018-04-15 6:26 GMT+02:00 Lucas Cordiviola <lucarda27@hotmail.commailto:lucarda27@hotmail.com>:
Hi Liam,
Amazing patching!
1: When you open this patch, are there any "couldn't create" messages in the console? If so, tell me!
There are not "couldn't create" on "externs-test.pd" but I found:
cyclone/tanh~ ... couldn't create
going through examples that use [docfiles/glock~].
On "12_overlay_examples.pd" & "13_embedding_(takes_several_minutes_to_load!).pd" i get:
<~ ... couldn't create &&~ ... couldn't create <~ ... couldn't create &&~ ... couldn't create <~ ... couldn't create &&~ ... couldn't create
2: Does Context seem to be working correctly? Try resizing it and shifting toggle floats to see.;
Resizing seems to work. I don't know what you mean with "shifting toggle floats to see".
Notes: when using "externs-test.pd" if I click on the *lower left toggle* i get:
0-crxyoff: no such object 0-roff: no such object 0-notsafe: no such object 0-roff2: no such object 0-crxyoff: no such object
But is not the case if I create a new patch and a new [context].
3: If the following objects have created correctly, can you call the helpfiles?
I can not open the help files.
Note: I have temporarily switched off my normal externals folder.
I can not open "00_first_time_tutorial.pd" it crashes Pd.
--
Mensaje telepatico asistido por maquinas.
On 4/14/2018 9:10 AM, Liam Goodacre wrote: I figured out what the difference was between mine and Alex's screenshots. In my case, the "custom search location" was also the folder that the patch was saved into. So it was loading an external relative to this, not the custom search folder.
I've uploaded a draft of Context with externals which I hope will work "out of the box". The idea is that if a user wants to use their own externals, they simply delete the relevant folders from the main Context folder, and then the patch goes back to searching for the externals in the regular places. This is based on the assumption that PD searches for externals in the PD folder BEFORE searching in Documents/PD/externals or anywhere else. This appears to be the case on my Linux and Windows machines, but can I count on it always working?
Lucas, thanks for pointing me towards the old Extended binaries for Zexy. I didn't realized that they existed, and it helps to keep the file size small. The Context folder currently has 6mb of binary externals (Linux, Windows & OS), which seems to me like an acceptable cost.
If anyone wants to test it, I'd really appreciate it, in case I've made a mistake. You can download the test branch here, then follow the instruction in the file "externs-test.pd".
https://github.com/LGoodacre/context-sequencer/tree/externs [https://avatars2.githubusercontent.com/u/22167643?s=400&v=4]https://github.com/LGoodacre/context-sequencer/tree/externs
LGoodacre/context-sequencerhttps://github.com/LGoodacre/context-sequencer/tree/externs context-sequencer - Context, a modular sequencer for PD github.comhttp://github.com
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-- Raphaël Ilias ___________________________________ phae.frhttp://phae.fr 17 places des Halles - Ingrandes 49123 Ingrandes Le Fresne s/ Loire phae.ilias@gmail.commailto:phae.ilias@gmail.com / +33 (0) 6 04 45 79 78 ___________
Good to know that my testing was useful.
However, I don't know if this is important for your testings, but I DO have iemguts and zexy (and cyclone, flatgui, hcs and list-abs... for the ones you use) already installed via Deken (so on Mac OS X now they're put in /Users/myuseraccount/Library/Pd/).
I'll look deeper into Context when I have time, but it looks a huge amount of work.
all the best,
Raphaël
2018-04-19 16:55 GMT+02:00 Liam Goodacre liamg_uw@hotmail.com:
Thanks Raphaël. It's especially good to know that Context works on Mac, since I haven't tested it there myself.
It looks like you don't have the zexy, iemguts or else installed. You can get them from Help-->Find Externals if you want, but the important thing is that Context works with the built in externals.
If you want to understand about resizing and shifting toggle floats, you can look at helpfiles/GUI_manioulation.pd
Let me know if you have any questions or suggestions!
Liam
*From:* Raphaël Ilias phae.ilias@gmail.com *Sent:* 19 April 2018 12:56 *Cc:* Liam Goodacre; PD list *Subject:* Re: [PD] CONTEXT V3.0.2 tests. (was: How to declare custom libraries in abstractions)
Hi,
I might be late for the answer... I didn't know Context, but I just had a quick look about it and seems interesting concept. I am trying "externs-test.pd". I am using Macbook Pro 2012 with OS X 10.10.5 Yosemite and pd-vanilla 0.48-1
I don't have any "couldn't create" on load
I don't really know yet how to "resizing and shifting toggle floats"
The 4 objects seems to create but none of their help-files open with
"right-click > Help"
- I quit pd, renamed the 8 libraries folder as "_OUT_libraryname/" and
re-opened "externs-test.pd" :
1B. Now I have a lot of "couldn't create" on load :
- demux
- l2s
- sort
- mux
- urn
- else/break &
- msgfile
- iemguts/initbang
- else/fromany
- else/toany
- else/routeall
- s2l
- time
- iemmatrix/matrix
- iemmatrix/mtx_check
... and a few chords that couldn't be created, and missing arrays (0-IDshare)
2B : still don't know how to "resize and shift toggle floats"
3B : [s2l] and [else/toany] don't create. The other two do open their help-patches with "right-click > Help"
NB : i don't have else library installed originally
Hope this helps !
cheers,
Raphaël
2018-04-15 6:26 GMT+02:00 Lucas Cordiviola lucarda27@hotmail.com:
Hi Liam,
Amazing patching!
1: When you open this patch, are there any "couldn't create" messages in the console? If so, tell me!
There are not "couldn't create" on "externs-test.pd" but I found:
- cyclone/tanh~*
*... couldn't create*
going through examples that use [docfiles/glock~].
On "12_overlay_examples.pd" & "13_embedding_(takes_several_minutes_to_load!).pd" i get:
- <~*
*... couldn't create*
- &&~*
*... couldn't create*
- <~*
*... couldn't create*
- &&~*
*... couldn't create*
- <~*
*... couldn't create*
- &&~*
*... couldn't create*
2: Does Context seem to be working correctly? Try resizing it and shifting toggle floats to see.;
Resizing seems to work. I don't know what you mean with "shifting toggle floats to see".
Notes: when using "externs-test.pd" if I click on the *lower left toggle* i get:
*0-crxyoff: no such object* *0-roff: no such object* *0-notsafe: no such object* *0-roff2: no such object* *0-crxyoff: no such object*
But is not the case if I create a new patch and a new [context].
3: If the following objects have created correctly, can you call the helpfiles?
I can not open the help files.
Note: I have temporarily switched off my normal externals folder.
I can not open "00_first_time_tutorial.pd" it crashes Pd.
--
Mensaje telepatico asistido por maquinas.
On 4/14/2018 9:10 AM, Liam Goodacre wrote:
I figured out what the difference was between mine and Alex's screenshots. In my case, the "custom search location" was also the folder that the patch was saved into. So it was loading an external relative to this, not the custom search folder.
I've uploaded a draft of Context with externals which I hope will work "out of the box". The idea is that if a user wants to use their own externals, they simply delete the relevant folders from the main Context folder, and then the patch goes back to searching for the externals in the regular places. This is based on the assumption that PD searches for externals in the PD folder BEFORE searching in Documents/PD/externals or anywhere else. This appears to be the case on my Linux and Windows machines, but can I count on it always working?
Lucas, thanks for pointing me towards the old Extended binaries for Zexy. I didn't realized that they existed, and it helps to keep the file size small. The Context folder currently has 6mb of binary externals (Linux, Windows & OS), which seems to me like an acceptable cost.
If anyone wants to test it, I'd really appreciate it, in case I've made a mistake. You can download the test branch here, then follow the instruction in the file "externs-test.pd".
https://github.com/LGoodacre/context-sequencer/tree/externs https://github.com/LGoodacre/context-sequencer/tree/externs LGoodacre/context-sequencer https://github.com/LGoodacre/context-sequencer/tree/externs context-sequencer - Context, a modular sequencer for PD github.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
-- Raphaël Ilias ___________________________________
phae.fr <http://phae.fr>*
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
What do you usually do to use objects from these libraries? All externals objects are declared as [library/object] inside Context, so it it works outside the patch, I don't understand why it wouldn't work inside. Can you for instance create [iemguts/canvasargs] in a regular patch?
From: Raphaël Ilias phae.ilias@gmail.com Sent: 19 April 2018 16:26 To: Liam Goodacre Cc: PD list Subject: Re: [PD] CONTEXT V3.0.2 tests. (was: How to declare custom libraries in abstractions)
Good to know that my testing was useful.
However, I don't know if this is important for your testings, but I DO have iemguts and zexy (and cyclone, flatgui, hcs and list-abs... for the ones you use) already installed via Deken (so on Mac OS X now they're put in /Users/myuseraccount/Library/Pd/).
I'll look deeper into Context when I have time, but it looks a huge amount of work.
all the best,
Raphaël
2018-04-19 16:55 GMT+02:00 Liam Goodacre <liamg_uw@hotmail.commailto:liamg_uw@hotmail.com>: Thanks Raphaël. It's especially good to know that Context works on Mac, since I haven't tested it there myself.
It looks like you don't have the zexy, iemguts or else installed. You can get them from Help-->Find Externals if you want, but the important thing is that Context works with the built in externals.
If you want to understand about resizing and shifting toggle floats, you can look at helpfiles/GUI_manioulation.pd
Let me know if you have any questions or suggestions!
Liam ________________________________ From: Raphaël Ilias <phae.ilias@gmail.commailto:phae.ilias@gmail.com> Sent: 19 April 2018 12:56 Cc: Liam Goodacre; PD list Subject: Re: [PD] CONTEXT V3.0.2 tests. (was: How to declare custom libraries in abstractions)
Hi,
I might be late for the answer... I didn't know Context, but I just had a quick look about it and seems interesting concept. I am trying "externs-test.pd". I am using Macbook Pro 2012 with OS X 10.10.5 Yosemite and pd-vanilla 0.48-1
I don't have any "couldn't create" on load
I don't really know yet how to "resizing and shifting toggle floats"
The 4 objects seems to create but none of their help-files open with "right-click > Help"
I quit pd, renamed the 8 libraries folder as "_OUT_libraryname/" and re-opened "externs-test.pd" :
1B. Now I have a lot of "couldn't create" on load :
- demux
- l2s
- sort
- mux
- urn
- else/break &
- msgfile
- iemguts/initbang
- else/fromany
- else/toany
- else/routeall
- s2l
- time
- iemmatrix/matrix
- iemmatrix/mtx_check
... and a few chords that couldn't be created, and missing arrays (0-IDshare)
2B : still don't know how to "resize and shift toggle floats"
3B : [s2l] and [else/toany] don't create. The other two do open their help-patches with "right-click > Help"
NB : i don't have else library installed originally
Hope this helps !
cheers,
Raphaël
2018-04-15 6:26 GMT+02:00 Lucas Cordiviola <lucarda27@hotmail.commailto:lucarda27@hotmail.com>:
Hi Liam,
Amazing patching!
1: When you open this patch, are there any "couldn't create" messages in the console? If so, tell me!
There are not "couldn't create" on "externs-test.pd" but I found:
cyclone/tanh~ ... couldn't create
going through examples that use [docfiles/glock~].
On "12_overlay_examples.pd" & "13_embedding_(takes_several_minutes_to_load!).pd" i get:
<~ ... couldn't create &&~ ... couldn't create <~ ... couldn't create &&~ ... couldn't create <~ ... couldn't create &&~ ... couldn't create
2: Does Context seem to be working correctly? Try resizing it and shifting toggle floats to see.;
Resizing seems to work. I don't know what you mean with "shifting toggle floats to see".
Notes: when using "externs-test.pd" if I click on the *lower left toggle* i get:
0-crxyoff: no such object 0-roff: no such object 0-notsafe: no such object 0-roff2: no such object 0-crxyoff: no such object
But is not the case if I create a new patch and a new [context].
3: If the following objects have created correctly, can you call the helpfiles?
I can not open the help files.
Note: I have temporarily switched off my normal externals folder.
I can not open "00_first_time_tutorial.pd" it crashes Pd.
--
Mensaje telepatico asistido por maquinas.
On 4/14/2018 9:10 AM, Liam Goodacre wrote: I figured out what the difference was between mine and Alex's screenshots. In my case, the "custom search location" was also the folder that the patch was saved into. So it was loading an external relative to this, not the custom search folder.
I've uploaded a draft of Context with externals which I hope will work "out of the box". The idea is that if a user wants to use their own externals, they simply delete the relevant folders from the main Context folder, and then the patch goes back to searching for the externals in the regular places. This is based on the assumption that PD searches for externals in the PD folder BEFORE searching in Documents/PD/externals or anywhere else. This appears to be the case on my Linux and Windows machines, but can I count on it always working?
Lucas, thanks for pointing me towards the old Extended binaries for Zexy. I didn't realized that they existed, and it helps to keep the file size small. The Context folder currently has 6mb of binary externals (Linux, Windows & OS), which seems to me like an acceptable cost.
If anyone wants to test it, I'd really appreciate it, in case I've made a mistake. You can download the test branch here, then follow the instruction in the file "externs-test.pd".
https://github.com/LGoodacre/context-sequencer/tree/externs [https://avatars2.githubusercontent.com/u/22167643?s=400&v=4]https://github.com/LGoodacre/context-sequencer/tree/externs
LGoodacre/context-sequencerhttps://github.com/LGoodacre/context-sequencer/tree/externs context-sequencer - Context, a modular sequencer for PD github.comhttp://github.com
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-- Raphaël Ilias ___________________________________ phae.frhttp://phae.fr 17 places des Halles - Ingrandes 49123 Ingrandes Le Fresne s/ Loire phae.ilias@gmail.commailto:phae.ilias@gmail.com / +33 (0) 6 04 45 79 78 ___________
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-- Raphaël Ilias ___________________________________ phae.frhttp://phae.fr 17 places des Halles - Ingrandes 49123 Ingrandes Le Fresne s/ Loire phae.ilias@gmail.commailto:phae.ilias@gmail.com / +33 (0) 6 04 45 79 78 ___________
On 2017-01-21 11:50, katja wrote:
Choosing a unique name for an external is indeed the best warranty to avoid conflicts.
the problem is of course to create those "unique" names. "context_initbang" could easily nameclash.
UUID could be used, but has other drawbacks ("091f5a12-43e0-482b-8be1-6e1ee3757cdc" anybody?)
Not only a future release of a dependency has the potential to break your patch. An old release with a bug or missing feature can do that too! It seems there's no way to force Pd loading the executable that sits in your project tree (I would be very happy if someone can prove me wrong).
well iirc, you should be able to force-load a library by using it's "fully" qualified filename.
that is, if you have an object [../context/iemguts/initbang], Pd wouldn't know how to create that, and start its library loading mechanism, eventually finding the ../context/iemguts/initbang.pd_linux file and loading it. doing so will - as a side effect - overwrite the constructor of "initbang", so any [initbang] instantiated therafter will be *this* version. (until Pd encounters an object [../cuntaxt/initbang] overwrite the constructor for "initbang" again).
i haven't tested how (and if) this works with [declare].
fgamsdr IOhannes
On Mon, Jan 23, 2017 at 1:04 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-01-21 11:50, katja wrote:
Not only a future release of a dependency has the potential to break your patch. An old release with a bug or missing feature can do that too! It seems there's no way to force Pd loading the executable that sits in your project tree (I would be very happy if someone can prove me wrong).
well iirc, you should be able to force-load a library by using it's "fully" qualified filename.
that is, if you have an object [../context/iemguts/initbang], Pd wouldn't know how to create that, and start its library loading mechanism, eventually finding the ../context/iemguts/initbang.pd_linux file and loading it. doing so will - as a side effect - overwrite the constructor of "initbang", so any [initbang] instantiated therafter will be *this* version. (until Pd encounters an object [../cuntaxt/initbang] overwrite the constructor for "initbang" again).
Ah cool. So you make the path unambiguous by using the leading slash (i.e. "./<object>" for an object that sits next to the patch, etcetera).
Happy! This method is great for test patches (unit tests, regression tests) where you want to be sure to test the intended build. The overwriting behavior isn't so elegant in some other cases though.
i haven't tested how (and if) this works with [declare].
As far as I could check, [declare] does not have the effect of overwriting a class.
fgamsdr IOhannes
Katja
-
Alexandre Torres Porres -
Chris McCormick -
Christof Ressi -
cyrille henry -
Fred Jan Kraan -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
José Rafael Subía Valdez -
katja -
Liam Goodacre -
Lucas Cordiviola -
Raphaël Ilias