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.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@iem.at
    http://lists.puredata.info/listinfo/pd-dev

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.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.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@iem.at
    >         http://lists.puredata.info/listinfo/pd-dev
    >
    >

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@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.or.at To: Joe White white.joe4@gmail.com Cc: pd-dev@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.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.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@iem.at
     >        http://lists.puredata.info/listinfo/pd-dev
     >
     >

---

Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

---

From: Joe White white.joe4@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; "pd-dev@iem.at" pd-dev@iem.at Sent: Thursday, September 15, 2011 8:32 AM Subject: Re: [PD-dev] automated library updates WAS: pd-extended 0.43 release push

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.

Right, that's in the *-meta.pd patch in the library's directory.

Does it make sense to duplicate information such as website in every help file? Would a centralised info textfile be more appropriate for this?

Actually "WEBSITE" isn't used very often.  But the others-- even AUTHOR-- can be different per class.  Even

LICENSE could potentially be different.

Is there any documentation available or just implemented in a few libraries and not in others?

I think all or most of the libraries have a *-meta.pd patch in them.

-Jonathan

Cheers, Joe

On 14 September 2011 18:11, Jonathan Wilkes jancsika@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.or.at To: Joe White white.joe4@gmail.com Cc: pd-dev@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.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.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@iem.at          >        http://lists.puredata.info/listinfo/pd-dev          >          >

---

Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev