[PD-dev] automated library updates WAS: pd-extended 0.43 release push
Hans-Christoph Steiner
hans at at.or.at
Thu Sep 15 18:19:37 CEST 2011
Hey Joe,
The *-meta.pd file is meant to include things like library name,
description, version, etc. In fact the Library Template build system
gets the version from the meta file.
Just about any library included in Pd-extended has a meta file, and
anything based on the Library Template does too. If you want a good
source of description texts, you can check the Debian packaging files
for any of the library that are in Debian or pure:dyne.
Its not as well documented as it should be, but there is some stuff up
on puredata.info (its still down). Luckily, the file format is really
simple and basically self-explanatory. Just check out the meta files in
each library folder in Pd-extended.
.hc
On Thu, 2011-09-15 at 13:32 +0100, Joe White wrote:
> Hi Jonathan,
>
>
> Thanks for the info!
>
>
> Although this seems to be mainly for internal information within the
> library i.e. object information. (not that this isn't important!).
>
>
> I was wondering whether there is a method for describing a library as
> a whole, such as library name, description, version, etc.. Maybe this
> could be a textfile included within the folder, it would be useful
> for Pd programs to be able to easily parse information regarding each
> library.
>
>
> Does it make sense to duplicate information such as website in every
> help file? Would a centralised info textfile be more appropriate for
> this?
>
>
> Is there any documentation available or just implemented in a few
> libraries and not in others?
>
>
> Cheers,
> Joe
>
> On 14 September 2011 18:11, Jonathan Wilkes <jancsika at yahoo.com>
> wrote:
> 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