>________________________________ >From: Joe White <[email protected]> >To: Jonathan Wilkes <[email protected]> >Cc: Hans-Christoph Steiner <[email protected]>; "[email protected]" <[email protected]> >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 <[email protected]> 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 <[email protected]> >>> To: Joe White <[email protected]> >>> Cc: [email protected] >>> 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 <[email protected]> >>>> 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/[email protected] >>>> >>>> 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 >>>> <[email protected]> >>>> > 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 >>>> > [email protected] >>>> > http://lists.puredata.info/listinfo/pd-dev >>>> > >>>> > >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Pd-dev mailing list >>> [email protected] >>> http://lists.puredata.info/listinfo/pd-dev >>> >> > > > _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
