Dear list,
the book sprint for the Pd FLOSS Manual last weekend went very well! Several writers and proofreaders joined us at each location in New York City and Berlin, as well as remote contributors online (see contributors below).
The good news is that quite a lot of content was generated over the weekend, including the beginnings of entirely new sections on GEM, MIDI, Network Data and Sensors. You can see the work-in-progress FLOSS Manual via the editing interface here:
http://en.flossmanuals.net/bin/view/PureData/WebHome
The not-so-good news is that most of these new sections are in limbo! Next month, Adam and I hope to publish version 1.0 of the Pure Data FLOSS Manual to the front page of the FLOSS Manuals site for public viewing:
The chapters that will be included in Version 1.0 will be:
INTRODUCTION INSTALLING GETTING STARTED THE INTERFACE AUDIO TUTORIALS DATAFLOW TUTORIALS STREAMING LIST OF OBJECTS APPENDICES
But in order to do this, some of the chapters in each section need some improvement. Here's what needs to happen immediately. Please take a look and see if you can help!
____ALL CHAPTERS____ --Proofreading for spelling, simplicity, new-user-friendliness and consistent tone (see INSTALLING, GETTING STARTED, THE INTERFACE and AUDIO TUTORIALS chapters for style and format examples).
____AUDIO TUTORIALS___
-> This section is almost done. What remains is to make a proper tutorial out of it... i.e. that the examples in the chapter follow a "story" which leads up the construction of a simple synthesizer. Due to changes in structure of the chapters inside, this needs updating, but I will work on it. -> In general, structure, tone and content of these chapters should serve as guide for the rest of the manual. -> I would like to see all sections follow this tutorial model, of building up a project from the various elements introduced in each chapter. -> keep in mind that other sections (such as MIDI, NETWORK DATA, SENSORS, etc) can build on examples started in this chapter, so that the whole manual is interconnected and has a proper "storyline".
--where does this go? Dataflow or Audio? (Audio I think) --Would be good to integrate with http://en.flossmanuals.net/bin/view/PureData/ArraysGraphsTables --I'd like to crop screenshots to get rid of menu bar --Incomplete, needs expansion and also "loop it" and "play sections" parts --Could this also be structured like tutorial rather than taxonomy?
____DATAFLOW____
--Looks very good!
--"I guess it isn't necessary to explain how [+], [-], [*] and [/] work. " Check for tone. --Bit twiddling: empty --Expr: empty --Audio math: empty
--Needs more than taxonomy, i.e. real world examples!!!!!
--Needs a little attention, but I'm not sure, maybe simpler examples, clearer screenshots, explain object abbreviations in-line if used
--Examples too busy, need to be simpler!!!!!! --Text doesn't really connect to examples
- Subpatches, Abstractions & Dollarsigns
--These should all be in one chapter, explaining how to make reusable patches with nice interfaces, rather than atomized into different chapters(title = Patch Management?)
--Needs final real world example, maybe in connection with abstractions
- GoP
--Tie in with Patch Management (to be created) --Better examples!
--Get rid of this chapter, confusing collision with dollar signs in messages --Better examples, explained in-line in text --Tie in with Patch Management (to be created) --All examples are not saved anywhere!!!!!
--Move to Patch Management (to be created) --Not completely explained (colored background canvas) --No colors in Pd patch screenshots please!
--Check text for clarity, accuracy, simplicity --Redo screenshots with antialiased text please!
___LIST OF OBJECTS____ -> Table format doesn't work in some browsers (Adam Hyde will look into this)
____GLOSSARY____ -> HTML tables don't work well here, Adam Hyde will reformat text with
<h1>, <h2> and <h3 tags>
...and finally, THE CONTRIBUTORS!
Here are the folks that helped us rock last weekend, in no particular order:
AdamHyde DerekHolzer HansChristophSteiner ScottFitzgerald VincentRioux PatrickDavison JoaoPais ServandoBarreiro KorayTahiroglu MariusSchebella JeremySchaller MaxNeupert EvanRaskob GeorgWerner AlexandrePorres JayMaechtlen RomanHaefeli DanielShiffman LauraGarciaBarrio AlejoDuque
(My apologies if I accidentally left someone out!)
Thanks all, I'm looking forward to seeing this 1.0 version looking its best! Derek
I have to teach in the end of the month, it will be a nice opportunity to proof read this before, and collaborate with the feedback you want. GOOD JOB! cheers
On Thu, Apr 9, 2009 at 1:40 PM, Derek Holzer derek@umatic.nl wrote:
Dear list,
the book sprint for the Pd FLOSS Manual last weekend went very well! Several writers and proofreaders joined us at each location in New York City and Berlin, as well as remote contributors online (see contributors below).
The good news is that quite a lot of content was generated over the weekend, including the beginnings of entirely new sections on GEM, MIDI, Network Data and Sensors. You can see the work-in-progress FLOSS Manual via the editing interface here:
http://en.flossmanuals.net/bin/view/PureData/WebHome
The not-so-good news is that most of these new sections are in limbo! Next month, Adam and I hope to publish version 1.0 of the Pure Data FLOSS Manual to the front page of the FLOSS Manuals site for public viewing:
The chapters that will be included in Version 1.0 will be:
INTRODUCTION INSTALLING GETTING STARTED THE INTERFACE AUDIO TUTORIALS DATAFLOW TUTORIALS STREAMING LIST OF OBJECTS APPENDICES
But in order to do this, some of the chapters in each section need some improvement. Here's what needs to happen immediately. Please take a look and see if you can help!
____ALL CHAPTERS____ --Proofreading for spelling, simplicity, new-user-friendliness and consistent tone (see INSTALLING, GETTING STARTED, THE INTERFACE and AUDIO TUTORIALS chapters for style and format examples).
____AUDIO TUTORIALS___
-> This section is almost done. What remains is to make a proper tutorial out of it... i.e. that the examples in the chapter follow a "story" which leads up the construction of a simple synthesizer. Due to changes in structure of the chapters inside, this needs updating, but I will work on it. -> In general, structure, tone and content of these chapters should serve as guide for the rest of the manual. -> I would like to see all sections follow this tutorial model, of building up a project from the various elements introduced in each chapter. -> keep in mind that other sections (such as MIDI, NETWORK DATA, SENSORS, etc) can build on examples started in this chapter, so that the whole manual is interconnected and has a proper "storyline".
--where does this go? Dataflow or Audio? (Audio I think) --Would be good to integrate with http://en.flossmanuals.net/bin/view/PureData/ArraysGraphsTables --I'd like to crop screenshots to get rid of menu bar --Incomplete, needs expansion and also "loop it" and "play sections" parts --Could this also be structured like tutorial rather than taxonomy?
____DATAFLOW____
--Looks very good!
--"I guess it isn't necessary to explain how [+], [-], [*] and [/] work. " Check for tone. --Bit twiddling: empty --Expr: empty --Audio math: empty
--Needs more than taxonomy, i.e. real world examples!!!!!
--Needs a little attention, but I'm not sure, maybe simpler examples, clearer screenshots, explain object abbreviations in-line if used
--Examples too busy, need to be simpler!!!!!! --Text doesn't really connect to examples
- Subpatches, Abstractions & Dollarsigns
--These should all be in one chapter, explaining how to make reusable patches with nice interfaces, rather than atomized into different chapters(title = Patch Management?)
--Needs final real world example, maybe in connection with abstractions + GoP
--Tie in with Patch Management (to be created) --Better examples!
--Get rid of this chapter, confusing collision with dollar signs in messages --Better examples, explained in-line in text --Tie in with Patch Management (to be created) --All examples are not saved anywhere!!!!!
--Move to Patch Management (to be created) --Not completely explained (colored background canvas) --No colors in Pd patch screenshots please!
--Check text for clarity, accuracy, simplicity --Redo screenshots with antialiased text please!
___LIST OF OBJECTS____ -> Table format doesn't work in some browsers (Adam Hyde will look into this)
____GLOSSARY____ -> HTML tables don't work well here, Adam Hyde will reformat text with <h1>,
<h2> and <h3 tags>
...and finally, THE CONTRIBUTORS!
Here are the folks that helped us rock last weekend, in no particular order:
AdamHyde DerekHolzer HansChristophSteiner ScottFitzgerald VincentRioux PatrickDavison JoaoPais ServandoBarreiro KorayTahiroglu MariusSchebella JeremySchaller MaxNeupert EvanRaskob GeorgWerner AlexandrePorres JayMaechtlen RomanHaefeli DanielShiffman LauraGarciaBarrio AlejoDuque
(My apologies if I accidentally left someone out!)
Thanks all, I'm looking forward to seeing this 1.0 version looking its best! Derek
-- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 123: "Once the search has begun, something will be found"
Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
Since it's GPL, I will translate some of them to brazilian portuguese and put into http://artesanato.devolts.org website, ok? This is a new brazilian hacklab weblog we just started...
I should also put it into the http://pt.flossmanuals.net if it could be set, but I think this is an issue to the floss manuals mailing list, right? I will ask for it there when I see that the job will really be done... Then I could try to ignite a local "sprint" also, and give a help about PDcon 09 rumours...
Thanks all of participants for the efforts, you know all the compliments deserved.
see ya
best regards,
glerm
2009/4/9 glerm soares organismo@gmail.com
Since it's GPL, I will translate some of them to brazilian portuguese and put into http://artesanato.devolts.org website, ok? This is a new brazilian hacklab weblog we just started...
In fact, I don't think I will "translate" litteraly, but use as some kind of guide for topics, and maybe use some pictures and examples... Any problem?
see ya
glerm
Hey Glerm,
no problem to borrow, as it's GPL, etc etc. However, if you wanted to engage in actual proper translation then then organization and infrastructure of FLOSS Manuals would be at your disposal. Best to wait until there are some 1.0 and later 2.0 (with sensors, networking, GEM, MIDI, etc) versions to translate of course. But I think Brazilian translation would be a very cool first translation of the releases. Maybe Adam Hyde from FLOSS Manuals could offer some suggestions on how to do it as well. They are actually busy writing a manual on how to translate manuals I believe...
best! D.
glerm soares wrote:
2009/4/9 glerm soares <organismo@gmail.com mailto:organismo@gmail.com>
Since it's GPL, I will translate some of them to brazilian portuguese and put into http://artesanato.devolts.org website, ok? This is a new brazilian hacklab weblog we just started...In fact, I don't think I will "translate" litteraly, but use as some kind of guide for topics, and maybe use some pictures and examples... Any problem?
Hi, I think I may have found a bug. After changing the abstraction argument, nothing comes out of the outlet to the parent patch. I'm on windows; can someone confirm before I post it on the bug tracker?
Thanks, Jonathan
I will set up a translation
i'll send the link soon!
adam
On Fri, 2009-04-10 at 01:57 +0200, Derek Holzer wrote:
Hey Glerm,
no problem to borrow, as it's GPL, etc etc. However, if you wanted to engage in actual proper translation then then organization and infrastructure of FLOSS Manuals would be at your disposal. Best to wait until there are some 1.0 and later 2.0 (with sensors, networking, GEM, MIDI, etc) versions to translate of course. But I think Brazilian translation would be a very cool first translation of the releases. Maybe Adam Hyde from FLOSS Manuals could offer some suggestions on how to do it as well. They are actually busy writing a manual on how to translate manuals I believe...
best! D.
glerm soares wrote:
2009/4/9 glerm soares <organismo@gmail.com mailto:organismo@gmail.com>
Since it's GPL, I will translate some of them to brazilian portuguese and put into http://artesanato.devolts.org website, ok? This is a new brazilian hacklab weblog we just started...In fact, I don't think I will "translate" litteraly, but use as some kind of guide for topics, and maybe use some pictures and examples... Any problem?
2009/4/11 adam hyde adam@flossmanuals.net
I will set up a translation
i'll send the link soon!
adam
Hey Adam, that´s great.
We can put http://estudiolivre.org tutorials there also. There´s lot and lots of FLOSS tutorials there im pt_br, mainly about multimedia tools...
I will sign the FLOSS manuals mailing list and we continue this issue there.
thanx
té+ glerm
hey
the br_pt manual is here:
http://translate.flossmanuals.net/bin/view/PureData_br_pt
info on how to use the translation system is here: http://en.flossmanuals.net/FLOSSManuals/TranslatingAManual
so...which tutorials from estudio livre do u wish to transfer? :)
adam
On Sat, 2009-04-11 at 17:52 -0300, glerm soares wrote:
2009/4/11 adam hyde adam@flossmanuals.net I will set up a translation
i'll send the link soon! adamHey Adam, that´s great.
We can put http://estudiolivre.org tutorials there also. There´s lot and lots of FLOSS tutorials there im pt_br, mainly about multimedia tools...
I will sign the FLOSS manuals mailing list and we continue this issue there.
thanx
té+ glerm
--Looks very good!
thanks,
--"I guess it isn't necessary to explain how [+], [-], [*] and [/] work.
" Check for tone. --Bit twiddling: empty --Expr: empty --Audio math: empty
I'll add that in the next days, or as soon as I can.
Hallo, Jo?o Pais hat gesagt: // Jo?o Pais wrote:
--Looks very good!
thanks,
One remark though: In messages08.pd messages without a symbol/list/float selector ("meta-messages") are called "undefined strings" which I think is misleading and even wrong: Pd vanilla doesn't have proper strings, and these messages are defined like anything else, they even are very common everywhere in Pd ("reset", "set", "read", "open" etc. come to mind).
In messages09.pd ff. a lot of these meta-messages are used, so it's even more misleading to call them undefined strings before.
In the context of this explanation I would just call them "other messages" or meta-messages, which is the term used by Miller, or "custom messages".
Ciao
Frank
Hi Frank,
as I've mentioned before, this obscure and arcane business of many types of messages is probably the most incomprehensible bit for new users coming to Pd. What I'd like to see in this chapter is not just another taxonomy of the different kind of messages Pd has. Rather, I'd like to see clear tutorials with real world examples of why you would use different messages for different purposes instead of presenting a bunch of abstract information right away.
I think the priority for the FLOSS Manual should be to show *why* things are used, rather than to be exhaustive about all the different things that *could* be used. So if obscure details are skipped in the beginning in favor of clarity, I would prefer that. Other, later examples can show the more exotic types and uses of "meta messages" "custom messages" etc, or the distinctions between them when it becomes important.
It's a different approach than most people currently in Pd seem to be used to writing. Probably this has to do with how they learned it...by being given lists of things to memorize! ;-)
best! D.
Frank Barknecht wrote:
Hallo, Jo?o Pais hat gesagt: // Jo?o Pais wrote:
--Looks very good!
thanks,
One remark though: In messages08.pd messages without a symbol/list/float selector ("meta-messages") are called "undefined strings" which I think is misleading and even wrong: Pd vanilla doesn't have proper strings, and these messages are defined like anything else, they even are very common everywhere in Pd ("reset", "set", "read", "open" etc. come to mind).
In messages09.pd ff. a lot of these meta-messages are used, so it's even more misleading to call them undefined strings before.
In the context of this explanation I would just call them "other messages" or meta-messages, which is the term used by Miller, or "custom messages".
Ciao
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
as I've mentioned before, this obscure and arcane business of many types
of messages is probably the most incomprehensible bit for new users
coming to Pd. What I'd like to see in this chapter is not just another
taxonomy of the different kind of messages Pd has. Rather, I'd like to
see clear tutorials with real world examples of why you would use
different messages for different purposes instead of presenting a bunch
of abstract information right away.I think the priority for the FLOSS Manual should be to show *why* things
are used, rather than to be exhaustive about all the different things
that *could* be used.
Meta-messages (I'll use this term now) have a very important "why": In Pd they are generally used to set the status of objects or make them do specific actions. Sending a "stop"-meta-message to [poly] will make it stop playing, sending a "set"-meta-message to a [makefilename] will change the format string, a "set" to a tabread sets the table to read from and so on.
The other messages - float, symbol or list - generally are data carrying messages. Floats to tabread will give the value of that index in the table, symbol to makefilename will apply the format string, lists to [poly] will be tagged with a number and output it. All of these change data and pass it along.
There's lots of potential for explaining the difference with examples taken from daily use.
The distinction between meta-messages and data messages becomes very important in message boxes, which are only doing the expected dollar expansion properly when the incoming message is a data message, and they react to meta messages like "set" in completely different ways.
"Messages in Pd are simewhat artificially divided into two classes. First are data-holding messages (bang, float, symbol, list) which are the primary way of communicating between objects. Second is "everything else" (you could call them out-of-band messages or metamessages) that describe changes in configuration, read and write files, quit Pd, etc. These are provided so that complex objects don't need to have 100 separate inlets for every possible functionality. It's not clear whether this was a good design choice, but it's entrenched."
That's a quote from list-help.pd
So if obscure details are skipped in the beginning
in favor of clarity, I would prefer that. Other, later examples can show
the more exotic types and uses of "meta messages" "custom messages" etc,
or the distinctions between them when it becomes important.
The distincion is important all the time. Even if it's explained in detail later, the terminology should not be different. That's why I recommended to not use "undefined strings" which is not a common term for the messages it refers to, especially as most of http://en.flossmanuals.net/bin/view/PureData/Messages deals with meta-messages and [route]. [route] almost always is used with either number lists or meta-messages, and only very rarely with data messages not starting with a float. (That's why my [route]s often come in tandem with [list trim].)
Ciao
Frank
or you can also make the changes you see fit directly (for now I am too
busy even to finish the math chapter)
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
as I've mentioned before, this obscure and arcane business of many types of messages is probably the most incomprehensible bit for new users coming to Pd. What I'd like to see in this chapter is not just another taxonomy of the different kind of messages Pd has. Rather, I'd like to see clear tutorials with real world examples of why you would use different messages for different purposes instead of presenting a bunch of abstract information right away.
I think the priority for the FLOSS Manual should be to show *why* things are used, rather than to be exhaustive about all the different things that *could* be used.
Meta-messages (I'll use this term now) have a very important "why": In
Pd they are generally used to set the status of objects or make them do specific actions. Sending a "stop"-meta-message to [poly] will make it stop
playing, sending a "set"-meta-message to a [makefilename] will change the format
string, a "set" to a tabread sets the table to read from and so on.The other messages - float, symbol or list - generally are data carrying messages. Floats to tabread will give the value of that index in the
table, symbol to makefilename will apply the format string, lists to [poly]
will be tagged with a number and output it. All of these change data and pass it
along.There's lots of potential for explaining the difference with examples
taken from daily use.The distinction between meta-messages and data messages becomes very important in message boxes, which are only doing the expected dollar
expansion properly when the incoming message is a data message, and they react to
meta messages like "set" in completely different ways."Messages in Pd are simewhat artificially divided into two classes. First are data-holding messages (bang, float, symbol, list) which are the primary way of communicating between objects. Second is "everything else" (you could call them out-of-band messages or metamessages) that describe changes in configuration, read and write files, quit Pd, etc. These are provided so that complex objects don't need to have 100 separate inlets for every possible functionality. It's not clear whether this was a good design choice, but it's entrenched." That's a quote from list-help.pd
So if obscure details are skipped in the beginning in favor of clarity, I would prefer that. Other, later examples can show the more exotic types and uses of "meta messages" "custom messages" etc, or the distinctions between them when it becomes important.
The distincion is important all the time. Even if it's explained in
detail later, the terminology should not be different. That's why I recommended
to not use "undefined strings" which is not a common term for the messages it
refers to, especially as most of
http://en.flossmanuals.net/bin/view/PureData/Messages deals with meta-messages and [route]. [route] almost always is used with
either number lists or meta-messages, and only very rarely with data messages
not starting with a float. (That's why my [route]s often come in tandem with
[list trim].)Ciao
--- On Sat, 4/11/09, Frank Barknecht fbar@footils.org wrote:
From: Frank Barknecht fbar@footils.org Subject: Re: [PD] Pd FLOSS Manual Update pt 1 To: pd-list@iem.at Date: Saturday, April 11, 2009, 8:49 PM Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
as I've mentioned before, this obscure and arcane
business of many types
of messages is probably the most incomprehensible bit
for new users
coming to Pd. What I'd like to see in this chapter
is not just another
taxonomy of the different kind of messages Pd has.
Rather, I'd like to
see clear tutorials with real world examples of why
you would use
different messages for different purposes instead of
presenting a bunch
of abstract information right away.
I think the priority for the FLOSS Manual should be to
show *why* things
are used, rather than to be exhaustive about all the
different things
that *could* be used.
Meta-messages (I'll use this term now) have a very important "why": In Pd they are generally used to set the status of objects or make them do specific actions. Sending a "stop"-meta-message to [poly] will make it stop playing, sending a "set"-meta-message to a [makefilename] will change the format string, a "set" to a tabread sets the table to read from and so on.
The other messages - float, symbol or list - generally are data carrying messages. Floats to tabread will give the value of that index in the table, symbol to makefilename will apply the format string, lists to [poly] will be tagged with a number and output it. All of these change data and pass it along.
There's lots of potential for explaining the difference with examples taken from daily use.
The distinction between meta-messages and data messages becomes very important in message boxes, which are only doing the expected dollar expansion properly when the incoming message is a data message, and they react to meta messages like "set" in completely different ways.
"Messages in Pd are simewhat artificially divided into two classes. First are data-holding messages (bang, float, symbol, list) which are the primary way of communicating between objects. Second is "everything else" (you could call them out-of-band messages or metamessages) that describe changes in configuration, read and write files, quit Pd, etc. These are provided so that complex objects don't need to have 100 separate inlets for every possible functionality. It's not clear whether this was a good design choice, but it's entrenched."
That's a quote from list-help.pd
So if obscure details are skipped in the beginning
in favor of clarity, I would prefer that. Other, laterexamples can show
the more exotic types and uses of "meta
messages" "custom messages" etc,
or the distinctions between them when it becomes
important.
The distincion is important all the time. Even if it's explained in detail later, the terminology should not be different. That's why I recommended to not use "undefined strings" which is not a common term for the messages it refers to, especially as most of http://en.flossmanuals.net/bin/view/PureData/Messages deals with meta-messages and [route]. [route] almost always is used with either number lists or meta-messages, and only very rarely with data messages not starting with a float. (That's why my [route]s often come in tandem with [list trim].)
I agree that meta-messages should be called meta-messages, if they're called anything. But I don't see how to make the distinction clear without having a comprehensive table of relevant pd-vanilla objects and their behavior regarding meta-messages.
Why do the first inlets of pack and symbol accept [pitch( ? Why wouldn't the secondary inlets of pack and symbol accept [pitch( ? Why does the second inlet of [list] accept [pitch( but the first inlet of [makefilename %s] doesn't? How do message-box dollar signs handle meta-messages? How does [list length] handle them? Do you need [list trim] to route a float list by the first value?
-Jonathan
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:
I agree that meta-messages should be called meta-messages, if they're called anything. But I don't see how to make the distinction clear without having a comprehensive table of relevant pd-vanilla objects and their behavior regarding meta-messages. Why do the first inlets of pack and symbol accept [pitch( ? Why wouldn't the secondary inlets of pack and symbol accept [pitch( ?
Or their behaviour regarding data messages: Why doesn't the first inlet of float accept symbol-messages? *Of course* you have to learn each object's behaviour to be able to use it. But if nobody tells you that there's a difference between "pitch" and "symbol pitch" many of the object's behaviour will seem arcane to you.
In fact I believe, that beginners have difficulites to understand messages because their tutors ignore these issues. Maybe they ignore them because they themselves feel uncomfortable with messages, meta-messages, symbols and other magic things - and a tutor needs to understand a topic in a much deeper way than his student.
But people are way too scared of meta-messages. They are nothing special. If you understand the difference between "symbol"- and "float"- messages, there is no problem understanding the difference between a "float"- and a "set"-message or between a "symbol" and a "read"-messages. And you surely are using these messages all the time.
Why does the second inlet of [list] accept [pitch( but the first inlet of [makefilename %s] doesn't?
[list] objects accept everything and convert all incoming messages to data messages, i.e. to list-messages. [list trim] converts back to meta messages.
How do message-box dollar signs handle meta-messages?
They take the first element as selector, and then start counting from there.
How does [list length] handle them?
See above: Like all [list]-objects it first converts to a list.
Do you need [list trim] to route a float list by the first value?
No but it doesn't hurt.
Ciao
Frank
--- On Sun, 4/12/09, Frank Barknecht fbar@footils.org wrote:
From: Frank Barknecht fbar@footils.org Subject: Re: [PD] Pd FLOSS Manual Update pt 1 To: pd-list@iem.at Date: Sunday, April 12, 2009, 8:29 AM Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:
I agree that meta-messages should be called
meta-messages, if
they're called anything. But I don't see how
to make the
distinction clear without having a comprehensive table
of relevant
pd-vanilla objects and their behavior regarding
meta-messages.
Why do the first inlets of pack and symbol accept
[pitch( ?
Why wouldn't the secondary inlets of pack and
symbol accept
[pitch( ?
Or their behaviour regarding data messages: Why doesn't the first inlet of float accept symbol-messages? *Of course* you have to learn each object's behaviour to be able to use it. But if nobody tells you that there's a difference between "pitch" and "symbol pitch" many of the object's behaviour will seem arcane to you.
In fact I believe, that beginners have difficulites to understand messages because their tutors ignore these issues. Maybe they ignore them because they themselves feel uncomfortable with messages, meta-messages, symbols and other magic things - and a tutor needs to understand a topic in a much deeper way than his student.
I'm not comfortable with the right inlet of [symbol] rejecting [pitch(, nor with [pitch( working only in the first inlet of pack. And not so comfortable really with [list one two(--[route one] behaving differently than [list 1 2(--[route 1].
But people are way too scared of meta-messages. They are nothing special. If you understand the difference between "symbol"- and "float"- messages, there is no problem understanding the difference between a "float"- and a "set"-message or between a "symbol" and a "read"-messages. And you surely are using these messages all the time.
Maybe they're nothing special to you because you already understand and are comfortable with all the special cases. But I can imagine a beginner getting really confused over [route symbol] not stripping the selector off of [symbol pitch(. It's confusing and inconsistent, and symbols/lists in Pd are limited enough that a comprehensive list of behaviors for the basic symbol-handling objects is doable. (see below)
Why does the second inlet of [list] accept [pitch( but
the first
inlet of [makefilename %s] doesn't?
[list] objects accept everything and convert all incoming messages to data messages, i.e. to list-messages. [list trim] converts back to meta messages.
How do message-box dollar signs handle meta-messages?
They take the first element as selector, and then start counting from there.
How does [list length] handle them?
See above: Like all [list]-objects it first converts to a list.
Do you need [list trim] to route a float list by the
first value?
No but it doesn't hurt.
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:
I'm not comfortable with the right inlet of [symbol] rejecting [pitch(, nor with [pitch( working only in the first inlet of pack. And not so comfortable really with [list one two(--[route one] behaving differently than [list 1 2(--[route 1].
...
Maybe they're nothing special to you because you already understand and are comfortable with all the special cases. But I can imagine a beginner getting really confused over [route symbol] not stripping the selector off of [symbol pitch(.
How many of your patches actually use [route symbol]?
(In general to strip off selectors, [list trim] should be used nowadays.)
It's confusing and inconsistent, and symbols/lists in Pd are limited enough that a comprehensive list of behaviors for the basic symbol-handling objects is doable. (see below)
Object behaviour is vocabulary - you have to memorize it for each object separately just like irregular verbs. The message system with selector and all that is grammar that describes the general rules to form sentences. The message system itself is easy - it almost fits into this: "a message is a selector + data". Memorizing all objects of course is hard(er), and indeed there are some inconsistencies in objects like [route] stripping off list-, but not symbol-selectors.
But all these things are behaviours of single objects and thus vocabulary. You could write a [route] which would strip off the symbol-selector of "symbol pitch" or which would not strip off any list-selectors. Or build a [symbol] that does accept non-symbol-messages or even floats into its right inlet. Maybe someone already did it as an external.
But they would be different objects - and would still work with the same message system grammar of Pd.
Ciao
Hi Derek,
thanks for your work of getting this all together and reviewing it etc. i liked the sprint and especially liked getting a face connected to some of the names i knew from the list. some questions:
--where does this go? Dataflow or Audio? (Audio I think)
yes i thought audio
--Would be good to integrate with http://en.flossmanuals.net/bin/view/PureData/ArraysGraphsTables
a lot of the things i did are covered there but more in the style of a reference then a story - i tried to have one but i'm confused about
--Could this also be structured like tutorial rather than taxonomy?
what do you mean by taxonomy?
--I'd like to crop screenshots to get rid of menu bar
no problem
--Incomplete, needs expansion and also "loop it" and "play sections" parts
will do that if i have the feeling that its work that is done in a way it is helpful. (the idea was to loop it with line~ and then bring the first part (melodie step sequencer) together with the second by playing samples at different speeds controlled by the sequencer). but just now i dont really understand what i did wrong in order to make it a tutorial. g.
-
adam hyde -
Alexandre Porres -
Derek Holzer -
Frank Barknecht -
Georg Werner -
glerm soares -
hard off -
Jonathan Wilkes -
João Pais