[PD] [pd META] metadata format WAS: pd 0.43 branch with the new GUI code
hans at at.or.at
Thu Aug 27 00:43:52 CEST 2009
On Aug 26, 2009, at 4:46 PM, Frank Barknecht wrote:
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>> On Aug 26, 2009, at 3:44 PM, Frank Barknecht wrote:
>>> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>>>> It won't let you go smaller than the menubar on the window.
>>> I think, being able to make a window smaller should be a default
>>> as it is with the old Pd. It definitely should be possible without
>> Ok, so a scriptlet it is. I've never seen any other app that
>> allows you
>> to shrink further than the menubar,
> Uhm, maybe you should look closer? :) Here I can minimize apps like
> Firefox and
> Gvim and hide parts of their menubars and icons.
> Acutally I found, that I still can minimize the Pd main window, the
> menus fold
>> Its a good idea and something that should definitely happen. That's
>> its part of the PDDP templates (http://puredata.info/dev/pddp) but
>> unfortunately not widely implemented. How about following that spec,
>> its close, but a bit simpler and designed to be easily parsed in Pd:
>> * the subpatch is called [pd META], and is not GOP
> GOP is important for us, as the docs are for users to read. We've
> "REFERENCE" to not conflict with META, but of course that would be
> easy to
AFAIK, the GOP status shouldn't affect the parsability. In the .pd
file, it just adds a "#X coords" line before the "#X restore" so it
would be easily ignored. Therefore, both GOP and non-GOP should be
>> * each comment is a whole chunk of data
> Same here, just that "free" comments are allowed as well as additional
> description paragraphs for readability reasons.
How to you mark "free" comments? Once there are keywords, then those
can easily be mistakenly entered in the free comments. To keep the
parsing simple, it makes sense to keep the free comments out out of
the [pd META] subpatch. Then have a
This doesn't have to be any hard fast rule in the implementation. In
effect, if someone writes a comment without a recognized tag, it'll be
a free comment. But I think it would be a good convention to follow:
"each comment in [pd META] counts as a piece of data". There could
also be a comment tag, it could be "#" or "comment".
So like python style: don't force people to do the right thing, but
make the right thing easy to do.
>> * the first word/atom is the datatype (i.e. no : at the end of it),
>> insensitive (removing a : in Pd is a little annoying)
> We have some 2-word keys, like "Outlet 0", so that is a tricky
> Anyway, as our system is mainly intended to be processed by
> "smarter" text
> processing tools, the : doesn't hurt. But maybe we could add spaces
> around it.
How about Outlet0, etc? Its really just a unique ID, so once parsed
the tag could be displayed as whatever.
These rules make it easier to parse in any language too. But I think
its important that the help patches be designed to be read by Pd
patches, since they are pd patches themselves.
>> * tags are space-separated not comma-separated (handling commas is a
>> pain in Pd)
> Again, this is to include tags with more than one word, but I see
> that for Pd
> parsing, the comma is nasty. However I guess with the text processing
> possibilities of tcl available in scriptlets, this may not be an
> issue anymore.
It is not only a question of making the format easy to parse, but also
easy to create. Since it is text included in a Pd patch, it should
follow Pd's syntax rules. Pd is made from [selector arg arg arg], I
think these comments should have the same syntax.
Many tag interfaces use space-separated tags, its a common idiom. It
makes sense with Pd too.
> Generally the "pd REFERENCE" idea was to have a most simple,
> parsable and user-readable reference system. META is cool and was an
> inspiration, but the rest of PDDP was deemed much too bloated with
> conventions and color coding and cnv-paintings and similar stuff to
> be useable
> for us. Help files IMO should be written, not designed.
We are only talking about [pd META], I also agree the PDDP stuff ended
up somewhat bloated. I think we are agreed on the [pd META] goals: as
simple as possible, parsable, user-readable. I hope we don't end up
with a separate, incompatible format unless there is a really good
reason for it.
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
More information about the Pd-list