I'm with you, Alessio.
As another user of Pd who has sometimes been paid in the past to make drop-and-go patches for others, if this community were to develop a repository-style way to load libraries into vanilla, I'd like to see it work like Java.
- Opening a patch with [import cyclone] would automatically download the
cyclone library from Pd vanilla's extended library database if it wasn't already installed. 2. Pd would first check inside the folder where the patch is saved before fetching cyclone from the repository. (This might help with legacy versions of libraries?) 3. There could be an option when saving a patch to save referenced libraries in the patch folder so novices don't have to go sorting through library files to find the cyclone file to copy to their folder.
I know 1 is significantly different behavior than how [import] currently works. I just believe that Pd should be simple for a non-Pd programmer to download and run a patch. This would assist greatly with that.
Sam
On 12/18/2014 08:16 PM, Samuel Burt wrote:
- Opening a patch with [import cyclone] would automatically download the
i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data.
mgfdsr IOhannes
Well, for starters, there could just be a repository with externals and libraries :)
I'm willing to help somehow. I'm not a programmer only, but I can help organising it and stuff. Testing libraries, listing it, etc.
Cheers
2014-12-18 17:34 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:
On 12/18/2014 08:16 PM, Samuel Burt wrote:
- Opening a patch with [import cyclone] would automatically download the
i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data.
mgfdsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
At this point I think that we can start to talk about technical stuff like roadmap, tasks, volunteers recruitment and so on :)
The basic steps, IMHO, can be:
- Identify which externals to include in the repo (for linux users, the
folder /usr/lib/pd-extended/extra can be a good starting point) 2. Identify which externals need to be compiled (some of them, as far as I rememer, are not "true" external library, but a pd patch [intrinsically cross-platform??]) 3. Identify which externals are mainteined/unmaintained, and eventually, contact the maintainers just to say: "hello, we are creating a shared repo of externals. Are you interested? and so on..." 4. Prioritize (i.e. most used extensions have the priority). 5. Assign tasks
In that context, a web platform can help to accomplish this preliminary steps. For example github (that has a project wiki), or Azendoo (free -and simple!- collaborative project management), to name a few. I'm not an expert of this platform, but I use github for small projects and IMHO, Azendoo (or something like that) it can help a lot for discussions, task management and so on, without flooding the mailing list :)
Here is just my thoughts... any idea/suggestion/alternative are appreciated! :)
Cheers
Alessio
On 18/12/2014 20:50, Alexandre Torres Porres wrote:
Well, for starters, there could just be a repository with externals and libraries :)
I'm willing to help somehow. I'm not a programmer only, but I can help organising it and stuff. Testing libraries, listing it, etc.
Cheers
2014-12-18 17:34 GMT-02:00 IOhannes m zmölnig <zmoelnig@iem.at mailto:zmoelnig@iem.at>:
On 12/18/2014 08:16 PM, Samuel Burt wrote: > 1. Opening a patch with [import cyclone] would automatically download the i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data. mgfdsr IOhannes _______________________________________________ Pd-list@lists.iem.at <mailto: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
Yep Alessio. It's time to mean business. So I volunteer
*1. Identify which externals to include in the repo (for linux users, the folder /usr/lib/pd-extended/extra can be a good starting point)*
The Pd extended libraries is a good starting point for all OS users, I guess. Not that I love all that there is there. IMHO there's a lot of junk. Even in the libraries I've mentioned I can't live without and are considered to be more stable I see some issues. Most of all, I'm usually unhappy about some help files that are quite crappy (like incomplete, sometimes the help files don't even work and you have to tweak them to hear something).
Other stuff I see, for example... just yesterday I learned about a new object for me, [LFO_noise~], and it's not working properly (it's frequency is twice than it should be). Other than that, it is redundanct, there are also two other objects that do exactly the same: [rand~] from cyclone and [noisi~] from zexy. I'd say just throw this "extra not working properly one away".
So I can volunteer to manage some of these libraries and rewrite the help files so that they are also vanilla compatible (that is, they don't call objects from other libraries, other than the ones from the same library).
I can't code! And I've compiled anything only a couple of times in my life. So I can't really help much with coding, and that's why I'd rather throw something away that doesn't properly work and has alternatives from other libraries. But I don't oppose if someone wants to fix stuff. I remember it wasn't exactly rock science to compile libraries, so I guess I can try and do it for the latest MAC OS systems on intel machines.
cheers
2014-12-19 9:51 GMT-02:00 Alessio Degani alessio.degani@ymail.com:
At this point I think that we can start to talk about technical stuff like roadmap, tasks, volunteers recruitment and so on :)
The basic steps, IMHO, can be:
- Identify which externals to include in the repo (for linux users, the
folder /usr/lib/pd-extended/extra can be a good starting point) 2. Identify which externals need to be compiled (some of them, as far as I rememer, are not "true" external library, but a pd patch [intrinsically cross-platform??]) 3. Identify which externals are mainteined/unmaintained, and eventually, contact the maintainers just to say: "hello, we are creating a shared repo of externals. Are you interested? and so on..." 4. Prioritize (i.e. most used extensions have the priority). 5. Assign tasks
In that context, a web platform can help to accomplish this preliminary steps. For example github (that has a project wiki), or Azendoo (free -and simple!- collaborative project management), to name a few. I'm not an expert of this platform, but I use github for small projects and IMHO, Azendoo (or something like that) it can help a lot for discussions, task management and so on, without flooding the mailing list :)
Here is just my thoughts... any idea/suggestion/alternative are appreciated! :)
Cheers
Alessio
On 18/12/2014 20:50, Alexandre Torres Porres wrote:
Well, for starters, there could just be a repository with externals and libraries :)
I'm willing to help somehow. I'm not a programmer only, but I can help organising it and stuff. Testing libraries, listing it, etc.
Cheers
2014-12-18 17:34 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:
On 12/18/2014 08:16 PM, Samuel Burt wrote:
- Opening a patch with [import cyclone] would automatically download
the
i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data.
mgfdsr IOhannes
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
-- a.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
FWIW, a good chunk of this cleanup is currently taking place in pd-l2ork. Namely, we are looking for redundant objects which are then disabled and replaced by legacy abstractions where possible or linked to other objects with identical or near identical functionality (again, where possible); we are disabling problematic objects that have design issues (e.g. foxy and flatspace IIRC), as well as looking to replace those with new objects that provide said functionality the right way. Finally, we are looking to standardize documentation (e.g. pd-l2ork has documentation for the entire cyclone adapted to the pddp format). If anyone desires git access to assist with this, please let us know.
Please note that in this process the primary goal/mission/mantra is to create a clean and consistent environment for new users which may also mean that some of us weathered PD users may have to adapt our old patches because certain objects may not be available anymore.
Best,
Ico On Dec 19, 2014 1:49 PM, "Alexandre Torres Porres" porres@gmail.com wrote:
Yep Alessio. It's time to mean business. So I volunteer
*1. Identify which externals to include in the repo (for linux users, the folder /usr/lib/pd-extended/extra can be a good starting point)*
The Pd extended libraries is a good starting point for all OS users, I guess. Not that I love all that there is there. IMHO there's a lot of junk. Even in the libraries I've mentioned I can't live without and are considered to be more stable I see some issues. Most of all, I'm usually unhappy about some help files that are quite crappy (like incomplete, sometimes the help files don't even work and you have to tweak them to hear something).
Other stuff I see, for example... just yesterday I learned about a new object for me, [LFO_noise~], and it's not working properly (it's frequency is twice than it should be). Other than that, it is redundanct, there are also two other objects that do exactly the same: [rand~] from cyclone and [noisi~] from zexy. I'd say just throw this "extra not working properly one away".
So I can volunteer to manage some of these libraries and rewrite the help files so that they are also vanilla compatible (that is, they don't call objects from other libraries, other than the ones from the same library).
I can't code! And I've compiled anything only a couple of times in my life. So I can't really help much with coding, and that's why I'd rather throw something away that doesn't properly work and has alternatives from other libraries. But I don't oppose if someone wants to fix stuff. I remember it wasn't exactly rock science to compile libraries, so I guess I can try and do it for the latest MAC OS systems on intel machines.
cheers
2014-12-19 9:51 GMT-02:00 Alessio Degani alessio.degani@ymail.com:
At this point I think that we can start to talk about technical stuff like roadmap, tasks, volunteers recruitment and so on :)
The basic steps, IMHO, can be:
- Identify which externals to include in the repo (for linux users, the
folder /usr/lib/pd-extended/extra can be a good starting point) 2. Identify which externals need to be compiled (some of them, as far as I rememer, are not "true" external library, but a pd patch [intrinsically cross-platform??]) 3. Identify which externals are mainteined/unmaintained, and eventually, contact the maintainers just to say: "hello, we are creating a shared repo of externals. Are you interested? and so on..." 4. Prioritize (i.e. most used extensions have the priority). 5. Assign tasks
In that context, a web platform can help to accomplish this preliminary steps. For example github (that has a project wiki), or Azendoo (free -and simple!- collaborative project management), to name a few. I'm not an expert of this platform, but I use github for small projects and IMHO, Azendoo (or something like that) it can help a lot for discussions, task management and so on, without flooding the mailing list :)
Here is just my thoughts... any idea/suggestion/alternative are appreciated! :)
Cheers
Alessio
On 18/12/2014 20:50, Alexandre Torres Porres wrote:
Well, for starters, there could just be a repository with externals and libraries :)
I'm willing to help somehow. I'm not a programmer only, but I can help organising it and stuff. Testing libraries, listing it, etc.
Cheers
2014-12-18 17:34 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:
On 12/18/2014 08:16 PM, Samuel Burt wrote:
- Opening a patch with [import cyclone] would automatically download
the
i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data.
mgfdsr IOhannes
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
-- a.
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
cool, so I supose we could share this cleanup process... right?
I see a lot here about pd-l2ork, I've never used it cause I'm not on Linux but it looks like it could be an alternative to extended if it could also run in windows/mac OS. I'm assuming this has been asked/discussed before over here, but I'll shoot again: any plans for that happening?
cheers
2014-12-20 8:28 GMT-02:00 Ivica Bukvic ico@vt.edu:
FWIW, a good chunk of this cleanup is currently taking place in pd-l2ork. Namely, we are looking for redundant objects which are then disabled and replaced by legacy abstractions where possible or linked to other objects with identical or near identical functionality (again, where possible); we are disabling problematic objects that have design issues (e.g. foxy and flatspace IIRC), as well as looking to replace those with new objects that provide said functionality the right way. Finally, we are looking to standardize documentation (e.g. pd-l2ork has documentation for the entire cyclone adapted to the pddp format). If anyone desires git access to assist with this, please let us know.
Please note that in this process the primary goal/mission/mantra is to create a clean and consistent environment for new users which may also mean that some of us weathered PD users may have to adapt our old patches because certain objects may not be available anymore.
Best,
Ico On Dec 19, 2014 1:49 PM, "Alexandre Torres Porres" porres@gmail.com wrote:
Yep Alessio. It's time to mean business. So I volunteer
*1. Identify which externals to include in the repo (for linux users, the folder /usr/lib/pd-extended/extra can be a good starting point)*
The Pd extended libraries is a good starting point for all OS users, I guess. Not that I love all that there is there. IMHO there's a lot of junk. Even in the libraries I've mentioned I can't live without and are considered to be more stable I see some issues. Most of all, I'm usually unhappy about some help files that are quite crappy (like incomplete, sometimes the help files don't even work and you have to tweak them to hear something).
Other stuff I see, for example... just yesterday I learned about a new object for me, [LFO_noise~], and it's not working properly (it's frequency is twice than it should be). Other than that, it is redundanct, there are also two other objects that do exactly the same: [rand~] from cyclone and [noisi~] from zexy. I'd say just throw this "extra not working properly one away".
So I can volunteer to manage some of these libraries and rewrite the help files so that they are also vanilla compatible (that is, they don't call objects from other libraries, other than the ones from the same library).
I can't code! And I've compiled anything only a couple of times in my life. So I can't really help much with coding, and that's why I'd rather throw something away that doesn't properly work and has alternatives from other libraries. But I don't oppose if someone wants to fix stuff. I remember it wasn't exactly rock science to compile libraries, so I guess I can try and do it for the latest MAC OS systems on intel machines.
cheers
2014-12-19 9:51 GMT-02:00 Alessio Degani alessio.degani@ymail.com:
At this point I think that we can start to talk about technical stuff like roadmap, tasks, volunteers recruitment and so on :)
The basic steps, IMHO, can be:
- Identify which externals to include in the repo (for linux users, the
folder /usr/lib/pd-extended/extra can be a good starting point) 2. Identify which externals need to be compiled (some of them, as far as I rememer, are not "true" external library, but a pd patch [intrinsically cross-platform??]) 3. Identify which externals are mainteined/unmaintained, and eventually, contact the maintainers just to say: "hello, we are creating a shared repo of externals. Are you interested? and so on..." 4. Prioritize (i.e. most used extensions have the priority). 5. Assign tasks
In that context, a web platform can help to accomplish this preliminary steps. For example github (that has a project wiki), or Azendoo (free -and simple!- collaborative project management), to name a few. I'm not an expert of this platform, but I use github for small projects and IMHO, Azendoo (or something like that) it can help a lot for discussions, task management and so on, without flooding the mailing list :)
Here is just my thoughts... any idea/suggestion/alternative are appreciated! :)
Cheers
Alessio
On 18/12/2014 20:50, Alexandre Torres Porres wrote:
Well, for starters, there could just be a repository with externals and libraries :)
I'm willing to help somehow. I'm not a programmer only, but I can help organising it and stuff. Testing libraries, listing it, etc.
Cheers
2014-12-18 17:34 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:
On 12/18/2014 08:16 PM, Samuel Burt wrote:
- Opening a patch with [import cyclone] would automatically download
the
i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data.
mgfdsr IOhannes
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
-- a.
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
On Dec 20, 2014 2:05 PM, "Alexandre Torres Porres" porres@gmail.com wrote:
cool, so I supose we could share this cleanup process... right?
I see a lot here about pd-l2ork, I've never used it cause I'm not on
Linux but it looks like it could be an alternative to extended if it could also run in windows/mac OS. I'm assuming this has been asked/discussed before over here, but I'll shoot again: any plans for that happening?
Short answer is yes. It is probably usable as-is ( there may be a few things to check TCL-side plus updating the autobuild script). I just never bothered building it. Help on this front is most welcome. As far as my priority list is concerned, I would like to finish qt port before delving into OSX and Windows support because once that is complete, supporting consistent GUI on all three platforms will become near seamless.
Best,
Ico
cheers
2014-12-20 8:28 GMT-02:00 Ivica Bukvic ico@vt.edu:
FWIW, a good chunk of this cleanup is currently taking place in
pd-l2ork. Namely, we are looking for redundant objects which are then disabled and replaced by legacy abstractions where possible or linked to other objects with identical or near identical functionality (again, where possible); we are disabling problematic objects that have design issues (e.g. foxy and flatspace IIRC), as well as looking to replace those with new objects that provide said functionality the right way. Finally, we are looking to standardize documentation (e.g. pd-l2ork has documentation for the entire cyclone adapted to the pddp format). If anyone desires git access to assist with this, please let us know.
Please note that in this process the primary goal/mission/mantra is to
create a clean and consistent environment for new users which may also mean that some of us weathered PD users may have to adapt our old patches because certain objects may not be available anymore.
Best,
Ico
On Dec 19, 2014 1:49 PM, "Alexandre Torres Porres" porres@gmail.com
wrote:
Yep Alessio. It's time to mean business. So I volunteer
- Identify which externals to include in the repo (for linux users,
the folder /usr/lib/pd-extended/extra can be a good starting point)
The Pd extended libraries is a good starting point for all OS users, I
guess. Not that I love all that there is there. IMHO there's a lot of junk. Even in the libraries I've mentioned I can't live without and are considered to be more stable I see some issues. Most of all, I'm usually unhappy about some help files that are quite crappy (like incomplete, sometimes the help files don't even work and you have to tweak them to hear something).
Other stuff I see, for example... just yesterday I learned about a new
object for me, [LFO_noise~], and it's not working properly (it's frequency is twice than it should be). Other than that, it is redundanct, there are also two other objects that do exactly the same: [rand~] from cyclone and [noisi~] from zexy. I'd say just throw this "extra not working properly one away".
So I can volunteer to manage some of these libraries and rewrite the
help files so that they are also vanilla compatible (that is, they don't call objects from other libraries, other than the ones from the same library).
I can't code! And I've compiled anything only a couple of times in my
life. So I can't really help much with coding, and that's why I'd rather throw something away that doesn't properly work and has alternatives from other libraries. But I don't oppose if someone wants to fix stuff. I remember it wasn't exactly rock science to compile libraries, so I guess I can try and do it for the latest MAC OS systems on intel machines.
cheers
2014-12-19 9:51 GMT-02:00 Alessio Degani alessio.degani@ymail.com:
At this point I think that we can start to talk about technical stuff
like roadmap, tasks, volunteers recruitment and so on :)
The basic steps, IMHO, can be:
- Identify which externals to include in the repo (for linux users,
the folder /usr/lib/pd-extended/extra can be a good starting point)
- Identify which externals need to be compiled (some of them, as far
as I rememer, are not "true" external library, but a pd patch [intrinsically cross-platform??])
- Identify which externals are mainteined/unmaintained, and
eventually, contact the maintainers just to say: "hello, we are creating a shared repo of externals. Are you interested? and so on..."
- Prioritize (i.e. most used extensions have the priority).
- Assign tasks
In that context, a web platform can help to accomplish this
preliminary steps. For example github (that has a project wiki), or Azendoo (free -and simple!- collaborative project management), to name a few. I'm not an expert of this platform, but I use github for small projects and IMHO, Azendoo (or something like that) it can help a lot for discussions, task management and so on, without flooding the mailing list :)
Here is just my thoughts... any idea/suggestion/alternative are
appreciated! :)
Cheers
Alessio
On 18/12/2014 20:50, Alexandre Torres Porres wrote:
Well, for starters, there could just be a repository with externals
and libraries :)
I'm willing to help somehow. I'm not a programmer only, but I can
help organising it and stuff. Testing libraries, listing it, etc.
Cheers
2014-12-18 17:34 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:
On 12/18/2014 08:16 PM, Samuel Burt wrote: > 1. Opening a patch with [import cyclone] would automatically
download the
i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data.
mgfdsr IOhannes
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
-- a.
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
On 2014-12-18 20:34, IOhannes m zmölnig wrote:
On 12/18/2014 08:16 PM, Samuel Burt wrote:
- Opening a patch with [import cyclone] would automatically download the
i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data.
And the Pd-community currently does not have the resources to build something that is similar or more advanced than the Debian distribution system and preferably be cross platform.
mgfdsr IOhannes
Greetings,
Fred Jan
If there is a cross-platform repository system out there that is well-tested and built to be _more_ secure than apt (i.e., defense against replay attacks in the original design), perhaps it could be leveraged. Unfortunately I don't know anything about binary repo systems, other than Debian's. -Jonathan
On Thursday, December 18, 2014 3:04 PM, Fred Jan Kraan <fjkraan@xs4all.nl> wrote:
On 2014-12-18 20:34, IOhannes m zmölnig wrote:
On 12/18/2014 08:16 PM, Samuel Burt wrote:
- Opening a patch with [import cyclone] would automatically download the
i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data.
And the Pd-community currently does not have the resources to build something that is similar or more advanced than the Debian distribution system and preferably be cross platform.
mgfdsr IOhannes
Greetings,
Fred Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 12/18/2014 10:13 PM, Jonathan Wilkes via Pd-list wrote:
If there is a cross-platform repository system out there that is well-tested and built to be _more_ secure than apt (i.e., defense against replay attacks in the original design), perhaps it could be leveraged. Unfortunately I don't know anything about binary repo systems, other than Debian's. -Jonathan
On Thursday, December 18, 2014 3:04 PM, Fred Jan Kraan <fjkraan@xs4all.nl> wrote:On 2014-12-18 20:34, IOhannes m zmölnig wrote:
On 12/18/2014 08:16 PM, Samuel Burt wrote:
- Opening a patch with [import cyclone] would automatically download the
i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data.
And the Pd-community currently does not have the resources to build something that is similar or more advanced than the Debian distribution system and preferably be cross platform.
so why not use apt?
i mean, we could build on top of apt to do something "more" cross platform. Debian (and thus apt) already handles multiple architectures and "operating systems" (well: kernels), so we just need a few others archs:
- w32-i386
- w32-amd64
- osx-i386
- osx-amd64
this would of course mean porting (parts of) apt to w32/osx (and i have no clue how much work *that* means)
fgmrds IOhannes
On 2014-12-20 19:09, IOhannes m zmölnig wrote:
On 12/18/2014 10:13 PM, Jonathan Wilkes via Pd-list wrote:
If there is a cross-platform repository system out there that is well-tested and built to be _more_ secure than apt (i.e., defense against replay attacks in the original design), perhaps it could be leveraged. Unfortunately I don't know anything about binary repo systems, other than Debian's. -Jonathan
On Thursday, December 18, 2014 3:04 PM, Fred Jan Kraan <fjkraan@xs4all.nl> wrote:On 2014-12-18 20:34, IOhannes m zmölnig wrote:
On 12/18/2014 08:16 PM, Samuel Burt wrote:
- Opening a patch with [import cyclone] would automatically download the
i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data.
And the Pd-community currently does not have the resources to build something that is similar or more advanced than the Debian distribution system and preferably be cross platform.
so why not use apt?
i mean, we could build on top of apt to do something "more" cross platform. Debian (and thus apt) already handles multiple architectures and "operating systems" (well: kernels), so we just need a few others archs:
- w32-i386
- w32-amd64
- osx-i386
- osx-amd64
this would of course mean porting (parts of) apt to w32/osx (and i have no clue how much work *that* means)
Porting apt would indeed solve the Pd-distribution problem, and maybe for more cross-platform packages.
For MacOSX, the Fink package is based on Debian tools (http://www.finkproject.org/). So that leaves Windows.
From the distant past I remember Inno Setup is free and usable
(http://www.jrsoftware.org/isinfo.php). As long as there is no native apt for Windows that could do...
Somehow, it looks a bit less abstract now :-).
fgmrds IOhannes
Greetings,
Fred Jan
On Sat, Dec 20, 2014 at 8:29 PM, Fred Jan Kraan fjkraan@xs4all.nl wrote:
On 2014-12-20 19:09, IOhannes m zmölnig wrote:
On 12/18/2014 10:13 PM, Jonathan Wilkes via Pd-list wrote:
If there is a cross-platform repository system out there that is
well-tested and built to be _more_ secure than apt (i.e., defense against replay attacks in the original design), perhaps it could be leveraged.
Unfortunately I don't know anything about binary repo systems, other
than Debian's.
-Jonathan
On Thursday, December 18, 2014 3:04 PM, Fred Jan Kraan <fjkraan@xs4all.nl> wrote:
On 2014-12-18 20:34, IOhannes m zmölnig wrote:
On 12/18/2014 08:16 PM, Samuel Burt wrote:
- Opening a patch with [import cyclone] would automatically download
the
i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data.
And the Pd-community currently does not have the resources to build something that is similar or more advanced than the Debian distribution system and preferably be cross platform.
so why not use apt?
i mean, we could build on top of apt to do something "more" cross
platform.
Debian (and thus apt) already handles multiple architectures and "operating systems" (well: kernels), so we just need a few others archs:
- w32-i386
- w32-amd64
- osx-i386
- osx-amd64
this would of course mean porting (parts of) apt to w32/osx (and i have no clue how much work *that* means)
Porting apt would indeed solve the Pd-distribution problem, and maybe for more cross-platform packages.
For MacOSX, the Fink package is based on Debian tools (http://www.finkproject.org/). So that leaves Windows.
From the distant past I remember Inno Setup is free and usable (http://www.jrsoftware.org/isinfo.php). As long as there is no native apt for Windows that could do...
Somehow, it looks a bit less abstract now :-).
fgmrds IOhannes
Greetings,
Fred Jan
http://sourceforge.net/projects/windows-get/ https://chocolatey.org/ http://dev.tranquil.it/wiki/WAPT_-_apt-get_pour_Windows ?
András
Is the idea to package an entire packaging system with Pd Vanilla? -Jonathan
On Saturday, December 20, 2014 2:41 PM, András Murányi <muranyia@gmail.com> wrote:
On Sat, Dec 20, 2014 at 8:29 PM, Fred Jan Kraan fjkraan@xs4all.nl wrote:
On 2014-12-20 19:09, IOhannes m zmölnig wrote:
On 12/18/2014 10:13 PM, Jonathan Wilkes via Pd-list wrote:
If there is a cross-platform repository system out there that is well-tested and built to be _more_ secure than apt (i.e., defense against replay attacks in the original design), perhaps it could be leveraged. Unfortunately I don't know anything about binary repo systems, other than Debian's. -Jonathan
On Thursday, December 18, 2014 3:04 PM, Fred Jan Kraan fjkraan@xs4all.nl wrote:
On 2014-12-18 20:34, IOhannes m zmölnig wrote:
On 12/18/2014 08:16 PM, Samuel Burt wrote:
- Opening a patch with [import cyclone] would automatically download the
i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data.
And the Pd-community currently does not have the resources to build something that is similar or more advanced than the Debian distribution system and preferably be cross platform.
so why not use apt?
i mean, we could build on top of apt to do something "more" cross platform. Debian (and thus apt) already handles multiple architectures and "operating systems" (well: kernels), so we just need a few others archs:
- w32-i386
- w32-amd64
- osx-i386
- osx-amd64
this would of course mean porting (parts of) apt to w32/osx (and i have no clue how much work *that* means)
Porting apt would indeed solve the Pd-distribution problem, and maybe for more cross-platform packages.
For MacOSX, the Fink package is based on Debian tools (http://www.finkproject.org/). So that leaves Windows.
From the distant past I remember Inno Setup is free and usable
(http://www.jrsoftware.org/isinfo.php). As long as there is no native apt for Windows that could do...
Somehow, it looks a bit less abstract now :-).
fgmrds IOhannes
Greetings,
Fred Jan
http://sourceforge.net/projects/windows-get/ https://chocolatey.org/ http://dev.tranquil.it/wiki/WAPT_-_apt-get_pour_Windows ? András _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2014-12-20 22:38, Jonathan Wilkes via Pd-list wrote:
Is the idea to package an entire packaging system with Pd Vanilla?
For me the focus is now to create a sort of versionable, installable package for cyclone*. But it could well apply to much more. A possible structure could consist of several packages; pd-vanilla as core, depending on it a ring of libraries making it an 'almost Max/MSP clone' and a set of 'special-interest' libraries for those that want it.
I am happy to see there is an apt-get of sorts for all essential non-linux platforms. There is still a lot of work to do, but we as pd-community with limited resources don't have to 'build it from scratch'.
*) The hard-core crowd is happy with just a set of objects, but new-users might like some guidance. Apart from that, some inherent versioning is a good thing too.
-Jonathan
Greetings,
Fred Jan
On Saturday, December 20, 2014 2:41 PM, András Murányi muranyia@gmail.com wrote:
On Sat, Dec 20, 2014 at 8:29 PM, Fred Jan Kraan fjkraan@xs4all.nl wrote:
On 2014-12-20 19:09, IOhannes m zmölnig wrote: > On 12/18/2014 10:13 PM, Jonathan Wilkes via Pd-list wrote: >> If there is a cross-platform repository system out there that is well-tested and built to be _more_ secure than apt (i.e., defense against replay attacks in the original design), perhaps it could be leveraged. >> Unfortunately I don't know anything about binary repo systems, other than Debian's. >> -Jonathan >> >> On Thursday, December 18, 2014 3:04 PM, Fred Jan Kraan <fjkraan@xs4all.nl> wrote: >> >> >> On 2014-12-18 20:34, IOhannes m zmölnig wrote: >>> On 12/18/2014 08:16 PM, Samuel Burt wrote: >>>> 1. Opening a patch with [import cyclone] would automatically download the >>> >>> i *strongly* oppose to anything that automatically connects to the >>> internet and fetches or submits data. >> >> And the Pd-community currently does not have the resources to build >> something that is similar or more advanced than the Debian distribution >> system and preferably be cross platform. > > > so why not use apt? > > i mean, we could build on top of apt to do something "more" cross platform. > Debian (and thus apt) already handles multiple architectures and > "operating systems" (well: kernels), so we just need a few others archs: > - w32-i386 > - w32-amd64 > - osx-i386 > - osx-amd64 > > this would of course mean porting (parts of) apt to w32/osx (and i have > no clue how much work *that* means) Porting apt would indeed solve the Pd-distribution problem, and maybe for more cross-platform packages. For MacOSX, the Fink package is based on Debian tools (http://www.finkproject.org/). So that leaves Windows. >From the distant past I remember Inno Setup is free and usable (http://www.jrsoftware.org/isinfo.php). As long as there is no native apt for Windows that could do... Somehow, it looks a bit less abstract now :-). > > fgmrds > IOhannes > Greetings, Fred Janhttp://sourceforge.net/projects/windows-get/ https://chocolatey.org/ http://dev.tranquil.it/wiki/WAPT_-_apt-get_pour_Windows ?
András
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
On 12/20/2014 05:06 PM, Fred Jan Kraan wrote:
On 2014-12-20 22:38, Jonathan Wilkes via Pd-list wrote:
Is the idea to package an entire packaging system with Pd Vanilla?
For me the focus is now to create a sort of versionable, installable package for cyclone*. But it could well apply to much more. A possible structure could consist of several packages; pd-vanilla as core, depending on it a ring of libraries making it an 'almost Max/MSP clone' and a set of 'special-interest' libraries for those that want it.
But there is already infrastructure for building a monolithic distribution called Pd-extended, and no infrastructure for doing a user-friendly a la carte package delivery system for Pd.
What are the cases where a user who wants an a la carte package system couldn't just get by with a monolithic distribution like Pd-extended?
I am happy to see there is an apt-get of sorts for all essential non-linux platforms. There is still a lot of work to do, but we as pd-community with limited resources don't have to 'build it from scratch'.
Let's say I'm a new user. My friend sends me a patch he/she downloaded from Pd forum that does something neat. It depends on ggee, moonlib, and cyclone.
Using Pd-extended, I download/install Pd-extended and run the patch (without having to know, care, or understand about those libraries).
What steps would be required to run the same patch using the structure you describe above?
-Jonathan
*) The hard-core crowd is happy with just a set of objects, but new-users might like some guidance. Apart from that, some inherent versioning is a good thing too.
-Jonathan
Greetings,
Fred Jan
On Saturday, December 20, 2014 2:41 PM, András Murányi muranyia@gmail.com wrote:
On Sat, Dec 20, 2014 at 8:29 PM, Fred Jan Kraan fjkraan@xs4all.nl wrote:
On 2014-12-20 19:09, IOhannes m zmölnig wrote: > On 12/18/2014 10:13 PM, Jonathan Wilkes via Pd-list wrote: >> If there is a cross-platform repository system out there that is well-tested and built to be _more_ secure than apt (i.e., defense against replay attacks in the original design), perhaps it could be leveraged. >> Unfortunately I don't know anything about binary repo systems, other than Debian's. >> -Jonathan >> >> On Thursday, December 18, 2014 3:04 PM, Fred Jan Kraan <fjkraan@xs4all.nl> wrote: >> >> >> On 2014-12-18 20:34, IOhannes m zmölnig wrote: >>> On 12/18/2014 08:16 PM, Samuel Burt wrote: >>>> 1. Opening a patch with [import cyclone] would automatically download the >>> >>> i *strongly* oppose to anything that automatically connects to the >>> internet and fetches or submits data. >> >> And the Pd-community currently does not have the resources to build >> something that is similar or more advanced than the Debian distribution >> system and preferably be cross platform. > > > so why not use apt? > > i mean, we could build on top of apt to do something "more" cross platform. > Debian (and thus apt) already handles multiple architectures and > "operating systems" (well: kernels), so we just need a few others archs: > - w32-i386 > - w32-amd64 > - osx-i386 > - osx-amd64 > > this would of course mean porting (parts of) apt to w32/osx (and i have > no clue how much work *that* means) Porting apt would indeed solve the Pd-distribution problem, and maybe for more cross-platform packages. For MacOSX, the Fink package is based on Debian tools (http://www.finkproject.org/). So that leaves Windows. >From the distant past I remember Inno Setup is free and usable (http://www.jrsoftware.org/isinfo.php). As long as there is no native apt for Windows that could do... Somehow, it looks a bit less abstract now :-). > > fgmrds > IOhannes > Greetings, Fred Janhttp://sourceforge.net/projects/windows-get/ https://chocolatey.org/ http://dev.tranquil.it/wiki/WAPT_-_apt-get_pour_Windows ?
András
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2014-12-20 23:41, Jonathan Wilkes via Pd-list wrote:
On 12/20/2014 05:06 PM, Fred Jan Kraan wrote:
On 2014-12-20 22:38, Jonathan Wilkes via Pd-list wrote:
Is the idea to package an entire packaging system with Pd Vanilla?
For me the focus is now to create a sort of versionable, installable package for cyclone*. But it could well apply to much more. A possible structure could consist of several packages; pd-vanilla as core, depending on it a ring of libraries making it an 'almost Max/MSP clone' and a set of 'special-interest' libraries for those that want it.
But there is already infrastructure for building a monolithic distribution called Pd-extended, and no infrastructure for doing a user-friendly a la carte package delivery system for Pd.
What are the cases where a user who wants an a la carte package system couldn't just get by with a monolithic distribution like Pd-extended?
The distribution ideas are just an attempt to simplify the current Pd-extended configuration and split the more general purpose libraries from the special interest ones. The core and general purpose libraries is nick-named here as 'Max/MSP-clone'.
Quite another issue is to split pd-extended into a repository for each package. Someone making a distribution can still pick the latest or more stable version of each library for a distribution package. The current Pd-extended all-in-one is just the 'complete' package.
I am happy to see there is an apt-get of sorts for all essential non-linux platforms. There is still a lot of work to do, but we as pd-community with limited resources don't have to 'build it from scratch'.
Let's say I'm a new user. My friend sends me a patch he/she downloaded from Pd forum that does something neat. It depends on ggee, moonlib, and cyclone.
Using Pd-extended, I download/install Pd-extended and run the patch (without having to know, care, or understand about those libraries).
What steps would be required to run the same patch using the structure you describe above?
Without knowing the exact nature of the ggee or moonlib libraries, by name the objects look general purpose and could be part of a 'Max/MSP-clone' distribution*. The core could be pd-extended-core, pd-l2ork-core or pd-vanilla, but the latter two are preferred because they are currently maintained.
*) Assuming they are stable, working and preferably maintained.
So for this example, the 'Max-MSP-clone'-distribution should be downloaded and installed. For Linux this could be a meta package installing the libraries it depends on. For Windows and MacOSX, depending on platform conventions, probably one package containing the core and all libraries.
-Jonathan
Fred Jan
I'll second that strong opposition. If someone wants to shoot themselves in the foot, here is a loader that automatically fetches binaries from the net and loads them:http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/loaders/url... -Jonathan
On Thursday, December 18, 2014 2:34 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 12/18/2014 08:16 PM, Samuel Burt wrote:
- Opening a patch with [import cyclone] would automatically download the
i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data.
mgfdsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 18/12/2014 20:34, IOhannes m zmölnig wrote:
On 12/18/2014 08:16 PM, Samuel Burt wrote:
- Opening a patch with [import cyclone] would automatically download the
i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data.
I totally agree with you! But an auto-download can be achieved by different means. For example by calling your default package manager. Or maybe in a semi-automatic way like pointing to a web page reposotory and then the user can download the external and put it in to a default folder (as suggested by Dan). Just an idea...
But I think that the main concern is about compiling/maintaining all the (cross platform) externals and organize them in a clean manner. After that, the installation task can be simplified in several ways...
Cheers
Alessio
mgfdsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alessio Degani -
Alexandre Torres Porres -
András Murányi -
Fred Jan Kraan -
IOhannes m zmölnig -
Ivica Bukvic -
Jonathan Wilkes -
Samuel Burt