Oi, no. That’s putting the cart before the horse. IMO It makes more sense to break up the externals in the svn to separate repos with working Makefiles. Once we know they’re all working and have an easy way to install binaries like Max, then we could go to the next level. Baby steps. If I wasn’t in the middle of my thesis writing right now, I would have done it as a test to Github already.
Besides, requiring beginners to install Fink (Homebrew is much nicer than Fink or MacPorts anyway) is going in the opposite direction. If we really wanted to make that work, it would require distributing apt and it’s required libraries in binary from with Pd on OSX and Windows. Yeah, I don’t see that happening :P
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 20, 2014, at 2:39 PM, pd-list-request@lists.iem.at wrote:
From: Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl> To: pd-list@lists.iem.at mailto:pd-list@lists.iem.at Date: December 20, 2014 at 2:29:30 PM EST Subject: Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches & issue list)
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 <mailto: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/ 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 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 2014-12-20 23:17, Dan Wilcox wrote:
Oi, no. That’s putting the cart before the horse. IMO It makes more sense to break up the externals in the svn to separate repos with working Makefiles. Once we know they’re all working and have an easy way to install binaries like Max, then we could go to the next level. Baby steps. If I wasn’t in the middle of my thesis writing right now, I would have done it as a test to Github already.
Besides, requiring beginners to install Fink (Homebrew is much nicer than Fink or MacPorts anyway) is going in the opposite direction. If we really wanted to make that work, it would require distributing apt and it’s required libraries in binary from with Pd on OSX and Windows. Yeah, I don’t see that happening :P
Sofar, it is only talk about how we should solve the maintenance and distribution problem. On Debian-like Linux systems, apt works good for both binary and source distribution. If it doesn't work on MacOSX for some reason, we should choose another solution. The same could be true for Windows. The binary distribution is clearly the most important bit to make easy.
For me, the current activity is only fixing help-patches and binaries in cyclone, to be followed by testing on several platforms. The pd-extended svn source code patches aren't even applied yet. The rest is only trying to plan ahead. No decision is made yet.
Fred Jan
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
On Dec 20, 2014, at 2:39 PM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
*From: *Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl> *To: *pd-list@lists.iem.at mailto:pd-list@lists.iem.at *Date: *December 20, 2014 at 2:29:30 PM EST *Subject: **Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches & issue list)*
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 mailto: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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I'm with Dan,
First of all, we need a svn/git/... repository with working (multi-platform??) Makefiles. Then, we have to fix the help files with a common style.
Only after that we can start to think how to distribute/install them on pd-[vanilla|l2ork]. And stuff like defining metapackages like for example, synthesys, filering, reverb, all, ... comes after.
To Jonathan: Yes... pd-extended is very useful... and that's why we are chatting about "extending" vanlilla. The main concern about pd-extended is that is "apparently" non maintained anymore (please tell me if I'm wrong!), and the core i synched to an old version of pd! A non maintained software, IMHO, means a dead software...
Cheers
Alessio
On 20/12/2014 23:17, Dan Wilcox wrote:
Oi, no. That’s putting the cart before the horse. IMO It makes more sense to break up the externals in the svn to separate repos with working Makefiles. Once we know they’re all working and have an easy way to install binaries like Max, then we could go to the next level. Baby steps. If I wasn’t in the middle of my thesis writing right now, I would have done it as a test to Github already.
Besides, requiring beginners to install Fink (Homebrew is much nicer than Fink or MacPorts anyway) is going in the opposite direction. If we really wanted to make that work, it would require distributing apt and it’s required libraries in binary from with Pd on OSX and Windows. Yeah, I don’t see that happening :P
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
On Dec 20, 2014, at 2:39 PM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
*From:*Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl> *To:*pd-list@lists.iem.at mailto:pd-list@lists.iem.at *Date:*December 20, 2014 at 2:29:30 PM EST *Subject:**Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches & issue list)*
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 mailto: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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yes, I'm suggesting this approach as an alternative to continuing Pd-extended, mainly because I don't see anyone willing to dig into the extended source to update/maintain it. I've considered doing this myself, but it's really too much for one person, as we've already seen.
I see a "Max-clone" of externals as a meta package of the individual externals. If the externals are in separate Github repos, it just requires a script and git to clone the ones needed by this package and build. We can make the scripts and Makefiles handle a lot of this for us. I can port over the Bash script library build system I wrote for OpenFrameworks called Apothecary to make it easy for users/maintainers.
Also, this approach might involve asking users to do a little more by downloading and installing external libraries as required. This has been working for Max for a long time already and I see the pluses are:
splitting up the externals makes maintenance an cooperation much easier (aka Github forking and PRs)
and extended like distribution no longer requires build and maintaining said entire separate or distribution
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On Dec 21, 2014, at 8:31 AM, Alessio Degani alessio.degani@ymail.com wrote:
I'm with Dan,
First of all, we need a svn/git/... repository with working (multi-platform??) Makefiles. Then, we have to fix the help files with a common style.
Only after that we can start to think how to distribute/install them on pd-[vanilla|l2ork]. And stuff like defining metapackages like for example, synthesys, filering, reverb, all, ... comes after.
To Jonathan: Yes... pd-extended is very useful... and that's why we are chatting about "extending" vanlilla. The main concern about pd-extended is that is "apparently" non maintained anymore (please tell me if I'm wrong!), and the core i synched to an old version of pd! A non maintained software, IMHO, means a dead software...
Cheers
Alessio
On 20/12/2014 23:17, Dan Wilcox wrote:
Oi, no. That’s putting the cart before the horse. IMO It makes more sense to break up the externals in the svn to separate repos with working Makefiles. Once we know they’re all working and have an easy way to install binaries like Max, then we could go to the next level. Baby steps. If I wasn’t in the middle of my thesis writing right now, I would have done it as a test to Github already.
Besides, requiring beginners to install Fink (Homebrew is much nicer than Fink or MacPorts anyway) is going in the opposite direction. If we really wanted to make that work, it would require distributing apt and it’s required libraries in binary from with Pd on OSX and Windows. Yeah, I don’t see that happening :P
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Dec 20, 2014, at 2:39 PM, pd-list-request@lists.iem.at wrote:
From: Fred Jan Kraan fjkraan@xs4all.nl To: pd-list@lists.iem.at Date: December 20, 2014 at 2:29:30 PM EST Subject: Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches & issue list)
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 Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- a.
Unless you want an enormous number of patches in the wild to bit-rot, you're going to have a "Install Pd-extended libraries" button. If you have that button, then presumably at least _one_ person is going to need to build and test the whole enchilada, no? Btw-- are there poisonous spiders lurking in the Pd-extended makefiles? Just reading this thread and seeing alternatives like "let's just port apt to some proprietary OSes" seems odd to me... So I guess I'll add my own idea to this mix: how about replacing every single external binary with an abstraction? Then the external libs become portable without having to compile a single thing. Plus any Pd user willing to click the object can potentially fix bugs or make improvements. Sure, you can't do Gem and some of the fancy stuff, but those are details. This would also increase the incentives for doing development to the core which makes abstractions faster.
-Jonathan
On Sunday, December 21, 2014 10:33 AM, Dan Wilcox <danomatika@gmail.com> wrote:
Yes, I'm suggesting this approach as an alternative to continuing Pd-extended, mainly because I don't see anyone willing to dig into the extended source to update/maintain it. I've considered doing this myself, but it's really too much for one person, as we've already seen. I see a "Max-clone" of externals as a meta package of the individual externals. If the externals are in separate Github repos, it just requires a script and git to clone the ones needed by this package and build. We can make the scripts and Makefiles handle a lot of this for us. I can port over the Bash script library build system I wrote for OpenFrameworks called Apothecary to make it easy for users/maintainers. Also, this approach might involve asking users to do a little more by downloading and installing external libraries as required. This has been working for Max for a long time already and I see the pluses are:
- splitting up the externals makes maintenance an cooperation much easier (aka Github forking and PRs)
- and extended like distribution no longer requires build and maintaining said entire separate or distribution
enohp ym morf tnes --------------Dan Wilcoxdanomatika.comrobotcowboy.com On Dec 21, 2014, at 8:31 AM, Alessio Degani alessio.degani@ymail.com wrote:
I'm with Dan,
First of all, we need a svn/git/... repository with working (multi-platform??) Makefiles. Then, we have to fix the help files with a common style.
Only after that we can start to think how to distribute/install them on pd-[vanilla|l2ork]. And stuff like defining metapackages like for example, synthesys, filering, reverb, all, ... comes after.
To Jonathan: Yes... pd-extended is very useful... and that's why we are chatting about "extending" vanlilla. The main concern about pd-extended is that is "apparently" non maintained anymore (please tell me if I'm wrong!), and the core i synched to an old version of pd! A non maintained software, IMHO, means a dead software...
Cheers
Alessio
On 20/12/2014 23:17, Dan Wilcox wrote:
Oi, no. That’s putting the cart before the horse. IMO It makes more sense to break up the externals in the svn to separate repos with working Makefiles. Once we know they’re all working and have an easy way to install binaries like Max, then we could go to the next level. Baby steps. If I wasn’t in the middle of my thesis writing right now, I would have done it as a test to Github already. Besides, requiring beginners to install Fink (Homebrew is much nicer than Fink or MacPorts anyway) is going in the opposite direction. If we really wanted to make that work, it would require distributing apt and it’s required libraries in binary from with Pd on OSX and Windows. Yeah, I don’t see that happening :P
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Dec 20, 2014, at 2:39 PM, pd-list-request@lists.iem.at wrote: From: Fred Jan Kraan fjkraan@xs4all.nl To: pd-list@lists.iem.at Date: December 20, 2014 at 2:29:30 PM EST Subject: Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches & issue list)
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
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
On 22/12/2014 08:55, Jonathan Wilkes wrote:
[CUT]
Btw-- are there poisonous spiders lurking in the Pd-extended makefiles? Just reading this thread and seeing alternatives like "let's just port apt to some proprietary OSes" seems odd to me...
That's a lot of work... I think. A more feasible way is, for example, an hybrid approach. The user downloads the desired extension/abstraction binary archive (i.e. zip, tar, ...) and then, that can be installed by simply drag'n'drop it to the pd main window (or any "install extensions" window). The installation process can be as symple as extracting the archive in to a user-specific folder (i.e. ~/.pd-extensions/) without root/admin permissions.
So I guess I'll add my own idea to this mix: how about replacing every single external binary with an abstraction? Then the external libs become portable without having to compile a single thing. Plus any Pd user willing to click the object can potentially fix bugs or make improvements.
That's a good idea! Intrinsically cross-platform and plus, each non-developer-pd-user can contribute itself to maintain the extensions... that means that the effective numbers of maintainers/developers grows exponentially! :)
Sure, you can't do Gem and some of the fancy stuff, but those are details.
Yes... that's the main concern about this approach...
Alessio
This would also increase the incentives for doing development to the core which makes abstractions faster.
-Jonathan
Well, funny this was mentioned here, cause I was actually thinking about creating a library of abstractions myself.
I've been working on an extensive computer music tutorial with Pd over the years now (in portuguese though, with over 220 patches now), and I usually present a vanilla alternative when I present externals. I mean, the whole idea of the thing is to show how to implement stuff, so I sometimes even go as far as presenting a vanilla implementation of some vanilla objects.
I'm very interested in this thread because of this work, by the way. Because the tutorial has been stuck to Pd Extended 0.42-5 :P in Pd Extended 0.43 [cartopol~] and [poltocar~] did break so I say it's not compatible to it. I wanted to include some of the vanilla 0.46 functionality too by the way. Well, I digress.
I surely value compiled objects as I think they can run faster and everything, but I could work on the abstractions. I can still think of many many external objects I couldn't live without in regards to this "tutorial". Not only many objects, but maybe most importantly some GUI features like [envgen] / [breakpoints~] / [grid]. And those gotta be externals, right.
Well. Anyway. I'd be glad to come up with a library of abstractions as a side part of this work I've been developing.
If you wanna have a look at it, even though you don't speak portuguese, here it is: https://sites.google.com/site/porres/ComputacaoMusical-Porres.zip
that's the current version I uploaded for this month, but I'm already working on a new release for next month.
Cheers
2014-12-22 9:16 GMT-02:00 Alessio Degani alessio.degani@ymail.com:
On 22/12/2014 08:55, Jonathan Wilkes wrote:
[CUT]
Btw-- are there poisonous spiders lurking in the Pd-extended makefiles? Just reading this thread and seeing alternatives like "let's just port apt to some proprietary OSes" seems odd to me...
That's a lot of work... I think. A more feasible way is, for example, an hybrid approach. The user downloads the desired extension/abstraction binary archive (i.e. zip, tar, ...) and then, that can be installed by simply drag'n'drop it to the pd main window (or any "install extensions" window). The installation process can be as symple as extracting the archive in to a user-specific folder (i.e. ~/.pd-extensions/) without root/admin permissions.
So I guess I'll add my own idea to this mix: how about replacing every single external binary with an abstraction? Then the external libs become portable without having to compile a single thing. Plus any Pd user willing to click the object can potentially fix bugs or make improvements.
That's a good idea! Intrinsically cross-platform and plus, each non-developer-pd-user can contribute itself to maintain the extensions... that means that the effective numbers of maintainers/developers grows exponentially! :)
Sure, you can't do Gem and some of the fancy stuff, but those are details.
Yes... that's the main concern about this approach...
Alessio
This would also increase the incentives for doing development to the core which makes abstractions faster.
-Jonathan
-- a.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Unless you want an enormous number of patches in the wild to bit-rot, you're going to have a "Install Pd-extended libraries" button. If you have that button, then presumably at least _one_ person is going to need to build and test the whole enchilada, no?
I disagree. If it’s easier to build, then it will be easier for a number of people to test on their respective OS. I assume l2ork doesn’t rely on one person testing and building across multiple platforms? I’ve been in that situation already and it sucks. Much nicer to split up the work, better still if the makefiles work and we have some scripting to handling automation, fetching, etc for developers and volunteer testers.
Btw-- are there poisonous spiders lurking in the Pd-extended makefiles? Just reading this thread and seeing alternatives like "let's just port apt to some proprietary OSes" seems odd to me…
I agree. I, for one, say let’s make sure the makefiles work well before getting into package management (if at all).
So I guess I'll add my own idea to this mix: how about replacing every single external binary with an abstraction? Then the external libs become portable without having to compile a single thing. Plus any Pd user willing to click the object can potentially fix bugs or make improvements. Sure, you can't do Gem and some of the fancy stuff, but those are details. This would also increase the incentives for doing development to the core which makes abstractions faster.
rjlib, etc have done some of this already and I’ve followed when I started reimplementing my abstraction library. Honestly, I don’t think this community has the resources to tackle an effort like that, regardless of the technical issues that would need to be fixed. I think it’s far more pragmatic to work on making it easier to split up the maintenance work on the existing externals and allow for more people to hep testing, building, and using them outside of a monolithic Pd-extended release. Again, this approach has worked for other projects like OpenFrameworks, so I think it can be applicable to Pd. This way, also, we still allow for the freedom of the users to step up and dictate which externals they want to keep using without throwing out all the work and useful source code that already exists.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 22, 2014 10:23 PM, "Dan Wilcox" danomatika@gmail.com wrote:
On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Unless you want an enormous number of patches in the wild to bit-rot,
you're going to have a "Install Pd-extended libraries" button. If you have that button, then presumably at least _one_ person is going to need to build and test the whole enchilada, no?
I disagree. If it’s easier to build, then it will be easier for a number
of people to test on their respective OS. I assume l2ork doesn’t rely on one person testing and building across multiple platforms? I’ve been in that situation already and it sucks. Much nicer to split up the work, better still if the makefiles work and we have some scripting to handling automation, fetching, etc for developers and volunteer testers.
Actually, you're simply trading one shortcoming for another, and I would argue you're shortcoming is a lot harder to troubleshoot. If you provide a monolithic distribution to all of your users, then reproducing their problems becomes exponentially easier as opposed to encouraging each user to install select externals which may clash with each other in unusual ways that may not be apparent otherwise and then trying to backtrace and troubleshoot their specific set up as opposed to relying on one monolithic release that you can easily reproduce on your own computer. If we had infinite time on this rock this may be a feasible option. As for me, particularly considering I am doing this not because I am getting paid to do it, monolithic approach is the way to go with the ultimate goal of having all externals in the extra folder and without any subfolders (in part because duplicates and buggy externals will have been weeded out).
BTW for clarification purposes, pd-l2ork is tested by a couple of core developers, including myself almost on a daily basis, plus 12+ members who have little or no experience with Linux, let alone with PD through the laptop orchestra, and finally a bunch of kids through various k12 education initiatives (who also have little or no knowledge of Linux or PD). I feel that is fairly sufficient for my needs.
Also, to clarify another point that has been brought up several times on this mailing list, while pd-l2ork does not support Windows or Mac at this time, this is mainly due to lack of human resources, rather than some kind of religious mission. There is clearly an intent on supporting those once we complete port to Qt toolkit. Until then, there is a bootable USB stick that boots on most computers, and has its own environment, including a persistent home directory. There are exceptions-- select laptops that stubbornly lock down their EFI making them not fully compliant with bootable USB stick format. Examples of this that I observed include select Apple hardware (as part of their ongoing "we know better than the user" walled garden initiative) and a few Dell and Alienware machines (in other words, select companies in close relationships with Microsoft).
Btw-- are there poisonous spiders lurking in the Pd-extended makefiles?
Just reading this thread and seeing alternatives like "let's just port apt to some proprietary OSes" seems odd to me…
I agree. I, for one, say let’s make sure the makefiles work well before
getting into package management (if at all).
So I guess I'll add my own idea to this mix: how about replacing every
single external binary with an abstraction? Then the external libs become portable without having to compile a single thing. Plus any Pd user willing to click the object can potentially fix bugs or make improvements. Sure, you can't do Gem and some of the fancy stuff, but those are details. This would also increase the incentives for doing development to the core which makes abstractions faster.
rjlib, etc have done some of this already and I’ve followed when I
started reimplementing my abstraction library. Honestly, I don’t think this community has the resources to tackle an effort like that, regardless of the technical issues that would need to be fixed. I think it’s far more pragmatic to work on making it easier to split up the maintenance work on the existing externals and allow for more people to hep testing, building, and using them outside of a monolithic Pd-extended release. Again, this approach has worked for other projects like OpenFrameworks, so I think it can be applicable to Pd. This way, also, we still allow for the freedom of the users to step up and dictate which externals they want to keep using without throwing out all the work and useful source code that already exists.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
One thing I'll add-- Pd-extended already includes within it the ability for individual libraries to be compiled "a la carte" in the way Dan desires. Any library adhering to the "libdir" format will have a standard makefile that can be used to compile the binaries. They'll end up in the same directory with their help patches, which means in most cases they will create properly when the user opens the help patch (even if that library hasn't been loaded yet). The idea of scripting dependencies across externals is an interesting one. I don't think that currently happens with Pd-extended. But a lot of libraries do employ [pddp/pddplink] in the documentation, so that feature would be handy in that situation. Also-- I think weeding out "duplicate" externals is a bad idea, at least the way Ivica describes it. Many people have built patches with Pd-extended, assuming that all the object names available at startup are essentially like "keywords" in text-based languages. It's unfortunate that [lib1/foo] does the same exact thing as [lib2/bar]. But if I'm trying to show off Pd by playing some fancy synthesizer patch which relies on [lib1/foo], it had better work. I'll always prefer ugly-but-works over clean-but-let-me-debug-this-patch-while-everyone-sits-there-and-waits. Anyway, I think there are ways to prefer certain objects or libs in the search results, and steer new users to the more reliable and maintained set of externals.
-Jonathan
On Monday, December 22, 2014 5:48 PM, Ivica Bukvic <ico@vt.edu> wrote:
On Dec 22, 2014 10:23 PM, "Dan Wilcox" danomatika@gmail.com wrote:
On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Unless you want an enormous number of patches in the wild to bit-rot, you're going to have a "Install Pd-extended libraries" button. If you have that button, then presumably at least _one_ person is going to need to build and test the whole enchilada, no?
I disagree. If it’s easier to build, then it will be easier for a number of people to test on their respective OS. I assume l2ork doesn’t rely on one person testing and building across multiple platforms? I’ve been in that situation already and it sucks. Much nicer to split up the work, better still if the makefiles work and we have some scripting to handling automation, fetching, etc for developers and volunteer testers.Actually, you're simply trading one shortcoming for another, and I would argue you're shortcoming is a lot harder to troubleshoot. If you provide a monolithic distribution to all of your users, then reproducing their problems becomes exponentially easier as opposed to encouraging each user to install select externals which may clash with each other in unusual ways that may not be apparent otherwise and then trying to backtrace and troubleshoot their specific set up as opposed to relying on one monolithic release that you can easily reproduce on your own computer. If we had infinite time on this rock this may be a feasible option. As for me, particularly considering I am doing this not because I am getting paid to do it, monolithic approach is the way to go with the ultimate goal of having all externals in the extra folder and without any subfolders (in part because duplicates and buggy externals will have been weeded out).BTW for clarification purposes, pd-l2ork is tested by a couple of core developers, including myself almost on a daily basis, plus 12+ members who have little or no experience with Linux, let alone with PD through the laptop orchestra, and finally a bunch of kids through various k12 education initiatives (who also have little or no knowledge of Linux or PD). I feel that is fairly sufficient for my needs.Also, to clarify another point that has been brought up several times on this mailing list, while pd-l2ork does not support Windows or Mac at this time, this is mainly due to lack of human resources, rather than some kind of religious mission. There is clearly an intent on supporting those once we complete port to Qt toolkit. Until then, there is a bootable USB stick that boots on most computers, and has its own environment, including a persistent home directory. There are exceptions-- select laptops that stubbornly lock down their EFI making them not fully compliant with bootable USB stick format. Examples of this that I observed include select Apple hardware (as part of their ongoing "we know better than the user" walled garden initiative) and a few Dell and Alienware machines (in other words, select companies in close relationships with Microsoft).>
Btw-- are there poisonous spiders lurking in the Pd-extended makefiles? Just reading this thread and seeing alternatives like "let's just port apt to some proprietary OSes" seems odd to me…
I agree. I, for one, say let’s make sure the makefiles work well before getting into package management (if at all).
So I guess I'll add my own idea to this mix: how about replacing every single external binary with an abstraction? Then the external libs become portable without having to compile a single thing. Plus any Pd user willing to click the object can potentially fix bugs or make improvements. Sure, you can't do Gem and some of the fancy stuff, but those are details. This would also increase the incentives for doing development to the core which makes abstractions faster.
rjlib, etc have done some of this already and I’ve followed when I started reimplementing my abstraction library. Honestly, I don’t think this community has the resources to tackle an effort like that, regardless of the technical issues that would need to be fixed. I think it’s far more pragmatic to work on making it easier to split up the maintenance work on the existing externals and allow for more people to hep testing, building, and using them outside of a monolithic Pd-extended release. Again, this approach has worked for other projects like OpenFrameworks, so I think it can be applicable to Pd. This way, also, we still allow for the freedom of the users to step up and dictate which externals they want to keep using without throwing out all the work and useful source code that already exists.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You know guys, all I’m saying is perhaps there’s a way to move forward with the spirit of Pd-extended with the practicality of making it easy to use the extended externals with vanilla. In no way was I trying to say what you’re doing or not doing with pd-l2ork is wrong.
This line "I assume l2ork doesn’t rely on one person testing and building across multiple platforms?” is only asking if you’ve experienced what a pain it is to handle that. It takes work and it’s *really* nice not to have to rely on one or two people to manually check things. I wrote that in comradeship assuming you agree that it’s a pain to do.
I appreciate the work y’all are doing, but not everyone wants to use pd-l2ork and you yourselves have said you have no interest in trying to fill the role of Pd-extended.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 22, 2014, at 7:06 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
One thing I'll add-- Pd-extended already includes within it the ability for individual libraries to be compiled "a la carte" in the way Dan desires. Any library adhering to the "libdir" format will have a standard makefile that can be used to compile the binaries. They'll end up in the same directory with their help patches, which means in most cases they will create properly when the user opens the help patch (even if that library hasn't been loaded yet).
The idea of scripting dependencies across externals is an interesting one. I don't think that currently happens with Pd-extended. But a lot of libraries do employ [pddp/pddplink] in the documentation, so that feature would be handy in that situation.
Also-- I think weeding out "duplicate" externals is a bad idea, at least the way Ivica describes it. Many people have built patches with Pd-extended, assuming that all the object names available at startup are essentially like "keywords" in text-based languages. It's unfortunate that [lib1/foo] does the same exact thing as [lib2/bar]. But if I'm trying to show off Pd by playing some fancy synthesizer patch which relies on [lib1/foo], it had better work. I'll always prefer ugly-but-works over clean-but-let-me-debug-this-patch-while-everyone-sits-there-and-waits.
Anyway, I think there are ways to prefer certain objects or libs in the search results, and steer new users to the more reliable and maintained set of externals.
-Jonathan
On Monday, December 22, 2014 5:48 PM, Ivica Bukvic ico@vt.edu wrote:
On Dec 22, 2014 10:23 PM, "Dan Wilcox" <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
Unless you want an enormous number of patches in the wild to bit-rot, you're going to have a "Install Pd-extended libraries" button. If you have that button, then presumably at least _one_ person is going to need to build and test the whole enchilada, no?
I disagree. If it’s easier to build, then it will be easier for a number of people to test on their respective OS. I assume l2ork doesn’t rely on one person testing and building across multiple platforms? I’ve been in that situation already and it sucks. Much nicer to split up the work, better still if the makefiles work and we have some scripting to handling automation, fetching, etc for developers and volunteer testers.
Actually, you're simply trading one shortcoming for another, and I would argue you're shortcoming is a lot harder to troubleshoot. If you provide a monolithic distribution to all of your users, then reproducing their problems becomes exponentially easier as opposed to encouraging each user to install select externals which may clash with each other in unusual ways that may not be apparent otherwise and then trying to backtrace and troubleshoot their specific set up as opposed to relying on one monolithic release that you can easily reproduce on your own computer. If we had infinite time on this rock this may be a feasible option. As for me, particularly considering I am doing this not because I am getting paid to do it, monolithic approach is the way to go with the ultimate goal of having all externals in the extra folder and without any subfolders (in part because duplicates and buggy externals will have been weeded out). BTW for clarification purposes, pd-l2ork is tested by a couple of core developers, including myself almost on a daily basis, plus 12+ members who have little or no experience with Linux, let alone with PD through the laptop orchestra, and finally a bunch of kids through various k12 education initiatives (who also have little or no knowledge of Linux or PD). I feel that is fairly sufficient for my needs. Also, to clarify another point that has been brought up several times on this mailing list, while pd-l2ork does not support Windows or Mac at this time, this is mainly due to lack of human resources, rather than some kind of religious mission. There is clearly an intent on supporting those once we complete port to Qt toolkit. Until then, there is a bootable USB stick that boots on most computers, and has its own environment, including a persistent home directory. There are exceptions-- select laptops that stubbornly lock down their EFI making them not fully compliant with bootable USB stick format. Examples of this that I observed include select Apple hardware (as part of their ongoing "we know better than the user" walled garden initiative) and a few Dell and Alienware machines (in other words, select companies in close relationships with Microsoft).
Btw-- are there poisonous spiders lurking in the Pd-extended makefiles? Just reading this thread and seeing alternatives like "let's just port apt to some proprietary OSes" seems odd to me…
I agree. I, for one, say let’s make sure the makefiles work well before getting into package management (if at all).
So I guess I'll add my own idea to this mix: how about replacing every single external binary with an abstraction? Then the external libs become portable without having to compile a single thing. Plus any Pd user willing to click the object can potentially fix bugs or make improvements. Sure, you can't do Gem and some of the fancy stuff, but those are details. This would also increase the incentives for doing development to the core which makes abstractions faster.
rjlib, etc have done some of this already and I’ve followed when I started reimplementing my abstraction library. Honestly, I don’t think this community has the resources to tackle an effort like that, regardless of the technical issues that would need to be fixed. I think it’s far more pragmatic to work on making it easier to split up the maintenance work on the existing externals and allow for more people to hep testing, building, and using them outside of a monolithic Pd-extended release. Again, this approach has worked for other projects like OpenFrameworks, so I think it can be applicable to Pd. This way, also, we still allow for the freedom of the users to step up and dictate which externals they want to keep using without throwing out all the work and useful source code that already exists.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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
On Dec 23, 2014 1:53 AM, "Dan Wilcox" danomatika@gmail.com wrote:
You know guys, all I’m saying is perhaps there’s a way to move forward
with the spirit of Pd-extended with the practicality of making it easy to use the extended externals with vanilla. In no way was I trying to say what you’re doing or not doing with pd-l2ork is wrong.
This line "I assume l2ork doesn’t rely on one person testing and building
across multiple platforms?” is only asking if you’ve experienced what a pain it is to handle that. It takes work and it’s *really* nice not to have to rely on one or two people to manually check things. I wrote that in comradeship assuming you agree that it’s a pain to do.
I appreciate the work y’all are doing, but not everyone wants to use
pd-l2ork and you yourselves have said you have no interest in trying to fill the role of Pd-extended.
I think you may have misunderstood me (or I may have misspoke, honestly can't remember). Pd-l2ork is and has since its inception replaced extended in my own work. Out of respect to the work of Hans and many others have done with extended, as well as pd-l2ork's arguably lesser concern with legacy stuff I never wanted to claim it will do the same for you and others (even though as of right now I can think of a couple, mainly cosmetic reasons why it wouldn't).
Best,
Ico
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Dec 22, 2014, at 7:06 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
One thing I'll add-- Pd-extended already includes within it the ability
for individual libraries to be compiled "a la carte" in the way Dan desires. Any library adhering to the "libdir" format will have a standard makefile that can be used to compile the binaries. They'll end up in the same directory with their help patches, which means in most cases they will create properly when the user opens the help patch (even if that library hasn't been loaded yet).
The idea of scripting dependencies across externals is an interesting
one. I don't think that currently happens with Pd-extended. But a lot of libraries do employ [pddp/pddplink] in the documentation, so that feature would be handy in that situation.
Also-- I think weeding out "duplicate" externals is a bad idea, at least
the way Ivica describes it. Many people have built patches with Pd-extended, assuming that all the object names available at startup are essentially like "keywords" in text-based languages. It's unfortunate that [lib1/foo] does the same exact thing as [lib2/bar]. But if I'm trying to show off Pd by playing some fancy synthesizer patch which relies on [lib1/foo], it had better work. I'll always prefer ugly-but-works over clean-but-let-me-debug-this-patch-while-everyone-sits-there-and-waits.
Anyway, I think there are ways to prefer certain objects or libs in the
search results, and steer new users to the more reliable and maintained set of externals.
-Jonathan
On Monday, December 22, 2014 5:48 PM, Ivica Bukvic ico@vt.edu wrote:
On Dec 22, 2014 10:23 PM, "Dan Wilcox" danomatika@gmail.com wrote:
On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes jancsika@yahoo.com
wrote:
Unless you want an enormous number of patches in the wild to bit-rot,
you're going to have a "Install Pd-extended libraries" button. If you have that button, then presumably at least _one_ person is going to need to build and test the whole enchilada, no?
I disagree. If it’s easier to build, then it will be easier for a
number of people to test on their respective OS. I assume l2ork doesn’t rely on one person testing and building across multiple platforms? I’ve been in that situation already and it sucks. Much nicer to split up the work, better still if the makefiles work and we have some scripting to handling automation, fetching, etc for developers and volunteer testers.
Actually, you're simply trading one shortcoming for another, and I would
argue you're shortcoming is a lot harder to troubleshoot. If you provide a monolithic distribution to all of your users, then reproducing their problems becomes exponentially easier as opposed to encouraging each user to install select externals which may clash with each other in unusual ways that may not be apparent otherwise and then trying to backtrace and troubleshoot their specific set up as opposed to relying on one monolithic release that you can easily reproduce on your own computer. If we had infinite time on this rock this may be a feasible option. As for me, particularly considering I am doing this not because I am getting paid to do it, monolithic approach is the way to go with the ultimate goal of having all externals in the extra folder and without any subfolders (in part because duplicates and buggy externals will have been weeded out).
BTW for clarification purposes, pd-l2ork is tested by a couple of core
developers, including myself almost on a daily basis, plus 12+ members who have little or no experience with Linux, let alone with PD through the laptop orchestra, and finally a bunch of kids through various k12 education initiatives (who also have little or no knowledge of Linux or PD). I feel that is fairly sufficient for my needs.
Also, to clarify another point that has been brought up several times on
this mailing list, while pd-l2ork does not support Windows or Mac at this time, this is mainly due to lack of human resources, rather than some kind of religious mission. There is clearly an intent on supporting those once we complete port to Qt toolkit. Until then, there is a bootable USB stick that boots on most computers, and has its own environment, including a persistent home directory. There are exceptions-- select laptops that stubbornly lock down their EFI making them not fully compliant with bootable USB stick format. Examples of this that I observed include select Apple hardware (as part of their ongoing "we know better than the user" walled garden initiative) and a few Dell and Alienware machines (in other words, select companies in close relationships with Microsoft).
Btw-- are there poisonous spiders lurking in the Pd-extended
makefiles? Just reading this thread and seeing alternatives like "let's just port apt to some proprietary OSes" seems odd to me…
I agree. I, for one, say let’s make sure the makefiles work well
before getting into package management (if at all).
So I guess I'll add my own idea to this mix: how about replacing
every single external binary with an abstraction? Then the external libs become portable without having to compile a single thing. Plus any Pd user willing to click the object can potentially fix bugs or make improvements. Sure, you can't do Gem and some of the fancy stuff, but those are details. This would also increase the incentives for doing development to the core which makes abstractions faster.
rjlib, etc have done some of this already and I’ve followed when I
started reimplementing my abstraction library. Honestly, I don’t think this community has the resources to tackle an effort like that, regardless of the technical issues that would need to be fixed. I think it’s far more pragmatic to work on making it easier to split up the maintenance work on the existing externals and allow for more people to hep testing, building, and using them outside of a monolithic Pd-extended release. Again, this approach has worked for other projects like OpenFrameworks, so I think it can be applicable to Pd. This way, also, we still allow for the freedom of the users to step up and dictate which externals they want to keep using without throwing out all the work and useful source code that already exists.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
On Dec 23, 2014 1:06 AM, "Jonathan Wilkes" jancsika@yahoo.com wrote:
One thing I'll add-- Pd-extended already includes within it the ability
for individual libraries to be compiled "a la carte" in the way Dan desires. Any library adhering to the "libdir" format will have a standard makefile that can be used to compile the binaries. They'll end up in the same directory with their help patches, which means in most cases they will create properly when the user opens the help patch (even if that library hasn't been loaded yet).
The idea of scripting dependencies across externals is an interesting
one. I don't think that currently happens with Pd-extended. But a lot of libraries do employ [pddp/pddplink] in the documentation, so that feature would be handy in that situation.
Also-- I think weeding out "duplicate" externals is a bad idea, at least
the way Ivica describes it. Many people have built patches with Pd-extended, assuming that all the object names available at startup are essentially like "keywords" in text-based languages. It's unfortunate that [lib1/foo] does the same exact thing as [lib2/bar]. But if I'm trying to show off Pd by playing some fancy synthesizer patch which relies on [lib1/foo], it had better work. I'll always prefer ugly-but-works over clean-but-let-me-debug-this-patch-while-everyone-sits-there-and-waits.
If the weeding is done properly, this alteration will provide adequate feedback, as is the case with cyclone/prepend, or will simply automatically substitute an object, e.g. clashing average implementations, of which one is clearly superior, and yet where both implementations are near synonymous.
Also, let's not forget that extended has already done this before by obsoleting certain libraries.
Anyway, I think there are ways to prefer certain objects or libs in the
search results, and steer new users to the more reliable and maintained set of externals.
-Jonathan
On Monday, December 22, 2014 5:48 PM, Ivica Bukvic ico@vt.edu wrote:
On Dec 22, 2014 10:23 PM, "Dan Wilcox" danomatika@gmail.com wrote:
On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes jancsika@yahoo.com
wrote:
Unless you want an enormous number of patches in the wild to bit-rot,
you're going to have a "Install Pd-extended libraries" button. If you have that button, then presumably at least _one_ person is going to need to build and test the whole enchilada, no?
I disagree. If it’s easier to build, then it will be easier for a
number of people to test on their respective OS. I assume l2ork doesn’t rely on one person testing and building across multiple platforms? I’ve been in that situation already and it sucks. Much nicer to split up the work, better still if the makefiles work and we have some scripting to handling automation, fetching, etc for developers and volunteer testers.
Actually, you're simply trading one shortcoming for another, and I would
argue you're shortcoming is a lot harder to troubleshoot. If you provide a monolithic distribution to all of your users, then reproducing their problems becomes exponentially easier as opposed to encouraging each user to install select externals which may clash with each other in unusual ways that may not be apparent otherwise and then trying to backtrace and troubleshoot their specific set up as opposed to relying on one monolithic release that you can easily reproduce on your own computer. If we had infinite time on this rock this may be a feasible option. As for me, particularly considering I am doing this not because I am getting paid to do it, monolithic approach is the way to go with the ultimate goal of having all externals in the extra folder and without any subfolders (in part because duplicates and buggy externals will have been weeded out).
BTW for clarification purposes, pd-l2ork is tested by a couple of core
developers, including myself almost on a daily basis, plus 12+ members who have little or no experience with Linux, let alone with PD through the laptop orchestra, and finally a bunch of kids through various k12 education initiatives (who also have little or no knowledge of Linux or PD). I feel that is fairly sufficient for my needs.
Also, to clarify another point that has been brought up several times on
this mailing list, while pd-l2ork does not support Windows or Mac at this time, this is mainly due to lack of human resources, rather than some kind of religious mission. There is clearly an intent on supporting those once we complete port to Qt toolkit. Until then, there is a bootable USB stick that boots on most computers, and has its own environment, including a persistent home directory. There are exceptions-- select laptops that stubbornly lock down their EFI making them not fully compliant with bootable USB stick format. Examples of this that I observed include select Apple hardware (as part of their ongoing "we know better than the user" walled garden initiative) and a few Dell and Alienware machines (in other words, select companies in close relationships with Microsoft).
Btw-- are there poisonous spiders lurking in the Pd-extended
makefiles? Just reading this thread and seeing alternatives like "let's just port apt to some proprietary OSes" seems odd to me…
I agree. I, for one, say let’s make sure the makefiles work well before
getting into package management (if at all).
So I guess I'll add my own idea to this mix: how about replacing every
single external binary with an abstraction? Then the external libs become portable without having to compile a single thing. Plus any Pd user willing to click the object can potentially fix bugs or make improvements. Sure, you can't do Gem and some of the fancy stuff, but those are details. This would also increase the incentives for doing development to the core which makes abstractions faster.
rjlib, etc have done some of this already and I’ve followed when I
started reimplementing my abstraction library. Honestly, I don’t think this community has the resources to tackle an effort like that, regardless of the technical issues that would need to be fixed. I think it’s far more pragmatic to work on making it easier to split up the maintenance work on the existing externals and allow for more people to hep testing, building, and using them outside of a monolithic Pd-extended release. Again, this approach has worked for other projects like OpenFrameworks, so I think it can be applicable to Pd. This way, also, we still allow for the freedom of the users to step up and dictate which externals they want to keep using without throwing out all the work and useful source code that already exists.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-
Alessio Degani -
Alexandre Torres Porres -
Dan Wilcox -
Fred Jan Kraan -
Ivica Bukvic -
Jonathan Wilkes