[PD-dev] automated library updates WAS: pd-extended 0.43 release push
Jonathan Wilkes
jancsika at yahoo.com
Wed Sep 14 19:11:27 CEST 2011
I haven't done any work with the *-meta.pd files-- mostly because half of the extant
libraries would have the recursive description "A collection of seemingly random objects
created by Author x because Author x needed this collection of objects". Btw-- whoever
created them must have tried to do an automated search/replace that went haywire,
because several of them have comments sitting on top of each other, which makes them
unreadable.
What I've done is add a [pd META] subpatch to each help patch with comments in the
"TAG value1 value2 etc." format. I use the following tags:
ALIAS alias for the object. For trigger, this would be t
KEYWORDS possible values are listed and defined in all_about_help_patches.pd
DESCRIPTION
LICENSE GPL v2 v3 SIBSD (I think there's a tcl/tk license somewhere in there, too)
INLET_0 possible values are: symbol float list bang pointer anything. Also custom
selectors like: set clear etc.
INLET_1
INLET_2
etc.
OUTLET_0
OUTLET_1
etc.
INLET_N this is for an object that can have a variable number of inlets (usually based on
a creation argument. Ex: [pack])
INLET_R refers the the rightmost inlet, for an object like [append] which always takes a
pointer in its last inlet.
OUTLET_N
OUTLET_R
AUTHOR author(s) + author's email, or anything else you want to include here
WEBSITE author's website link
HELP_PATCH_AUTHORS
GENRE omitted for help patches, but you can use it to mark a patch as one of the following:
tutorial all_about_pd. Could probably add "example" as well...
I'm already using these for some searches with my search-plugin.
-Jonathan
----- Original Message -----
> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Joe White <white.joe4 at gmail.com>
> Cc: pd-dev at iem.at
> Sent: Wednesday, September 14, 2011 10:44 AM
> Subject: [PD-dev] automated library updates WAS: pd-extended 0.43 release push
>
>
> I think that at this point, Jonathan Wilkes is the expert on the meta
> data. If you wanted to take on trying to do automatic updates using the
> existing library format [1], that would be awesome. That should be
> possible on any platform. The new downloads section should make it a
> lot easier to automatically find and download updates:
> http://puredata.info/downloads
>
> .hc
>
> [1] http://puredata.info/docs/developer/LibraryTemplate
>
> On Wed, 2011-09-14 at 14:22 +0100, Joe White wrote:
>> Sounds promising Hans,
>>
>>
>> Is there any more info about this meta structure you were referring
>> to. How far has this progressed? What are the implications for
>> existing libraries and for programs trying to interface with it?
>>
>>
>> I'm on OSX and have no knowledge of Debian so I'm not sure how
> helpful
>> I could be. If there is anything I could do let me know. I'm
>> interested in seeing how this would work from a user perspective, e.g.
>> being able to seeing available libraries, downloading and updating
>> them. I'm looking into adding git support in the app I'm writing.
>>
>> Cheers,
>> Joe
>>
>> On 13 September 2011 19:43, Hans-Christoph Steiner <hans at at.or.at>
>> wrote:
>>
>> Hey Joe,
>>
>> This is a great idea that has been talked about in the past
>> every now
>> and then. The big missing piece has always been someone who
>> wants to do
>> the work to implement it. Personally, I've been moving my own
>> Pd
>> packaging work to be based out of Debian. And I've been
>> trying to make
>> a similar process for Pd-extended (see GettingIntoPdextended
>> from the
>> original email) You can see the libraries I maintain because
>> they are
>> (almost) all in Debian:
>>
>> http://qa.debian.org/developer.php?login=hans@eds.org
>>
>> We know have a lot of the pieces in place to make this task a
>> lot
>> easier. For example, the libraries all have *-meta.pd files
>> which
>> contain meta information about the library. Jonathan Wilkes
>> has been
>> doing some great work around the meta data, but the more
>> people working
>> on this stuff, the more that gets done :)
>>
>> .hc
>>
>>
>> On Tue, 2011-09-13 at 17:36 +0100, Joe White wrote:
>> > Hey,
>> >
>> >
>> > Forgive me if this is not totally on topic but I had an idea
>> a while
>> > ago a wondered what the feasibility of it was.
>> >
>> >
>> > I don't really have a great knowledge of the Pd extended
>> package but
>> > how possible would it be to have each library versioned (say
>> on
>> > github) as individual repositories that then get pulled in
>> the build.
>> > Maybe you could see when certain libraries have been changed
>> and
>> > update them on your own machine. Along the idea of how
>> macports
>> > works.
>> >
>> > Again, apologies if this is a really stupid question.
>> >
>> >
>> > Cheers,
>> > Joe
>> >
>> > On 13 September 2011 17:06, Hans-Christoph Steiner
>> <hans at at.or.at>
>> > wrote:
>> >
>> > I was thinking that now would be a good time to
>> start a
>> > release cycle
>> > for Pd-extended 0.43. There is a ton of really
>> useful new
>> > stuff in the
>> > editor with the new gui, plugins, etc. So I'm
>> thinking I'll
>> > delay some
>> > of the library work I've been doing, and revert to
>> the 0.42.5
>> > behavior
>> > of loading a bunch of libraries by default at
>> startup. But I
>> > personally
>> > be dropping my support for a number of included
>> libraries, but
>> > anyone is
>> > welcome to pick them up if they want to see them
>> stay in
>> > Pd-extended.
>> > You can see the state of things here:
>> >
>> > http://puredata.info/docs/LibrariesInPdExtended
>> >
>> > This can be a trial run of the new process of
>> keeping things
>> > in
>> > Pd-extended. Basically, I need to reduce my
>> maintenance load,
>> > I just
>> > can't keep up any more. So I am proposing that
> the
>> new
>> > process for
>> > getting things into a Pd-extended release. First,
>> the new
>> > release
>> > branch will be a copy of the previous release
>> branch. Each
>> > library/doc
>> > has a maintainer, listed on the
>> LibrariesInPdExtended page.
>> > It is that
>> > maintainer's job to update their libraries/docs
> into
>> the
>> > pd-extended
>> > release branch, otherwise the version will be the
>> same as the
>> > previous
>> > version. Each version of a library included in
>> Pd-extended
>> > needs to a
>> > fully released version with a proper version number
>> and a
>> > release posted
>> > on its own page in the
>> http://puredata.info/downloads section,
>> > and
>> > ultimately uploaded to Debian/testing (I'm happy
> to
>> sponsor
>> > people's
>> > packages for upload to Debian once they are ready).
>> The full
>> > process is
>> > documented here:
>> >
>> >
>> http://puredata.info/docs/developer/GettingIntoPdextended
>> >
>> > Comments, feedback, concerns? I'd like to make
> this
>> a much
>> > more open
>> > and participatory process.
>> >
>> > .hc
>> >
>> > _______________________________________________
>> > Pd-dev mailing list
>> > Pd-dev at iem.at
>> > http://lists.puredata.info/listinfo/pd-dev
>> >
>> >
>>
>>
>>
>>
>>
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
More information about the Pd-dev
mailing list