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

[Alessio Degani]

Hello list,

Here my two cents.

 From PD user POV, I can say that I LOVE pd-vanilla. Mainly beacuse I 
love almost every vanilla-"thing". Just a matter of philosophy. You have 
the base system that you can extend following your needs.

But, there are at least two things that makes pd-extended a desirable 
choice (at least for ME):
1. Intallation on a new machine is almost a matter of few clicks. Im my 
home PC, that's not a problem, but when you are in a tight scheduling, 
that can make the difference.
2. When I work on PD, after hours of patching, I find the pd-extended 
patch rendering UI less tiring than pd-vanilla's one. I'm not the 
"eye-candy" guy, but with the patch rendering of pd-vanilla, after a 
while, I've some difficulties in identify objects at first sight and 
stuff like that (I know, maybe it's just me :) ).

Based on this two "requisites" and recalling other posts in this thread, 
_my_ ideal scenario is the following.
1. Pd-vanilla with the patch rendering of pd-extended (I have no idea of 
the amount of work needed to obtain this, maybe someone has the answer).
2. A BINARY repository, or whatever, that provides a simple way to 
select and install the externels that I need without go to each 
externals developer website, and download, compile, ... .

The number (2) seems to be the most critical step. At this point, 
questions come:
1. Every external works as-is with pd-vanilla?
2. It's clear that the most "efficient" (?) externals repository must be 
platform-based. For example, the most intuitive way to install things 
for an Ubuntu user is to fire up apt/synaptic ad click on this and that 
and click install. But from a developer point of view that means you 
have to create a repository for Ubuntu users, a repo for Fedora, a repo 
for OSX, for WIN, and so on and so forth. I think this strategy can be 
very developer-hungry :) (i.e. one or more mainter for each repo?).
Another "ideal" scenario is to have a pd internal packaging system (i.e. 
a pd menu item called "extensions" that pops up a window in which you 
can chose the extension to install for your PLATFORM). Hummm... it seems 
a LOT of work for this! :)
A trade-off can be a web page, with binary download link. The page can 
be generated automatically, and the duty of the mainters is to compile 
the extensions for different platforms and put those "on the website".

I will be happy to work with anyone who wants to collaborate :)

Ceers

Alessio

On 17/12/2014 17:08, Alexandre Torres Porres wrote:
> Hello, I'm opening a new thread about the new direction of discussion 
> with a proper subject title. Perhaps this will call the attention of 
> other readers.
>
> I particularly think this is of major interest to everyone. We're 
> discussing new ways of using the libraries in Pd Extended into Pd 
> Vanilla, and even a way to bring some of the Pd-extended UI changes 
> into vanilla.
>
> Something Miller brought up in the thread was "/Just FYI…. Joe Deken 
> of newblankets.org <http://newblankets.org/> is considering making a 
> repository of external objects compatible with Pd vanilla.  I think 
> almost all the/
> /objects in Pd extended will work with vanilla (and if I find out what 
> specific changes vanilla would need to allow the others, I'd be happy 
> to try to provide them). It seems like maintaining compiled versions 
> of the //libs is an easier thing to do than maintaining all of Pd 
> Extended/."
>
> So, anyone else care to share their two cents?
>
> cheers
>
> [CUT]

-- 
a.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141218/3905c9e9/attachment.html>