Re: [PD] Pd FLOSS Manual Update pt 1
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd FLOSS Manual Update pt 1
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd FLOSS Manual Update pt 1
--- On Sun, 4/12/09, Frank Barknecht f...@footils.org wrote: From: Frank Barknecht f...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd FLOSS Manual Update pt 1
Hallo, Jo?o Pais hat gesagt: // Jo?o Pais wrote: * http://en.flossmanuals.net/bin/view/PureData/Messages --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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd FLOSS Manual Update pt 1
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: * http://en.flossmanuals.net/bin/view/PureData/Messages --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 -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 146: Spectrum analysis ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd FLOSS Manual Update pt 1
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd FLOSS Manual Update pt 1
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 -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd FLOSS Manual Update pt 1
--- On Sat, 4/11/09, Frank Barknecht f...@footils.org wrote: From: Frank Barknecht f...@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, 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].) 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd FLOSS Manual Update pt 1
* http://en.flossmanuals.net/bin/view/PureData/Messages --Looks very good! thanks, * http://en.flossmanuals.net/bin/view/PureData/Math --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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Pd FLOSS Manual Update pt 1
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: http://en.flossmanuals.net/ 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. * http://en.flossmanuals.net/bin/view/PureData/Tables --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 * http://en.flossmanuals.net/bin/view/PureData/Messages --Looks very good! * http://en.flossmanuals.net/bin/view/PureData/Math --I guess it isn't necessary to explain how [+], [-], [*] and [/] work. Check for tone. --Bit twiddling: empty --Expr: empty --Audio math: empty * http://en.flossmanuals.net/bin/view/PureData/Lists --Needs more than taxonomy, i.e. real world examples! * http://en.flossmanuals.net/bin/view/PureData/OrderOfOperations --Needs a little attention, but I'm not sure, maybe simpler examples, clearer screenshots, explain object abbreviations in-line if used * http://en.flossmanuals.net/bin/view/PureData/WirelessConnections --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?) * http://en.flossmanuals.net/bin/view/PureData/Subpatches --Needs final real world example, maybe in connection with abstractions + GoP * http://en.flossmanuals.net/bin/view/PureData/Abstractions --Tie in with Patch Management (to be created) --Better examples! * http://en.flossmanuals.net/bin/view/PureData/DollarSigns --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! * http://en.flossmanuals.net/bin/view/PureData/GraphOnParent --Move to Patch Management (to be created) --Not completely explained (colored background canvas) --No colors in Pd patch screenshots please! * http://en.flossmanuals.net/bin/view/PureData/ArraysGraphsTables --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
