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 <danomat...@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:
1. splitting up the externals makes maintenance an cooperation much easier (aka
Github forking and PRs)
2. 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.deg...@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-requ...@lists.iem.at wrote:
From: Fred Jan Kraan <fjkr...@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 <fjkr...@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.
_______________________________________________
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
