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