it looks like the future of pd-extended is going to be 'deken'. what to do then about portability?
i make patches for people who don't know a lot about programming. plus they are on Mac, i'm on Windows. one time downloading the right version of Pdext is enough; i can give them my patches and they just run them. when i make changes, new features: there's no hassle for them.
using Vanilla & deken is something else. declaring a library in the patch is not enough. including the library in the patch-package works only on the same type of OS; Windows & Windows, Mac & Mac, (Linux & Linux?).
one method could be a deken-connected feature to automatically
download a declared lib when it's not present.
what about updates or changes in a lib in that case?
the organisation of pd-ext somehow included a kind of gate-keeping,
which resulted in a stable Pd-system.
i'm still using Pdext 42.5 and the included libs a lot (because of the
old machines in my installations). the same libs are functional in
Pdext 43.4.
so one could argue that there's no great need for a portability
design. just download everything that's necessary (and available) and
it will work for quite some time.
? rolf
The GUI port I'm working on for Pd-l2ork should essentially replace Pd-extended. But I still have to get it building on OSX. There will be some inconveniences:* I'm not porting Toxy. (But Pd Vanilla broke support for it anyway.)* Aside from some key GUI externals, I'm only going to port GUI externals "a la carte". That is, if your patches depend on it and it would be burdensome to find a workaround, I'll go ahead and (try to) port it. But in general, all the other externals that ship with Pd-extended should work just fine (and do work atm in Pd-l2ork). -Jonathan
On Wednesday, October 14, 2015 11:22 AM, "rolfm@dds.nl" <rolfm@dds.nl> wrote:
it looks like the future of pd-extended is going to be 'deken'. what to do then about portability?
i make patches for people who don't know a lot about programming. plus they are on Mac, i'm on Windows. one time downloading the right version of Pdext is enough; i can give them my patches and they just run them. when i make changes, new features: there's no hassle for them.
using Vanilla & deken is something else. declaring a library in the patch is not enough. including the library in the patch-package works only on the same type of OS; Windows & Windows, Mac & Mac, (Linux & Linux?).
one method could be a deken-connected feature to automatically download a declared lib when it's not present. what about updates or changes in a lib in that case?
the organisation of pd-ext somehow included a kind of gate-keeping, which resulted in a stable Pd-system. i'm still using Pdext 42.5 and the included libs a lot (because of the old machines in my installations). the same libs are functional in Pdext 43.4. so one could argue that there's no great need for a portability design. just download everything that's necessary (and available) and it will work for quite some time.
? rolf
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
But I still have to get it building on OSX.
Does it mean you already have it for windows?
Will the pd-extended package be versioned as well?
I don't get it, is the "versioned" the "rolling package release" or the "standard release"?
cheers
2015-10-14 13:02 GMT-03:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at
:
The GUI port I'm working on for Pd-l2ork should essentially replace Pd-extended. But I still have to get it building on OSX.
There will be some inconveniences:
- I'm not porting Toxy. (But Pd Vanilla broke support for it anyway.)
- Aside from some key GUI externals, I'm only going to port GUI externals
"a la carte". That is, if your patches depend on it and it would be burdensome to find a workaround, I'll go ahead and (try to) port it.
But in general, all the other externals that ship with Pd-extended should work just fine (and do work atm in Pd-l2ork).
-Jonathan
On Wednesday, October 14, 2015 11:22 AM, "rolfm@dds.nl" rolfm@dds.nl wrote:
it looks like the future of pd-extended is going to be 'deken'. what to do then about portability?
i make patches for people who don't know a lot about programming. plus they are on Mac, i'm on Windows. one time downloading the right version of Pdext is enough; i can give them my patches and they just run them. when i make changes, new features: there's no hassle for them.
using Vanilla & deken is something else. declaring a library in the patch is not enough. including the library in the patch-package works only on the same type of OS; Windows & Windows, Mac & Mac, (Linux & Linux?).
one method could be a deken-connected feature to automatically download a declared lib when it's not present. what about updates or changes in a lib in that case?
the organisation of pd-ext somehow included a kind of gate-keeping, which resulted in a stable Pd-system. i'm still using Pdext 42.5 and the included libs a lot (because of the old machines in my installations). the same libs are functional in Pdext 43.4. so one could argue that there's no great need for a portability design. just download everything that's necessary (and available) and it will work for quite some time.
? rolf
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
That’s why one idea with deken is to install an “extended” meta package which installs most (if not all) of the libs that came with pd-extended. I don’t think it’s too hard to ask a user to open the plugin and install a single package.
Also, the cross platform issue will be fixed in time. Thanks for debugging!
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 14, 2015, at 9:22 AM, rolfm@dds.nl mailto:rolfm@dds.nl wrote:
it looks like the future of pd-extended is going to be 'deken'. what to do then about portability?
i make patches for people who don't know a lot about programming. plus they are on Mac, i'm on Windows. one time downloading the right version of Pdext is enough; i can give them my patches and they just run them. when i make changes, new features: there's no hassle for them.
using Vanilla & deken is something else. declaring a library in the patch is not enough. including the library in the patch-package works only on the same type of OS; Windows & Windows, Mac & Mac, (Linux & Linux?).
one method could be a deken-connected feature to automatically download a declared lib when it's not present. what about updates or changes in a lib in that case?
the organisation of pd-ext somehow included a kind of gate-keeping, which resulted in a stable Pd-system. i'm still using Pdext 42.5 and the included libs a lot (because of the old machines in my installations). the same libs are functional in Pdext 43.4. so one could argue that there's no great need for a portability design. just download everything that's necessary (and available) and it will work for quite some time.
? rolf
Hi Dan, How do you handle versioning?
On Wednesday, October 14, 2015 3:18 PM, Dan Wilcox <danomatika@gmail.com> wrote:
That’s why one idea with deken is to install an “extended” meta package which installs most (if not all) of the libs that came with pd-extended. I don’t think it’s too hard to ask a user to open the plugin and install a single package. Also, the cross platform issue will be fixed in time. Thanks for debugging!
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Oct 14, 2015, at 9:22 AM, rolfm@dds.nl wrote:
it looks like the future of pd-extended is going to be 'deken'. what to do then about portability?
i make patches for people who don't know a lot about programming. plus they are on Mac, i'm on Windows. one time downloading the right version of Pdext is enough; i can give them my patches and they just run them. when i make changes, new features: there's no hassle for them.
using Vanilla & deken is something else. declaring a library in the patch is not enough. including the library in the patch-package works only on the same type of OS; Windows & Windows, Mac & Mac, (Linux & Linux?).
one method could be a deken-connected feature to automatically download a declared lib when it's not present. what about updates or changes in a lib in that case?
the organisation of pd-ext somehow included a kind of gate-keeping, which resulted in a stable Pd-system. i'm still using Pdext 42.5 and the included libs a lot (because of the old machines in my installations). the same libs are functional in Pdext 43.4. so one could argue that there's no great need for a portability design. just download everything that's necessary (and available) and it will work for quite some time.
? rolf
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Well, not specifically me as I haven’t contributed code to deken. Versions are currently handled by the filename format: https://github.com/pure-data/deken#create-and-upload-a-package https://github.com/pure-data/deken#create-and-upload-a-package
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 14, 2015, at 3:07 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Hi Dan, How do you handle versioning?
On Wednesday, October 14, 2015 3:18 PM, Dan Wilcox danomatika@gmail.com wrote:
That’s why one idea with deken is to install an “extended” meta package which installs most (if not all) of the libs that came with pd-extended. I don’t think it’s too hard to ask a user to open the plugin and install a single package.
Also, the cross platform issue will be fixed in time. Thanks for debugging!
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 14, 2015, at 9:22 AM, rolfm@dds.nl mailto:rolfm@dds.nl wrote:
it looks like the future of pd-extended is going to be 'deken'. what to do then about portability?
i make patches for people who don't know a lot about programming. plus they are on Mac, i'm on Windows. one time downloading the right version of Pdext is enough; i can give them my patches and they just run them. when i make changes, new features: there's no hassle for them.
using Vanilla & deken is something else. declaring a library in the patch is not enough. including the library in the patch-package works only on the same type of OS; Windows & Windows, Mac & Mac, (Linux & Linux?).
one method could be a deken-connected feature to automatically download a declared lib when it's not present. what about updates or changes in a lib in that case?
the organisation of pd-ext somehow included a kind of gate-keeping, which resulted in a stable Pd-system. i'm still using Pdext 42.5 and the included libs a lot (because of the old machines in my installations). the same libs are functional in Pdext 43.4. so one could argue that there's no great need for a portability design. just download everything that's necessary (and available) and it will work for quite some time.
? rolf
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Will the pd-extended package be versioned as well? In other words is it a rolling package release-- always fetching the most recent versions of the library packages it contains, or standard release-- tested and released with specific versions of the library packages?
-Jonathan On Wednesday, October 14, 2015 6:11 PM, Dan Wilcox danomatika@gmail.com wrote:
Well, not specifically me as I haven’t contributed code to deken. Versions are currently handled by the filename format: https://github.com/pure-data/deken#create-and-upload-a-package
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Oct 14, 2015, at 3:07 PM, Jonathan Wilkes jancsika@yahoo.com wrote: Hi Dan, How do you handle versioning?
On Wednesday, October 14, 2015 3:18 PM, Dan Wilcox <danomatika@gmail.com> wrote:
That’s why one idea with deken is to install an “extended” meta package which installs most (if not all) of the libs that came with pd-extended. I don’t think it’s too hard to ask a user to open the plugin and install a single package. Also, the cross platform issue will be fixed in time. Thanks for debugging!
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Oct 14, 2015, at 9:22 AM, rolfm@dds.nl wrote:
it looks like the future of pd-extended is going to be 'deken'. what to do then about portability?
i make patches for people who don't know a lot about programming. plus they are on Mac, i'm on Windows. one time downloading the right version of Pdext is enough; i can give them my patches and they just run them. when i make changes, new features: there's no hassle for them.
using Vanilla & deken is something else. declaring a library in the patch is not enough. including the library in the patch-package works only on the same type of OS; Windows & Windows, Mac & Mac, (Linux & Linux?).
one method could be a deken-connected feature to automatically download a declared lib when it's not present. what about updates or changes in a lib in that case?
the organisation of pd-ext somehow included a kind of gate-keeping, which resulted in a stable Pd-system. i'm still using Pdext 42.5 and the included libs a lot (because of the old machines in my installations). the same libs are functional in Pdext 43.4. so one could argue that there's no great need for a portability design. just download everything that's necessary (and available) and it will work for quite some time.
? rolf
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
It would be a good idea to version it, if possible. I’m not sure if the meta package has been created yet, but that’s the idea.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 14, 2015, at 7:54 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Will the pd-extended package be versioned as well? In other words is it a rolling package release-- always fetching the most recent versions of the library packages it contains, or standard release-- tested and released with specific versions of the library packages?
-Jonathan On Wednesday, October 14, 2015 6:11 PM, Dan Wilcox danomatika@gmail.com wrote:
Well, not specifically me as I haven’t contributed code to deken. Versions are currently handled by the filename format: https://github.com/pure-data/deken#create-and-upload-a-package https://github.com/pure-data/deken#create-and-upload-a-package
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 14, 2015, at 3:07 PM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
Hi Dan, How do you handle versioning?
On Wednesday, October 14, 2015 3:18 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
That’s why one idea with deken is to install an “extended” meta package which installs most (if not all) of the libs that came with pd-extended. I don’t think it’s too hard to ask a user to open the plugin and install a single package.
Also, the cross platform issue will be fixed in time. Thanks for debugging!
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 14, 2015, at 9:22 AM, rolfm@dds.nl mailto:rolfm@dds.nl wrote:
it looks like the future of pd-extended is going to be 'deken'. what to do then about portability?
i make patches for people who don't know a lot about programming. plus they are on Mac, i'm on Windows. one time downloading the right version of Pdext is enough; i can give them my patches and they just run them. when i make changes, new features: there's no hassle for them.
using Vanilla & deken is something else. declaring a library in the patch is not enough. including the library in the patch-package works only on the same type of OS; Windows & Windows, Mac & Mac, (Linux & Linux?).
one method could be a deken-connected feature to automatically download a declared lib when it's not present. what about updates or changes in a lib in that case?
the organisation of pd-ext somehow included a kind of gate-keeping, which resulted in a stable Pd-system. i'm still using Pdext 42.5 and the included libs a lot (because of the old machines in my installations). the same libs are functional in Pdext 43.4. so one could argue that there's no great need for a portability design. just download everything that's necessary (and available) and it will work for quite some time.
? rolf
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Hello,
Warning, 100% vapourware ahead.
On 14/10/15 23:22, rolfm@dds.nl wrote:
it looks like the future of pd-extended is going to be 'deken'. what to do then about portability?
I think we should copy the good existing solutions for this from popular scripting languages.
For example, in Python you can supply a file "requirements.txt" with
your Python code, and an end-user can issue pip install -r requirements.txt to install all of the packages with the correct
versions listed therein:
https://pip.readthedocs.org/en/1.1/requirements.html
There should be a thing in Pd/deken that works exactly like this. For example, you could have a [deps] object which specifies the name of a text file that contains the list of dependencies and their versions. The user could bang the [deps] object (or be prompted when it loads, or some other user-friendly mechanism) to load up the deken interface and initiate the install of those dependencies one-by-one.
Before anybody wigs out about security, obviously we should make sure
the GPG signatures of all of those binary packages are checked and
verified, as well as using HTTPS for all connections, and the user
should be prompted before taking any action that might compromise their
security, and informed of all of the risks [which is much more than
Python's pip does currently]. Just as much as anybody else I don't
want the NSA stealing my proprietary procedural rave algorithms[1] and
using them to subdue a band of deeply attractive Russian spies causing
them to dance uncontrollably to the frankly irresistible rhythms of acid
bass + garage beats thereby forcing the west's neo-libertarian
centralized fiat capitalist imperial practices upon the free world[2].
Fuck that!
IOhannes and I have some draft code and GitHub tickets (search "dekenception" on the GitHub) pointing in this general direction but there is a lot of work to be done. Patches are very much welcome!
Given the above does not exist, if the current deken functionality does not work for your users I would suggest they use Pd-extended, or Pd-l2ork if it is available for their platform [I have not tried the latter but I think Jonathan indicated it should fit the bill].
Cheers,
Chris.
[1] Hypothetically proprietary - they're actually GPL. [2] https://en.wikipedia.org/wiki/Does_Humor_Belong_in_Music%3F_%28album%29#/med...
Glad to see there is finally something like this happening! The meta.pd file in the libdir format would be a good place to include dependencies. It already contains the version.
.hc
On Oct 16, 2015, at 8:42 AM, Chris McCormick wrote:
Hello,
Warning, 100% vapourware ahead.
On 14/10/15 23:22, rolfm@dds.nl wrote:
it looks like the future of pd-extended is going to be 'deken'. what to do then about portability?
I think we should copy the good existing solutions for this from popular scripting languages.
For example, in Python you can supply a file "requirements.txt" with your Python code, and an end-user can issue
pip install -r requirements.txtto install all of the packages with the correct versions listed therein:https://pip.readthedocs.org/en/1.1/requirements.html
There should be a thing in Pd/deken that works exactly like this. For example, you could have a [deps] object which specifies the name of a text file that contains the list of dependencies and their versions. The user could bang the [deps] object (or be prompted when it loads, or some other user-friendly mechanism) to load up the deken interface and initiate the install of those dependencies one-by-one.
Before anybody wigs out about security, obviously we should make sure the GPG signatures of all of those binary packages are checked and verified, as well as using HTTPS for all connections, and the user should be prompted before taking any action that might compromise their security, and informed of all of the risks [which is much more than Python's
pipdoes currently]. Just as much as anybody else I don't want the NSA stealing my proprietary procedural rave algorithms[1] and using them to subdue a band of deeply attractive Russian spies causing them to dance uncontrollably to the frankly irresistible rhythms of acid bass + garage beats thereby forcing the west's neo-libertarian centralized fiat capitalist imperial practices upon the free world[2]. Fuck that!IOhannes and I have some draft code and GitHub tickets (search "dekenception" on the GitHub) pointing in this general direction but there is a lot of work to be done. Patches are very much welcome!
Given the above does not exist, if the current deken functionality does not work for your users I would suggest they use Pd-extended, or Pd-l2ork if it is available for their platform [I have not tried the latter but I think Jonathan indicated it should fit the bill].
Cheers,
Chris.
[1] Hypothetically proprietary - they're actually GPL. [2] https://en.wikipedia.org/wiki/Does_Humor_Belong_in_Music%3F_%28album%29#/med...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 09/11/15 20:35, Hans-Christoph Steiner wrote:
Glad to see there is finally something like this happening! The meta.pd file in the libdir format would be a good place to include dependencies. It already contains the version.
Good idea!
Cheers,
Chris.
-
Alexandre Torres Porres -
Chris McCormick -
Dan Wilcox -
Hans-Christoph Steiner -
Jonathan Wilkes -
rolfm＠dds.nl