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