[PD] [Bulk] Re: [Bulk] Extending Vanilla (was Cyclone help patches & issue list)

Mon Dec 22 08:55:48 CET 2014

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 at 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.degani at 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 at lists.iem.at wrote: 
  From: Fred Jan Kraan <fjkraan at xs4all.nl>
  To: pd-list at 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 at 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 at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

 -- 
a. 
_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141222/d644906b/attachment-0001.html>