hi all,
i moved to ubuntu 9.04 recently.. my kernel is 2.6.28-11-generic
the issue is that the adc~ object (pd vanilla) doesn't respond, no input is processed :(
what i found strange is that i can actually hear the mic and line inputs, even change their volume or mute them, etc. from the system mixer.. but pd ignore them completely!
i need help for connecting my midi controllers too, well.. it's being hard for me (my first times on linux stuff)
regards!
Gabriel Vinazza wrote:
what i found strange is that i can actually hear the mic and line inputs, even change their volume or mute them, etc. from the system mixer.. but pd ignore them completely!
i need help for connecting my midi controllers too, well.. it's being hard for me (my first times on linux stuff)
to get started on this take a look at the manual, try the help menu ... the html manual was probably installed along with Pd, look at
getting pd to run >> audio and midi
it will explain how to select the right audio and midi inputs.
Simon
[list one two three(
How should the help patches refer to "one" above: as the first element or the first item in the list? Currently the reference docs use both, and I'd like to pick one and stick to it.
-Jonathan
That's a good point and a tough question. It should be consistently documented, but its not totally clear how. My guess right now, says that atom selectors should not be considered an 'element'. So these would be both 3 element lists:
list one two three 1 2 3
Check the Pd Definitions wiki on http://puredata.info/dev for some discussion on this stuff. And please add anything there that you think should be there.
.hc
Jonathan Wilkes wrote:
[list one two three(
How should the help patches refer to "one" above: as the first element or the first item in the list? Currently the reference docs use both, and I'd like to pick one and stick to it.
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--- On Sun, 8/9/09, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Help Docs: element vs. item To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "puredata mailing list" pd-list@iem.at Date: Sunday, August 9, 2009, 9:37 PM
That's a good point and a tough question. It should be consistently documented, but its not totally clear how. My guess right now, says that atom selectors should not be considered an 'element'. So these would be both 3 element lists:
list one two three 1 2 3
Check the Pd Definitions wiki on http://puredata.info/dev for some discussion on this stuff. And please add anything there that you think should be there.
On the Pd Definitions wiki, they are referred to as elements, and I've already changed the reference patches to reflect this. Because of the way they are laid out, I don't think there is any ambiguity between first element and selector in the help patches (I don't think "selector" is used in any of them, but I'll check and make sure).
Each help patch also has a common [help] abstraction at the bottom, which has a place for definitions. I haven't gotten to it yet, but when I do I'll explore the definitions wiki in more detail.
-Jonathan
.hc
Jonathan Wilkes wrote:
[list one two three(
How should the help patches refer to "one" above: as
the first element or the first item in the list? Currently the reference docs use both, and I'd like to pick one and stick to it.
-Jonathan
_______________________________________________ Pd-list@iem.at
mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 9 Aug 2009, Jonathan Wilkes wrote:
--- On Sun, 8/9/09, Hans-Christoph Steiner hans@at.or.at wrote:
Check the Pd Definitions wiki on http://puredata.info/dev for some discussion on this stuff. And please add anything there that you think should be there.
On the Pd Definitions wiki, they are referred to as elements, and I've already changed the reference patches to reflect this.
I wouldn't quite advocate using the PdDefinitions as they are now. Much of the way people talk about pd is ambiguous, and that includes Miller too. The Pd Manual itself has a fair amount of vague talk, but then, the PdDefinitions page handpicks quotes in it without regard to whether "the definition of float" is about float-values, float-atoms, floatatom-objects, the floatatom class, the strings recognised as floats, or the strings that floats are outputted as; and likewise for several other definitions lifted from the manual.
"atoms are either numbers or symbols" -> that's only when you look at what you can write in a messagebox that can end up as-is in a message. This ignore comma atoms, semicolon atoms, dollar atoms ($1), dollsym atoms ($1-blah), and pointer atoms (which can't be produced by the parser).
"There are two atom boxes, floatatom and symbolatom" -> this is irrelevant to the definition of an atom, of a float, or of a symbol, in that you could make patches without ever using any atomboxes and you could still see all the characteristics of float values and symbol values shine through.
"Anything that is not a valid number is considered a symbol." -> this is only in the context of parsing, and only once the commas and semicolons are dealt with.
"The selector is a symbol, which appears in the patch as a non-numeric string with no white space, semicolons, or commas." -> the manual doesn't take into account any weird thing you can do in Pd, even with pure pd, and even without hand-editing any .pd files. E.g. this patch:
#N canvas 0 0 450 300 10; #X obj 12 31 makefilename %d; #X msg 12 13 123; #X msg 12 67; #X msg 12 49 set $1 , bang; #X obj 12 85 f; #X connect 0 0 3 0; #X connect 1 0 0 0; #X connect 2 0 4 0; #X connect 3 0 2 0;
ends up saying:
no method for '123'
but "no method for" errors always state the selector, and here, 123 is a selector, which is a symbol, but is printed in a way that makes it look like a float.
Because of the way they are laid out, I don't think there is any ambiguity between first element and selector in the help patches (I don't think "selector" is used in any of them, but I'll check and make sure).
Selector ought to be used to talk about all those so-called "meta-messages", not only because the Pd Manual does, but also because the manuals of several other programming languages call that same thing by the same name. It's not like selectors are a weird thing from outerspace that got stuck into Pd for no reason (even though some facts about Pd's selectors are a bit weird).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
--- On Mon, 8/10/09, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Help Docs: element vs. item To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Hans-Christoph Steiner" hans@at.or.at, "puredata mailing list" pd-list@iem.at Date: Monday, August 10, 2009, 6:05 AM On Sun, 9 Aug 2009, Jonathan Wilkes wrote:
--- On Sun, 8/9/09, Hans-Christoph Steiner hans@at.or.at
wrote:
Check the Pd Definitions wiki on http://puredata.info/dev for some discussion on this stuff. And please add anything there that you
think
should be there.
On the Pd Definitions wiki, they are referred to as
elements, and I've
already changed the reference patches to reflect
this.
I wouldn't quite advocate using the PdDefinitions as they are now. Much of the way people talk about pd is ambiguous, and that includes Miller too. The Pd Manual itself has a fair amount of vague talk, but then, the PdDefinitions page handpicks quotes in it without regard to whether "the definition of float" is about float-values, float-atoms, floatatom-objects, the floatatom class, the strings recognised as floats, or the strings that floats are outputted as; and likewise for several other definitions lifted from the manual.
"atoms are either numbers or symbols" -> that's only when you look at what you can write in a messagebox that can end up as-is in a message. This ignore comma atoms, semicolon atoms, dollar atoms ($1), dollsym atoms ($1-blah), and pointer atoms (which can't be produced by the parser).
"There are two atom boxes, floatatom and symbolatom" -> this is irrelevant to the definition of an atom, of a float, or of a symbol, in that you could make patches without ever using any atomboxes and you could still see all the characteristics of float values and symbol values shine through.
"Anything that is not a valid number is considered a symbol." -> this is only in the context of parsing, and only once the commas and semicolons are dealt with.
"The selector is a symbol, which appears in the patch as a non-numeric string with no white space, semicolons, or commas." -> the manual doesn't take into account any weird thing you can do in Pd, even with pure pd, and even without hand-editing any .pd files. E.g. this patch:
#N canvas 0 0 450 300 10; #X obj 12 31 makefilename %d; #X msg 12 13 123; #X msg 12 67; #X msg 12 49 set $1 , bang; #X obj 12 85 f; #X connect 0 0 3 0; #X connect 1 0 0 0; #X connect 2 0 4 0; #X connect 3 0 2 0;
ends up saying:
no method for '123'
but "no method for" errors always state the selector, and here, 123 is a selector, which is a symbol, but is printed in a way that makes it look like a float.
Because of the way they are laid out, I don't think
there is any ambiguity between first element and selector in the help patches (I don't think "selector" is used in any of them, but I'll check and make sure).
Selector ought to be used to talk about all those so-called "meta-messages", not only because the Pd Manual does, but also because the manuals of several other programming languages call that same thing by the same name. It's not like selectors are a weird thing from outerspace that got stuck into Pd for no reason (even though some facts about Pd's selectors are a bit weird).
Other than the help patch for [list], the term "selector" hasn't come up much because each inlet/outlet just has a list of accepted messages and a description. So for the left inlet of [delay], "bang", "float", and "stop" are listed (without quotes), and the description for "stop" is the phrase "causes [delay] to cancel its scheduled output." When referencing selectors I've just been using a phrase like "sending a 'stop' message." This fits the terminology that is already in the bulk of the help patches, and I think the meaning is clear.
The word "selector" appears mainly where the presence or absence of a selector could easily lead to confusion- in a subpatch in print-help.pd, route-help.pd, and probably for [symbol] and [list] though I haven't done those yet. Unlike the word "message" (or the word "word"), I think "selector" requires a definition when it is used, or at least a reference to the manual where it is explained in detail.
-Jonathan
On Sun, 9 Aug 2009, Jonathan Wilkes wrote:
Other than the help patch for [list], the term "selector" hasn't come up much because each inlet/outlet just has a list of accepted messages and a description.
Actually, "selector" would be the most sensible column name for the column that lists "the accepted messages"...
The word "selector" appears mainly where the presence or absence of a selector could easily lead to confusion- in a subpatch in print-help.pd, route-help.pd, and probably for [symbol] and [list]
right.
Unlike the word "message" (or the word "word"), I think "selector" requires a definition when it is used, or at least a reference to the manual where it is explained in detail.
"message" also "requires" a definition as much as anything else, but in the Pd world, there's a greater tendency to let the people just guess what something is and figure out just as much as they need to know... if they can figure it out (which may be somewhat more difficult to do than to believe to have figured it out).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
--- On Wed, 8/12/09, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Help Docs: element vs. item To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Hans-Christoph Steiner" hans@at.or.at, "puredata mailing list" pd-list@iem.at Date: Wednesday, August 12, 2009, 10:20 PM On Sun, 9 Aug 2009, Jonathan Wilkes wrote:
Other than the help patch for [list], the term
"selector" hasn't come up much because each inlet/outlet just has a list of accepted messages and a description.
Actually, "selector" would be the most sensible column name for the column that lists "the accepted messages"...
It would, but there currently aren't column names in the pddp template.
Are you looking at a different template than the one for [float] in
pd-ext?
The word "selector" appears mainly where the presence
or absence of a selector could easily lead to confusion- in a subpatch in print-help.pd, route-help.pd, and probably for [symbol] and [list]
right.
Unlike the word "message" (or the word "word"), I
think "selector" requires a definition when it is used, or at least a reference to the manual where it is explained in detail.
"message" also "requires" a definition as much as anything else, but in the Pd world, there's a greater tendency to let the people just guess what something is and figure out just as much as they need to know... if they can figure it out (which may be somewhat more difficult to do than to believe to have figured it out).
Hmm...I don't think these more general terms require definitions, because they are superficially describing what one types to produce the desired behavior. There's an implicit step when the term "message" is used (i.e., typing something in a message box and sending it to the object). But if you look at the Max docs where they say, "the word 'set' followed by a number", there's not even that.
If "selector" is going to be used in all the help patches, it should also appear as common parlance in the tutorials (especially the first few where messages and message boxes are discussed).
-Jonathan
On Wed, 12 Aug 2009, Jonathan Wilkes wrote:
--- On Wed, 8/12/09, Mathieu Bouchard matju@artengine.ca wrote:
Actually, "selector" would be the most sensible column name for the column that lists "the accepted messages"...
It would, but there currently aren't column names in the pddp template. Are you looking at a different template than the one for [float] in pd-ext?
I'm not looking at a template, why?
Hmm...I don't think these more general terms require definitions, because they are superficially describing what one types to produce the desired behavior.
I don't think that it's a good idea to directly connect "what you type" with "what you get", except in examples. The theory should connect "what you type" with an internal representation, and connect the internal representation with "what you get", or any other number of intermediate steps, whatever is needed to make people distinguish between "a symbol" and "the spelling out of a symbol by a user" and "the printing out of the symbol by pd" and other things.
It's more obvious (and more critical) if you think of the float situation.
There's an implicit step when the term "message" is used (i.e., typing something in a message box and sending it to the object). But if you look at the Max docs where they say, "the word 'set' followed by a number", there's not even that.
And so... how are the Max docs related to how Pd should be documented?...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Aug 12, 2009, at 6:22 PM, Mathieu Bouchard wrote:
On Wed, 12 Aug 2009, Jonathan Wilkes wrote:
--- On Wed, 8/12/09, Mathieu Bouchard matju@artengine.ca wrote:
Actually, "selector" would be the most sensible column name for the column that lists "the accepted messages"...
It would, but there currently aren't column names in the pddp
template. Are you looking at a different template than the one for [float] in pd-ext?I'm not looking at a template, why?
Hmm...I don't think these more general terms require definitions,
because they are superficially describing what one types to produce
the desired behavior.I don't think that it's a good idea to directly connect "what you
type" with "what you get", except in examples. The theory should
connect "what you type" with an internal representation, and connect
the internal representation with "what you get", or any other number
of intermediate steps, whatever is needed to make people distinguish
between "a symbol" and "the spelling out of a symbol by a user" and
"the printing out of the symbol by pd" and other things.It's more obvious (and more critical) if you think of the float
situation.There's an implicit step when the term "message" is used (i.e.,
typing something in a message box and sending it to the object).
But if you look at the Max docs where they say, "the word 'set'
followed by a number", there's not even that.And so... how are the Max docs related to how Pd should be
documented?...
They are widely regarded and good to learn from, and Pd is part of the
Max family.
.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
On Wed, 12 Aug 2009, Hans-Christoph Steiner wrote:
On Aug 12, 2009, at 6:22 PM, Mathieu Bouchard wrote:
There's an implicit step when the term "message" is used (i.e., typing something in a message box and sending it to the object). But if you look at the Max docs where they say, "the word 'set' followed by a number", there's not even that.
And so... how are the Max docs related to how Pd should be documented?...
They are widely regarded and good to learn from, and Pd is part of the Max family.
Yeah, but that doesn't give a specific reason why a specific aspect of the Max docs should be the reference in the case of this specific question.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Aug 13, 2009, at 12:59 PM, Mathieu Bouchard wrote:
On Wed, 12 Aug 2009, Hans-Christoph Steiner wrote:
On Aug 12, 2009, at 6:22 PM, Mathieu Bouchard wrote:
There's an implicit step when the term "message" is used (i.e.,
typing something in a message box and sending it to the object).
But if you look at the Max docs where they say, "the word 'set'
followed by a number", there's not even that.And so... how are the Max docs related to how Pd should be
documented?...They are widely regarded and good to learn from, and Pd is part of
the Max family.Yeah, but that doesn't give a specific reason why a specific aspect
of the Max docs should be the reference in the case of this specific
question.
Pd's type system is directly related to Max/MSP's type system. That's
a good reason to read the Max/MSP docs.
.hc
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
--- On Wed, 8/12/09, Mathieu Bouchard matju@artengine.ca
wrote:
Actually, "selector" would be the most sensible
column name
for the column that lists "the accepted
messages"...
It would, but there currently aren't column names in
the pddp template.
Are you looking at a different template than the one
for [float] in
pd-ext?
I'm not looking at a template, why?
Because I'm using the pddp template to revise the help patches. I don't see a simple way to add column headings to the templates. Were you suggesting adding column headings, or something else?
Hmm...I don't think these more general terms require
definitions, because they are superficially describing what one types to produce the desired behavior.
I don't think that it's a good idea to directly connect "what you type" with "what you get", except in examples. The theory should connect "what you type" with an internal representation, and connect the internal representation with "what you get", or any other number of intermediate steps, whatever is needed to make people distinguish between "a symbol" and "the spelling out of a symbol by a user" and "the printing out of the symbol by pd" and other things.
It's more obvious (and more critical) if you think of the float situation.
I don't think I understand your point. A float is referred to as a "float" in the help patches. The patches don't refer to a "float message," or "float selector." So I don't see a problem with how float is handled in the current docs.
So I wouldn't connect "what you type" with "what you get" in the case of float, but I don't see the problem of doing this with "the set message."
There's an implicit step when the term "message"
is used (i.e., typing something in a message box and sending it to the object). But if you look at the Max docs where they say, "the word 'set' followed by a number", there's not even that.
And so... how are the Max docs related to how Pd should be documented?...
I thought I could leave it unwritten: But if you look at the Max docs where they say, "the word 'set' followed by a number", there's not even that. Yet the wording is clear, succinct, and unambiguous.
-Jonathan
On Wed, 12 Aug 2009, Jonathan Wilkes wrote:
--- On Wed, 8/12/09, Mathieu Bouchard matju@artengine.ca
I'm not looking at a template, why?
Because I'm using the pddp template to revise the help patches. I don't see a simple way to add column headings to the templates. Were you suggesting adding column headings, or something else?
Oh, column headings wouldn't have hurt, but I'm not gonna advocate it as long as PDDP doesn't have massive shortcuts for things like that... else it's a lot of wasted time.
I don't think that it's a good idea to directly connect "what you type" with "what you get", except in examples. The theory should connect "what you type" with an internal representation, and connect the internal representation with "what you get", or any other number of intermediate steps, whatever is needed to make people distinguish between "a symbol" and "the spelling out of a symbol by a user" and "the printing out of the symbol by pd" and other things. It's more obvious (and more critical) if you think of the float situation.
I don't think I understand your point. A float is referred to as a "float" in the help patches. The patches don't refer to a "float message," or "float selector." So I don't see a problem with how float is handled in the current docs.
I mean things like: you can input a float as any number of digits, and that has a precision that has a power of ten, but then, once it enters Pd, it will have a precision that is a power of two, and that's when it enters actual objects, but whenever the numbers are printed out, they will be printed with a power-of-ten precision, but will have been converted from a number that has a power-of-two precision, and it will pick the number of digits that it wants to, which is probably not the number of digits you entered in the first place, and which is less digits than what is available in the float values as they are used in pd objects, and this affects directly what happens when you save/load patches... e.g. you can't even write "1234567" as a regular number in a regular sentence in a pd comment and have it stay that way when you save and load.
But this particular topic doesn't necessarily affect anything in most help patches.
But if you look at the Max docs where they say, "the word 'set' followed by a number", there's not even that. Yet the wording is clear, succinct, and unambiguous.
Well, it's not technically unambiguous, but pretty much everybody will understand that this means «set 123» and not «set123» nor «set, 123», and that this could be «set $1» as long as $1 represents a number. Frankly, those "unlikely" mistakes are done a lot more by beginners than we know or like to admit, but at once, the wording can't be complicated so much, especially if it's going to be repeated over 1000 help files... though I guess it's not a bad idea to make a help patch that shows how to read a help patch, and have beginners read it early on. In short, the Max-style wording is probably fine.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Hi all,
I'm looking for a way to do this: Show text where the letters are positioned randomly across the screen. Then gradually move the letters towards their correct position, to show the original, readable text... any suggestions? Thanks!
Tim
Hallo, info@timvets.net hat gesagt: // info@timvets.net wrote:
I'm looking for a way to do this: Show text where the letters are positioned randomly across the screen. Then gradually move the letters towards their correct position, to show the original, readable text...
For showing letters you could use Gem.
Then use pmpd or msd to do the smooth movement with some physical feeling. Just add some fixed mass points to the line(s) of text you want to fill, and add mobile masses connected by links to their respective fixed/final positions. Turn off all links by setting the "k" rigidity parameter to 0, spread out the letters in random positions, then turn on the "k" again to let the masses start moving.
Ciao
Frank
hi tim,
additionally to what frank said you might want to use a font with
fixed width, otherwise you need to parse the kerning information
somehow. with a fixed width you can just count the letter position and
add the space to the x-position. use [text3d].
max
Am 14.08.2009 um 10:44 schrieb Frank Barknecht:
Hallo, info@timvets.net hat gesagt: // info@timvets.net wrote:
I'm looking for a way to do this: Show text where the letters are positioned randomly across the
screen. Then gradually move the letters towards their correct position, to
show the original, readable text...For showing letters you could use Gem.
Then use pmpd or msd to do the smooth movement with some physical
feeling. Just add some fixed mass points to the line(s) of text you want to fill,
and add mobile masses connected by links to their respective fixed/final
positions. Turn off all links by setting the "k" rigidity parameter to 0,
spread out the letters in random positions, then turn on the "k" again to let the
masses start moving.Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello,
Thanks for sharing your insights! The project turned out to be a little different from what I first thought though.
Now it's like this:
A text is shown, but only the word lengths are correct, most letters are randomly swapped with another letter in the text. The letters one by one flip back to their original position in the text.
so it would go from:
"taxbe ieis eal'est ih I gvin ae tyampse ki wuam it sfohld looa lofe" to "maybe it's easiest if I give an example of what it should look like"
...letter per letter, so in <n> steps where <n> is the number of non-space caracters in the text. In the starting situation, spaces stay in place, all other caracters are exchanged with other letters in the text randomly.
So I suppose it comes down to processing text in some way (list-abs, pyext, ...??) and sending the results to a text3d object. btw: Does text3d support a newline character ?
Thanks again, Tim
2009/8/14 Max abonnements@revolwear.com
hi tim,
additionally to what frank said you might want to use a font with fixed width, otherwise you need to parse the kerning information somehow. with a fixed width you can just count the letter position and add the space to the x-position. use [text3d].
max
Am 14.08.2009 um 10:44 schrieb Frank Barknecht:
Hallo,
info@timvets.net hat gesagt: // info@timvets.net wrote:
I'm looking for a way to do this:
Show text where the letters are positioned randomly across the screen. Then gradually move the letters towards their correct position, to show the original, readable text...
For showing letters you could use Gem.
Then use pmpd or msd to do the smooth movement with some physical feeling. Just add some fixed mass points to the line(s) of text you want to fill, and add mobile masses connected by links to their respective fixed/final positions. Turn off all links by setting the "k" rigidity parameter to 0, spread out the letters in random positions, then turn on the "k" again to let the masses start moving.
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
tim vets wrote:
btw: Does text3d support a newline character ?
You can send "string" messages of Unicode code points (or some other encoding, not entirely sure) to [text3d], which includes newlines.
"string 48 49 10 50 51"--[text3d]
Note that this is undocumented in the help patch in old versions of Gem. (and maybe in the current one too, I haven't checked the latest yet)
Claude
Claude Heiland-Allen a écrit :
tim vets wrote:
btw: Does text3d support a newline character ?
You can send "string" messages of Unicode code points (or some other encoding, not entirely sure) to [text3d], which includes newlines.
"string 48 49 10 50 51"--[text3d]
Note that this is undocumented in the help patch in old versions of Gem. (and maybe in the current one too, I haven't checked the latest yet)
it was not, i just add it. c
Claude
Le mardi 18 août 2009 à 20:36 +0100, Claude Heiland-Allen a écrit :
tim vets wrote:
btw: Does text3d support a newline character ?
You can send "string" messages of Unicode code points (or some other encoding, not entirely sure) to [text3d], which includes newlines.
"string 48 49 10 50 51"--[text3d]
Ya, very good ! So, something like this is useful :
[une 10 petite 10 espace( | [str to_list] | [list prepend string] | [list trim] | [text3d]
If i understand here, there is no symbol created ? If it is true, this is a good new, because this remove the problem of memory, when the symbol change everytime :
(a symbol created) | [text $1] | [text3d]
++
Jack
Note that this is undocumented in the help patch in old versions of Gem. (and maybe in the current one too, I haven't checked the latest yet)
Claude
info@timvets.net wrote:
Hi all,
I'm looking for a way to do this: Show text where the letters are positioned randomly across the screen. Then gradually move the letters towards their correct position, to show the original, readable text... any suggestions? Thanks!
Tim
IIR: next position := current position * 0.95 + 0.05 * target position (will never reach target exactly)
FIR: current position := start position * (1-t) + t * target position (with t in 0 .. 1)
You need one of the above for each coordinate of each letter, so I suggest storing the information in arrays (or data structures) and looping through them.
Claude
On Wed, 12 Aug 2009, Jonathan Wilkes wrote:
--- On Wed, 8/12/09, Mathieu Bouchard matju@artengine.ca
I'm not looking at a template, why?
Because I'm using the pddp template to revise the help
patches. I don't see a simple way to add column headings to the templates. Were you suggesting adding column headings, or something else?
Oh, column headings wouldn't have hurt, but I'm not gonna advocate it as long as PDDP doesn't have massive shortcuts for things like that... else it's a lot of wasted time.
Before I saw the PDDP template, I tried using an abstraction and entering all the inlet/outlet/argument info as args to the abstraction in order to separate the content from the formatting. It wasn't too bad because you can use semicolons in object boxes to get line breaks (and just filter them out later).
Since every help patch uses the same abstraction, you would just make formatting changes once. If there's an object that automatically lists the methods of an object, then all you would need for each help patch is to enter the name of an object (plus maybe some keywords) as arguments to the abstraction.
I don't think that it's a good idea to directly
connect "what you type" with "what you get", except in examples. The theory should connect "what you type" with an internal representation, and connect the internal representation with "what you get", or any other number of intermediate steps, whatever is needed to make people distinguish between "a symbol" and "the spelling out of a symbol by a user" and "the printing out of the symbol by pd" and other things. It's more obvious (and more critical) if you think of the float situation.
I don't think I understand your point. A float
is referred to as a "float" in the help patches. The patches don't refer to a "float message," or "float selector." So I don't see a problem with how float is handled in the current docs.
I mean things like: you can input a float as any number of digits, and that has a precision that has a power of ten, but then, once it enters Pd, it will have a precision that is a power of two, and that's when it enters actual objects, but whenever the numbers are printed out, they will be printed with a power-of-ten precision, but will have been converted from a number that has a power-of-two precision, and it will pick the number of digits that it wants to, which is probably not the number of digits you entered in the first place, and which is less digits than what is available in the float values as they are used in pd objects, and this affects directly what happens when you save/load patches... e.g. you can't even write "1234567" as a regular number in a regular sentence in a pd comment and have it stay that way when you save and load.
But this particular topic doesn't necessarily affect anything in most help patches.
But if you look at the Max docs where they say, "the
word 'set' followed by a number", there's not even that. Yet the wording is clear, succinct, and unambiguous.
Well, it's not technically unambiguous, but pretty much everybody will understand that this means «set 123» and not «set123» nor «set, 123», and that this could be «set $1» as long as $1 represents a number. Frankly, those "unlikely" mistakes are done a lot more by beginners than we know or like to admit, but at once, the wording can't be complicated so much, especially if it's going to be repeated over 1000 help files... though I guess it's not a bad idea to make a help patch that shows how to read a help patch, and have beginners read it early on. In short, the Max-style wording is probably fine.
I have a help-on-help abstraction (it's just called help) in each help patch, and I thought it would be cool to sprinkle little graphical ds arrows in it to point out the various parts of the help patch. They turned into little sprinkles of pepper when I tried to save and reopen the patch, but now I'm thinking maybe I can just make 1000s of broken ds-instances and cluster them all together to form the shape of arrows.
-Jonathan
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
"message" also "requires" a definition as much as anything else, >
There is an introduction (not a real "definition") to Pd's messages here: http://puredata.info/dev/PdMessages/
It uses the term "selector" all over, as I, too, think, it's key to understanding messages in Pd.
Ciao
Frank
On Aug 13, 2009, at 7:47 AM, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
"message" also "requires" a definition as much as anything else, >
There is an introduction (not a real "definition") to Pd's messages
here: http://puredata.info/dev/PdMessages/It uses the term "selector" all over, as I, too, think, it's key to understanding messages in Pd.
Just to be clear, that page is Frank's take on redefining the
PdDefinitions page. I don't think we ever came up with a final,
agreed upon set of definitions, that's why I bring it up. I think
mostly there is agreement on the definitions, but there are some key
differences. You can see my attempt here (both on the bottom of the
PdDefinitions page).
http://puredata.info/dev/HansDataTypeDefinitions
On that note, it would be good to see other people digesting this info
and posted on that page.
.hc
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism. - retired U.S. Army general, William Odom
On Aug 10, 2009, at 12:05 AM, Mathieu Bouchard wrote:
On Sun, 9 Aug 2009, Jonathan Wilkes wrote:
--- On Sun, 8/9/09, Hans-Christoph Steiner hans@at.or.at wrote:
Check the Pd Definitions wiki on http://puredata.info/dev for some
discussion on this stuff. And please add anything there that you think should be there.On the Pd Definitions wiki, they are referred to as elements, and
I've already changed the reference patches to reflect this.I wouldn't quite advocate using the PdDefinitions as they are now.
Much of the way people talk about pd is ambiguous, and that includes
Miller too. The Pd Manual itself has a fair amount of vague talk,
but then, the PdDefinitions page handpicks quotes in it without
regard to whether "the definition of float" is about float-values,
float-atoms, floatatom-objects, the floatatom class, the strings
recognised as floats, or the strings that floats are outputted as;
and likewise for several other definitions lifted from the manual.
The idea of that section of the PdDefintions wiki is to collect all
bits of text that contribute to the definition of what is a symbol/
float/atom/etc. That's why there are many bits. If there is anything
missing please add it.
"atoms are either numbers or symbols" -> that's only when you look
at what you can write in a messagebox that can end up as-is in a
message. This ignore comma atoms, semicolon atoms, dollar atoms
($1), dollsym atoms ($1-blah), and pointer atoms (which can't be
produced by the parser).
Well, this defintion comes from the "object boxes" section, not
message boxes or messages. There is no discussion of messages in the
section where that is defined. But that's a minor detail.
http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s1.2
.hc
"There are two atom boxes, floatatom and symbolatom" -> this is
irrelevant to the definition of an atom, of a float, or of a symbol,
in that you could make patches without ever using any atomboxes and
you could still see all the characteristics of float values and
symbol values shine through.
"Anything that is not a valid number is considered a symbol." ->
this is only in the context of parsing, and only once the commas and
semicolons are dealt with."The selector is a symbol, which appears in the patch as a non- numeric string with no white space, semicolons, or commas." -> the
manual doesn't take into account any weird thing you can do in Pd,
even with pure pd, and even without hand-editing any .pd files. E.g.
this patch:#N canvas 0 0 450 300 10; #X obj 12 31 makefilename %d; #X msg 12 13 123; #X msg 12 67; #X msg 12 49 set $1 , bang; #X obj 12 85 f; #X connect 0 0 3 0; #X connect 1 0 0 0; #X connect 2 0 4 0; #X connect 3 0 2 0;
ends up saying:
no method for '123'
but "no method for" errors always state the selector, and here, 123
is a selector, which is a symbol, but is printed in a way that makes
it look like a float.Because of the way they are laid out, I don't think there is any
ambiguity between first element and selector in the help patches (I
don't think "selector" is used in any of them, but I'll check and
make sure).Selector ought to be used to talk about all those so-called "meta- messages", not only because the Pd Manual does, but also because the
manuals of several other programming languages call that same thing
by the same name. It's not like selectors are a weird thing from
outerspace that got stuck into Pd for no reason (even though some
facts about Pd's selectors are a bit weird)._ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Information wants to be free. -Stewart Brand
Hans-Christoph Steiner wrote:
On Aug 10, 2009, at 12:05 AM, Mathieu Bouchard wrote:
I wouldn't quite advocate using the PdDefinitions as they are now.
The idea of that section of the PdDefintions wiki is to collect all bits of text that contribute to the definition of what is a symbol/float/atom/etc. That's why there are many bits. If there is anything missing please add it.
while the PdDefinitions wiki is definitely a good start, in it's current state it probably adds more shadow than light here (mainly because of quotes without context) i guess matju was referring to that. (this doesn't mean that one shouldn't go and add/fix/improve it)
Well, this defintion comes from the "object boxes" section, not message boxes or messages. There is no discussion of messages in the section where that is defined. But that's a minor detail.
yes, that's the problem with the missing context.
an atom is agnostic of whether it appears in a message or an object.
saying that an atom either a number or a symbol is just wrong (even if miller himself seems to indicate this in http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s3.1 )
fmgasdr IOhannes´
On Tue, 11 Aug 2009, Hans-Christoph Steiner wrote:
The idea of that section of the PdDefintions wiki is to collect all bits of text that contribute to the definition of what is a symbol/float/atom/etc. That's why there are many bits. If there is anything missing please add it.
In the Humanities, you can define abstract words the postmodern way, collecting little bits and talking about a word until it acquires a meaning. In a computer programme, it doesn't matter what the word means to the users or even whether the users think of the thing as being abstract: symbols and floats are very concrete things that have very precise definitions that don't leave a lot of room for interpretational variation.
So I think we can leave the mosaïc of testimonies aside and just read the source, so that we get back to what Pd is instead of what we think it is.
Well, this defintion comes from the "object boxes" section, not message boxes or messages. There is no discussion of messages in the section where that is defined. But that's a minor detail. http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s1.2
Ah, well, when I read that, it never crossed my mind that I had to look up the bibliographical reference to actually understand what's written there. That's what I mean by "out of context"... the PdDefinition page is unusually dependent on its bibliographical references... doesn't stand on its own.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Aug 12, 2009, at 4:07 PM, Mathieu Bouchard wrote:
On Tue, 11 Aug 2009, Hans-Christoph Steiner wrote:
The idea of that section of the PdDefintions wiki is to collect all
bits of text that contribute to the definition of what is a symbol/ float/atom/etc. That's why there are many bits. If there is
anything missing please add it.In the Humanities, you can define abstract words the postmodern way,
collecting little bits and talking about a word until it acquires a
meaning. In a computer programme, it doesn't matter what the word
means to the users or even whether the users think of the thing as
being abstract: symbols and floats are very concrete things that
have very precise definitions that don't leave a lot of room for
interpretational variation.So I think we can leave the mosaïc of testimonies aside and just
read the source, so that we get back to what Pd is instead of what
we think it is.
Well, this defintion comes from the "object boxes" section, not
message boxes or messages. There is no discussion of messages in
the section where that is defined. But that's a minor detail. http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s1.2Ah, well, when I read that, it never crossed my mind that I had to
look up the bibliographical reference to actually understand what's
written there. That's what I mean by "out of context"... the
PdDefinition page is unusually dependent on its bibliographical
references... doesn't stand on its own.
Just to clarify, you guys seem to be missing the point of that page.
The point was to gather all definitions in Miller's manual and in Pd
itself. Then, that's a basis to then come up with clearer definitions
and clearer implementations.
There does not seem to be one canonical source of definitions, the
source is also inconsistent in some places. The fact that these
definitions vary highlights that problem. If you think you can
improve on Frank and my attempts at clarifying things, please add a
wiki page and put your own definitions there. Also, if you find any
other relevant definitions, please add it to the main page.
http://puredata.info/dev/PdDefinitions
.hc
.hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
That's a good point and a tough question. It should be consistently documented, but its not totally clear how. My guess right now would be to use 'element'.
Check the Pd Definitions wiki on http://puredata.info/dev for some discussion on this stuff. And please add anything there that you think should be there.
.hc
Jonathan Wilkes wrote:
[list one two three(
How should the help patches refer to "one" above: as the first element or the first item in the list? Currently the reference docs use both, and I'd like to pick one and stick to it.
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Claude Heiland-Allen -
cyrille henry -
Frank Barknecht -
Gabriel Vinazza -
Hans-Christoph Steiner -
info＠timvets.net -
IOhannes m zmoelnig -
Jack -
Jonathan Wilkes -
Mathieu Bouchard -
Max -
Simon Wise -
tim vets