n Wilcox mailto:danomat...@gmail.com>>
> Date: December 23, 2014 at 3:16:12 AM EST
> Subject: Re: [PD] [Bulk] Re: [Bulk] Extending Vanilla (was Cyclone help
> patches & issue list)
>
>
>
> On Dec 23, 2014 1:53 AM, "Dan Wilcox" <mailto:danomat...@
On Dec 23, 2014 1:53 AM, "Dan Wilcox" 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 wi
On Dec 23, 2014 1:06 AM, "Jonathan Wilkes" 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
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 l2or
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 di
On Dec 22, 2014 10:23 PM, "Dan Wilcox" wrote:
>
>
>> On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes 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 _o
> On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes 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
> te
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 lurki
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"
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 li
If we separate the externals into repos with a standardized Makefile, I imagine
they should build fine for both vanilla and l2ork. I see overlap here that’s
more advantageous then having all the former Pd-extended externals being
maintained on Sourceforge and updated on Github for l2ork.
Again,
On Dec 20, 2014 2:05 PM, "Alexandre Torres Porres" 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
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, b
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
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
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:
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)
On 18/12/2014 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.
I totally agree with you
17 matches
Mail list logo
