Hallo, I spent some time working on the Pdpedia.
I chose switch~ for the start of a reference article since it's very simple; I think if we can get it looking nice it will be a good step towards describing more complex objects, like the IEMGUIs or [pool].
So, most of my work should be pretty self-explanatory. One question: what is the intent of the "Messages" section? Is this "messages understood by the first inlet"? If so, I guess I should move the "Inlet 0" explanations there and put something like "Inlet 0: 1/0 for DSP On/Off + <Messages>" with a link to that section?
I also made some templates called {{msg}} and {{obj}}. You can see them in action at http://wiki.puredata.info/en/switch%7E. The obj template automatically tries to link the object name, so I suggest (if people like them) that that is the preferred "object linking method". The regular [[link]] can be saved for linking to articles not directly about an object. Blurbs on their usage are at http://wiki.puredata.info/en/Help:Contents.
When I'm feeling saucy I'll see about doing a version for ascii-art patches.
So, it would be nice if everyone could check out and groom the switch~ article so it can be henceforth used as a starting point for cleaning up the rest of the 'pedia. I didn't try using tables yet; maybe they'd be handy for enumerating inlets/outlets etc.
Cheers Luke
hi Luke, this looks great! maybe you can add 1 or 2 pixels of padding to msg and obj, although, I don't know if that would destroy the message box? the message section can be deleted, most of that will be in inlets/outlets, so it is a little bit redundant. but you can also leave it. do you know that it is possible to use images now, so if you want to have a small example patch as an image it would be possible to embed. the next thing I want to do, is to make all fields that are empty disappear in the infobox. there are some details, like I would not capitalize objectnames like Dac~ or Throw~, even if they start a sentence. marius.
Luke Iannini (pd) wrote:
Hallo, I spent some time working on the Pdpedia.
I chose switch~ for the start of a reference article since it's very simple; I think if we can get it looking nice it will be a good step towards describing more complex objects, like the IEMGUIs or [pool].
So, most of my work should be pretty self-explanatory. One question: what is the intent of the "Messages" section? Is this "messages understood by the first inlet"? If so, I guess I should move the "Inlet 0" explanations there and put something like "Inlet 0: 1/0 for DSP On/Off + <Messages>" with a link to that section?
I also made some templates called {{msg}} and {{obj}}. You can see them in action at http://wiki.puredata.info/en/switch%7E. The obj template automatically tries to link the object name, so I suggest (if people like them) that that is the preferred "object linking method". The regular [[link]] can be saved for linking to articles not directly about an object. Blurbs on their usage are at http://wiki.puredata.info/en/Help:Contents.
When I'm feeling saucy I'll see about doing a version for ascii-art patches.
So, it would be nice if everyone could check out and groom the switch~ article so it can be henceforth used as a starting point for cleaning up the rest of the 'pedia. I didn't try using tables yet; maybe they'd be handy for enumerating inlets/outlets etc.
Cheers Luke
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
have a small example patch as an image it would be possible to embed.
I tried this without luck, maybe you can take a look?
the next thing I want to do, is to make all fields that are empty disappear in the infobox.
It looks like you'll need http://meta.wikimedia.org/wiki/Help:ParserFunctions#Installation to do that; then I think it will look something like this:
{| class="infobox borderless" |+ colspan="2" style="text-align:center; font-size: large; background:#ffdead;" | '''{{{name}}}''' |- | colspan="2" style="text-align:center;" | {{{example_image}}}<br>{{{caption|''caption''}}} |- ! [[Description]]: | {{{description|''description is required''}}} {{ #if: {{{abbreviation|}}} | {{!}}- ! [[Abbreviation]]: {{!}} <b>{{{abbreviation|}}}</b> }} |}
Mmm, great : ). (the statement is {{ #if: <condition string> | <then text> }}, but you can't use "|" in the condition or then string (or it will think it is the separator between <condition> and <then>, so you use a template called Template:! which contains | instead. Found at http://meta.wikimedia.org/wiki/Help:ParserFunctions#Caveats and http://meta.wikimedia.org/wiki/Help:Template#A_parameter_value_containing_a_... )
There seems to be a problem with tilde filenames. I don't know if I can fix that quickly, maybe for now use only filenames that do not contain special characters. I will have a closer look at the "if" thing, but I think I tried this when we set up the wiki and it did not work/needs some additional "enable"-switch. But I will try again. marius.
Luke Iannini (pd) wrote:
have a small example patch as an image it would be possible to embed.
I tried this without luck, maybe you can take a look?
the next thing I want to do, is to make all fields that are empty disappear in the infobox.
It looks like you'll need http://meta.wikimedia.org/wiki/Help:ParserFunctions#Installation to do that; then I think it will look something like this:
{| class="infobox borderless" |+ colspan="2" style="text-align:center; font-size: large; background:#ffdead;" | '''{{{name}}}''' |- | colspan="2" style="text-align:center;" | {{{example_image}}}<br>{{{caption|''caption''}}} |- ! [[Description]]: | {{{description|''description is required''}}} {{ #if: {{{abbreviation|}}} | {{!}}- ! [[Abbreviation]]: {{!}} <b>{{{abbreviation|}}}</b> }} |}
Mmm, great : ). (the statement is {{ #if: <condition string> | <then text> }}, but you can't use "|" in the condition or then string (or it will think it is the separator between <condition> and <then>, so you use a template called Template:! which contains | instead. Found at http://meta.wikimedia.org/wiki/Help:ParserFunctions#Caveats and http://meta.wikimedia.org/wiki/Help:Template#A_parameter_value_containing_a_... )
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Luke Iannini (pd) wrote:
Hallo, I spent some time working on the Pdpedia.
I chose switch~ for the start of a reference article since it's very simple; I think if we can get it looking nice it will be a good step towards describing more complex objects, like the IEMGUIs or [pool].
So, most of my work should be pretty self-explanatory. One question: what is the intent of the "Messages" section? Is this "messages understood by the first inlet"? If so, I guess I should move the "Inlet 0" explanations there and put something like "Inlet 0: 1/0 for DSP On/Off + <Messages>" with a link to that section?
well, here starts the great definition chaos on what is message and what is data.
for simplicity i guess that you have 2 choices:
- everything that goes to inlet-0 is a 'message'; in this case i would
suggest to remove the inlet-0 section (rather than the messages section)
- everything that is not one of the predefined types "float", "symbol",
"list" is a 'message'; in this case we would need both a messages- and an inlet0- section.
I also made some templates called {{msg}} and {{obj}}. You can see them in action at http://wiki.puredata.info/en/switch%7E. The obj
_very_ nice
fmdr sIOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Luke Iannini (pd) wrote:
So, most of my work should be pretty self-explanatory. One question: what is the intent of the "Messages" section? Is this "messages understood by the first inlet"? If so, I guess I should move the "Inlet 0" explanations there and put something like "Inlet 0: 1/0 for DSP On/Off + <Messages>" with a link to that section?
well, here starts the great definition chaos on what is message and what is data.
for simplicity i guess that you have 2 choices:
- everything that goes to inlet-0 is a 'message'; in this case i would
suggest to remove the inlet-0 section (rather than the messages section)
- everything that is not one of the predefined types "float", "symbol",
"list" is a 'message'; in this case we would need both a messages- and an inlet0- section.
Hm, but inlets different from inlet0 also may accept different kinds of messages, "pack 0 0 0" vs. "pack s s s" is one example. So I would suggest to remove the "Messages" section and only use Inlet-sections, that explain the various messages and data streams an inlet accepts or expects. But just like Luke I may now understand what Messages was supposed to contain in the first place.
Ciao
Frank Barknecht _ ______footils.org__
On Nov 9, 2007, at 11:20 AM, Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Luke Iannini (pd) wrote:
So, most of my work should be pretty self-explanatory. One
question: what is the intent of the "Messages" section? Is this "messages understood by the first inlet"? If so, I guess I should move the "Inlet 0" explanations there and put something like "Inlet 0: 1/0
for DSP On/Off + <Messages>" with a link to that section?well, here starts the great definition chaos on what is message
and what is data.for simplicity i guess that you have 2 choices:
- everything that goes to inlet-0 is a 'message'; in this case i
would suggest to remove the inlet-0 section (rather than the messages
section)
- everything that is not one of the predefined types "float",
"symbol", "list" is a 'message'; in this case we would need both a messages-
and an inlet0- section.Hm, but inlets different from inlet0 also may accept different kinds of messages, "pack 0 0 0" vs. "pack s s s" is one example. So I would suggest to remove the "Messages" section and only use Inlet-sections, that explain the various messages and data streams an inlet accepts or expects. But just like Luke I may now understand what Messages was supposed to contain in the first place.
I guess the idea of the "messages" section was to list things like
[reset(, [poll 1(, [set blah( etc. that are messages with custom
selectors. AFAIK, it's very rare for these messages to be sent to
anything but the first inlet. Then the "inlets" section would list
the message types that the inlet accepts: (float, pointer, symbol,
list, anything)
That was the reasoning behind separate sections, I don't have a
strong preference either way.
.hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I guess the idea of the "messages" section was to list things like
[reset(, [poll 1(, [set blah( etc. that are messages with custom
selectors. AFAIK, it's very rare for these messages to be sent to
anything but the first inlet.
Well, maybe, but only by convention. OTOH by convention the last inlet in every RRADical object is a meta-message inlet (for OSC-messages). Generally I think, maybe pdpedia better is prepared for the rare as well.
Ciao
Frank Barknecht _ ______footils.org__
On Nov 9, 2007, at 3:52 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I guess the idea of the "messages" section was to list things like [reset(, [poll 1(, [set blah( etc. that are messages with custom selectors. AFAIK, it's very rare for these messages to be sent to anything but the first inlet.
Well, maybe, but only by convention. OTOH by convention the last inlet in every RRADical object is a meta-message inlet (for OSC-messages). Generally I think, maybe pdpedia better is prepared for the rare as well.
In Pd objects, it is only by convention, in the C API, class_addmethod
() doesn't let you choose which inlet to accept on, it always uses
the first inlet AFAIK.
.hc
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
In Pd objects, it is only by convention, in the C API, class_addmethod () doesn't let you choose which inlet to accept on, it always uses
the first inlet AFAIK.
It's been a while since I wrote my last C-external ... :)
Anyway, there definitly are some cases inbetween abstractions and C-externals as well: at least Python and the Lua loader let you write objects that accept meta-messages in any inlet.
Ciao
Frank Barknecht _ ______footils.org__
On Nov 9, 2007, at 6:05 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
In Pd objects, it is only by convention, in the C API,
class_addmethod () doesn't let you choose which inlet to accept on, it always uses the first inlet AFAIK.It's been a while since I wrote my last C-external ... :)
Anyway, there definitly are some cases inbetween abstractions and C-externals as well: at least Python and the Lua loader let you write objects that accept meta-messages in any inlet.
I think it's probably a good convention to stick to, even in Python,
Lua, etc, but I could be wrong.
.hc
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think it's probably a good convention to stick to, even in Python,
Lua, etc, but I could be wrong.
I agree about the convention, but:
Does pdpedia aim to be a reference or a style guide?
Ciao
Frank Barknecht _ ______footils.org__
On Nov 10, 2007, at 2:47 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think it's probably a good convention to stick to, even in Python, Lua, etc, but I could be wrong.
I agree about the convention, but:
Does pdpedia aim to be a reference or a style guide?
It should show the world as it is, like an encyclopedia, IMHO.
.hc
¡El pueblo unido jamás será vencido!
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 10, 2007, at 2:47 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think it's probably a good convention to stick to, even in Python, Lua, etc, but I could be wrong.
I agree about the convention, but:
Does pdpedia aim to be a reference or a style guide?
It should show the world as it is, like an encyclopedia, IMHO.
Well, then I think the division between what's in the section "Messages" and the section for inlet0 is artificial and I would suggest to drop "Messages". Everything then can be dealt with in the "Inlet X" sections.
Ciao
Frank Barknecht _ ______footils.org__
On Nov 10, 2007, at 12:58 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 10, 2007, at 2:47 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think it's probably a good convention to stick to, even in
Python, Lua, etc, but I could be wrong.I agree about the convention, but:
Does pdpedia aim to be a reference or a style guide?
It should show the world as it is, like an encyclopedia, IMHO.
Well, then I think the division between what's in the section "Messages" and the section for inlet0 is artificial and I would suggest to drop "Messages". Everything then can be dealt with in the "Inlet X" sections.
Fine by me.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
Hans-Christoph Steiner wrote:
In Pd objects, it is only by convention, in the C API, class_addmethod () doesn't let you choose which inlet to accept on, it always uses
the first inlet AFAIK.
but of course this can be worked around by proxies: e.g. zexy's [multiplex] is a c-implementation that eats any message on all inlets (but the last).
however, in the case of [multiplex] "messages" are acutally treated as "data", therefore the distinction blurs, but this is because [multiplex], like [route], is more a "system"-object that is to be used to _control_ the data-flow, rather than an ordinary object.
fma.sdr IOhannes
On Sat, 10 Nov 2007, IOhannes m zmoelnig wrote:
however, in the case of [multiplex] "messages" are acutally treated as "data", therefore the distinction blurs, but this is because [multiplex], like [route], is more a "system"-object that is to be used to _control_ the data-flow, rather than an ordinary object.
This is because it makes you think of control-flow statements in C, which are special, as you can't define any new (except some macro tricks), and functions cannot fulfill the same role.
Several languages allow you to define control-flow statements because they look like any other functions. there are anonymous sub-functions that act like the blocks of a control-flow statements. In some of those languages, all control-flow statements are functions.
In Pd, all control-flow statements are objects, and there is no need to draw a line between "system" and "non-system". There are more useful lines to draw, such as "behaves like [pack] followed by an object followed by [unpack]" or "behaves like [timer]", as a way to tell quickly what an object is supposed to be used like.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Very nice job !
Jack
Le 9 nov. 07 à 14:13, Luke Iannini (pd) a écrit :
Hallo, I spent some time working on the Pdpedia.
I chose switch~ for the start of a reference article since it's very simple; I think if we can get it looking nice it will be a good step towards describing more complex objects, like the IEMGUIs or [pool].
So, most of my work should be pretty self-explanatory. One question: what is the intent of the "Messages" section? Is this "messages understood by the first inlet"? If so, I guess I should move the "Inlet 0" explanations there and put something like "Inlet 0: 1/0 for DSP On/Off + <Messages>" with a link to that section?
I also made some templates called {{msg}} and {{obj}}. You can see them in action at http://wiki.puredata.info/en/switch%7E. The obj template automatically tries to link the object name, so I suggest (if people like them) that that is the preferred "object linking method". The regular [[link]] can be saved for linking to articles not directly about an object. Blurbs on their usage are at http://wiki.puredata.info/en/Help:Contents.
When I'm feeling saucy I'll see about doing a version for ascii-art
patches.So, it would be nice if everyone could check out and groom the switch~ article so it can be henceforth used as a starting point for cleaning up the rest of the 'pedia. I didn't try using tables yet; maybe they'd be handy for enumerating inlets/outlets etc.
Cheers Luke
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Very nice work, and thanks for taking the initiative to do this. A
couple of comments (and since it's a wiki, I made some changes to the
page, we can always revert if people don't like them:)
- I made a the boxes a bit bigger and lightened the grey border to
try to enhance readability. Hopefully y'all like it.
- which reminds me, another thing to tackle is fixing the Infobox
template to hide fields that aren't filled in. The wikipedia Infobox
templates do that.
- I am not sure about where examples should go. It seems to me that
the inlets section should just be a reference section, then there
should be a separate section with examples.
- instead of ASCII patches, I think we should include screenshots. I
guess ASCII patches are quicker, and are better than nothing.
- the "Notes" section is a bit vague. if it is important
information, it should be included in the description. I was
thinking that we could have more specific sections for adding info,
like "Bugs", "Tips & Tricks", etc.
.hc
On Nov 9, 2007, at 8:13 AM, Luke Iannini (pd) wrote:
Hallo, I spent some time working on the Pdpedia.
I chose switch~ for the start of a reference article since it's very simple; I think if we can get it looking nice it will be a good step towards describing more complex objects, like the IEMGUIs or [pool].
So, most of my work should be pretty self-explanatory. One question: what is the intent of the "Messages" section? Is this "messages understood by the first inlet"? If so, I guess I should move the "Inlet 0" explanations there and put something like "Inlet 0: 1/0 for DSP On/Off + <Messages>" with a link to that section?
I also made some templates called {{msg}} and {{obj}}. You can see them in action at http://wiki.puredata.info/en/switch%7E. The obj template automatically tries to link the object name, so I suggest (if people like them) that that is the preferred "object linking method". The regular [[link]] can be saved for linking to articles not directly about an object. Blurbs on their usage are at http://wiki.puredata.info/en/Help:Contents.
When I'm feeling saucy I'll see about doing a version for ascii-art
patches.So, it would be nice if everyone could check out and groom the switch~ article so it can be henceforth used as a starting point for cleaning up the rest of the 'pedia. I didn't try using tables yet; maybe they'd be handy for enumerating inlets/outlets etc.
Cheers Luke
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
-
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jack -
Luke Iannini (pd) -
marius schebella -
Mathieu Bouchard