Hello,
Before you go any further in Pd, you should check out the [trigger] object. It's the single most important object in Pd, in my opinion - it will help you get the timing right in these kinds of situations. Trigger forces hot-cold things to happen in the correct order explicitly -- without it you have to rely on the order in which you made the connections, which you can't SEE in the patch.
You should use [trigger] instead of the [pipe 0] construction you have as well, the number box should most likely be a message with a zero in it (to hardwire it to zero), and you should probably be sending it to the cold inlet of the [int] (so that it just sets the [int] state rather than passing the zero through once when you set it and then once again on the first bang of the [until]).
But again, master the use of [trigger] before you go any further -- multiple lines coming from an object should make you feel uncomfortable until you're sure you're doing it correctly.
I hope this helps.
MB
I've looked over the help patches, the FLOSS manual, and at a number of examples, but I'm clearly missing something.
I'm trying to build a proof-of-concept state table for a grid sequencer. I figured out to use an array to store my states, and I can write to and read from the table, except when I'm trying to use pack.
The reason for pack is to get the column, row, and state of each button in a range of the state table (will be a single column in my end use, but I'm doing the whole thing for now).
Attached is a patch with a 2x2 grid set up and you can click on them and set the state table. That works. It's the lookup part that doesn't. I'm stepping through the entire state table, deriving the column and row from the index and looking up the value of that index. This all works until I send those three pieces of information to a pack object, it re-arranges things in inconsistent manner. Clearly there's either a timing thing or I'm not understanding the data flow of what I'm doing. Or maybe I'm just not getting the point of pack.
I'm pretty new to this and every step is a struggle, so any suggestions are welcome. But if there are any tips or pointers on why pack is not working the way I think it should - or what I should be using to accomplish what I'm trying to do - I would appreciate it.
Long-winded description of how the attached patch is behaving:
Buttons are arranged in column, row order. I'm just storing 0/1 values in the state_table array. If I click on the first and last buttons, my array is then 1 0 0 1. So state_table[i] gets me the off/on value for the button. i div 2 gets me the column number and i mod 2 gets me the row number.
If I just print these three outputs I get everything out in the order I expect:
column: 0 row: 0 state: 1 column: 0 row: 1 state: 0 column: 1 row: 0 state: 0 column: 1 row: 1 state: 1
If I send the three values into a pack object and print the output of that, I get:
pack: 0 1 0 pack: 0 0 1 pack: 1 1 0 pack: 1 0 0
I would expect this:
pack: 0 0 1 pack: 0 1 0 pack: 1 0 0 pack: 1 1 1
So things are coming in the wrong order overall, and the state values are wrong.
Thanks,
-Theron
Thanks! I used [pipe] because I had an obvious timing problem and that was an explicit delay object. Didn't occur to me that [trigger] could control the timing as well. It's use wasn't obvious to me from what I had read about it.
I will make the adjustments you suggest and see where I get. I expect I will have more questions.
Thanks again,
-Theron ^
On Fri, Feb 4, 2011 at 5:17 AM, Matt Barber brbrofsvl@gmail.com wrote:
Hello,
Before you go any further in Pd, you should check out the [trigger] object. It's the single most important object in Pd, in my opinion - it will help you get the timing right in these kinds of situations. Trigger forces hot-cold things to happen in the correct order explicitly -- without it you have to rely on the order in which you made the connections, which you can't SEE in the patch.
You should use [trigger] instead of the [pipe 0] construction you have as well, the number box should most likely be a message with a zero in it (to hardwire it to zero), and you should probably be sending it to the cold inlet of the [int] (so that it just sets the [int] state rather than passing the zero through once when you set it and then once again on the first bang of the [until]).
But again, master the use of [trigger] before you go any further -- multiple lines coming from an object should make you feel uncomfortable until you're sure you're doing it correctly.
I hope this helps.
MB
I've looked over the help patches, the FLOSS manual, and at a number of examples, but I'm clearly missing something.
I'm trying to build a proof-of-concept state table for a grid sequencer.
I
figured out to use an array to store my states, and I can write to and
read
from the table, except when I'm trying to use pack.
The reason for pack is to get the column, row, and state of each button
in a
range of the state table (will be a single column in my end use, but I'm doing the whole thing for now).
Attached is a patch with a 2x2 grid set up and you can click on them and
set
the state table. That works. It's the lookup part that doesn't. I'm stepping through the entire state table, deriving the column and row from the index and looking up the value of that index. This all works until I send those three pieces of information to a pack object, it re-arranges things in inconsistent manner. Clearly there's either a timing thing or
I'm
not understanding the data flow of what I'm doing. Or maybe I'm just not getting the point of pack.
I'm pretty new to this and every step is a struggle, so any suggestions
are
welcome. But if there are any tips or pointers on why pack is not
working
the way I think it should - or what I should be using to accomplish what
I'm
trying to do - I would appreciate it.
Long-winded description of how the attached patch is behaving:
Buttons are arranged in column, row order. I'm just storing 0/1 values
in
the state_table array. If I click on the first and last buttons, my
array
is then 1 0 0 1. So state_table[i] gets me the off/on value for the
button.
i div 2 gets me the column number and i mod 2 gets me the row number.
If I just print these three outputs I get everything out in the order I expect:
column: 0 row: 0 state: 1 column: 0 row: 1 state: 0 column: 1 row: 0 state: 0 column: 1 row: 1 state: 1
If I send the three values into a pack object and print the output of
that,
I get:
pack: 0 1 0 pack: 0 0 1 pack: 1 1 0 pack: 1 0 0
I would expect this:
pack: 0 0 1 pack: 0 1 0 pack: 1 0 0 pack: 1 1 1
So things are coming in the wrong order overall, and the state values are wrong.
Thanks,
-Theron
That worked very nicely. I had to change the until input to 4 to get it to do the right number of iterations, since the input didn't also kick off the loop, but that's fine.
I'm not sure I understand exactly what was going on before, but I now have a [trigger] object that does the [tabread] first, and then the mod/div math. So I understand why it works now. Just not exactly why it didn't before :)
Now... I have another [pipe 0] object in the button_handler sub-patch which delays a message while a [expr] object does its thing. Replacing it with a [trigger] doesn't work. But it's not coordinated with the other outputs of the [unpack] object.
Is there an object like [trigger] that has multiple inputs and lets you control the timing of the outputs? [pipe] can take multiple inputs but doesn't have the same right-to-left coordinated output that [trigger] does.
The FLOSS manual says that the order you hook things up in part determines the order they do things. But I can't make that make a difference.
Thanks,
-Theron ^
On Fri, Feb 4, 2011 at 12:50 PM, Theron Trowbridge < theron.trowbridge@gmail.com> wrote:
Thanks! I used [pipe] because I had an obvious timing problem and that was an explicit delay object. Didn't occur to me that [trigger] could control the timing as well. It's use wasn't obvious to me from what I had read about it.
I will make the adjustments you suggest and see where I get. I expect I will have more questions.
Thanks again,
-Theron ^
On Fri, Feb 4, 2011 at 5:17 AM, Matt Barber brbrofsvl@gmail.com wrote:
Hello,
Before you go any further in Pd, you should check out the [trigger] object. It's the single most important object in Pd, in my opinion - it will help you get the timing right in these kinds of situations. Trigger forces hot-cold things to happen in the correct order explicitly -- without it you have to rely on the order in which you made the connections, which you can't SEE in the patch.
You should use [trigger] instead of the [pipe 0] construction you have as well, the number box should most likely be a message with a zero in it (to hardwire it to zero), and you should probably be sending it to the cold inlet of the [int] (so that it just sets the [int] state rather than passing the zero through once when you set it and then once again on the first bang of the [until]).
But again, master the use of [trigger] before you go any further -- multiple lines coming from an object should make you feel uncomfortable until you're sure you're doing it correctly.
I hope this helps.
MB
I've looked over the help patches, the FLOSS manual, and at a number of examples, but I'm clearly missing something.
I'm trying to build a proof-of-concept state table for a grid sequencer.
I
figured out to use an array to store my states, and I can write to and
read
from the table, except when I'm trying to use pack.
The reason for pack is to get the column, row, and state of each button
in a
range of the state table (will be a single column in my end use, but I'm doing the whole thing for now).
Attached is a patch with a 2x2 grid set up and you can click on them and
set
the state table. That works. It's the lookup part that doesn't. I'm stepping through the entire state table, deriving the column and row
from
the index and looking up the value of that index. This all works until
I
send those three pieces of information to a pack object, it re-arranges things in inconsistent manner. Clearly there's either a timing thing or
I'm
not understanding the data flow of what I'm doing. Or maybe I'm just
not
getting the point of pack.
I'm pretty new to this and every step is a struggle, so any suggestions
are
welcome. But if there are any tips or pointers on why pack is not
working
the way I think it should - or what I should be using to accomplish what
I'm
trying to do - I would appreciate it.
Long-winded description of how the attached patch is behaving:
Buttons are arranged in column, row order. I'm just storing 0/1 values
in
the state_table array. If I click on the first and last buttons, my
array
is then 1 0 0 1. So state_table[i] gets me the off/on value for the
button.
i div 2 gets me the column number and i mod 2 gets me the row number.
If I just print these three outputs I get everything out in the order I expect:
column: 0 row: 0 state: 1 column: 0 row: 1 state: 0 column: 1 row: 0 state: 0 column: 1 row: 1 state: 1
If I send the three values into a pack object and print the output of
that,
I get:
pack: 0 1 0 pack: 0 0 1 pack: 1 1 0 pack: 1 0 0
I would expect this:
pack: 0 0 1 pack: 0 1 0 pack: 1 0 0 pack: 1 1 1
So things are coming in the wrong order overall, and the state values
are
wrong.
Thanks,
-Theron
Check below:
On Tue, Feb 8, 2011 at 10:55 PM, Theron Trowbridge theron.trowbridge@gmail.com wrote:
That worked very nicely. I had to change the until input to 4 to get it to do the right number of iterations, since the input didn't also kick off the loop, but that's fine.
Good -- this looks stylistically correct to me.
I'm not sure I understand exactly what was going on before, but I now have a [trigger] object that does the [tabread] first, and then the mod/div math. So I understand why it works now. Just not exactly why it didn't before :)
If I remember correctly, it didn't work before because you had connected the output of one object to several inputs in the wrong order. The problem is there's no way to see if it's in the wrong order just by looking at it -- hence the need for [trigger]. So it wasn't a mistake of ordering the connections properly on your part, it was a mistake in not ordering them explicitly with trigger.
Now... I have another [pipe 0] object in the button_handler sub-patch which delays a message while a [expr] object does its thing. Replacing it with a [trigger] doesn't work. But it's not coordinated with the other outputs of the [unpack] object.
Right -- in this case what you need is to have the incoming list in the correct order. See the attached (also, for something this simple there's probably no reason to use [expr]. In the attached patch I just rotated the order of the incoming list -- but probably you would want to make the lists attached to the toggles in the main patch have the order you want -- the last thing you want to unpack should be the first thing in the list (which may seem like confusing syntax when you're building the lists, but it will get more intuitive once you work with order of operation in Pd for a while).
Good Luck,
MB
Is there an object like [trigger] that has multiple inputs and lets you control the timing of the outputs? [pipe] can take multiple inputs but doesn't have the same right-to-left coordinated output that [trigger] does. The FLOSS manual says that the order you hook things up in part determines the order they do things. But I can't make that make a difference.
Thanks, -Theron ^
On Fri, Feb 4, 2011 at 12:50 PM, Theron Trowbridge theron.trowbridge@gmail.com wrote:
Thanks! I used [pipe] because I had an obvious timing problem and that was an explicit delay object. Didn't occur to me that [trigger] could control the timing as well. It's use wasn't obvious to me from what I had read about it. I will make the adjustments you suggest and see where I get. I expect I will have more questions.
Thanks again, -Theron ^
On Fri, Feb 4, 2011 at 5:17 AM, Matt Barber brbrofsvl@gmail.com wrote:
Hello,
Before you go any further in Pd, you should check out the [trigger] object. It's the single most important object in Pd, in my opinion - it will help you get the timing right in these kinds of situations. Trigger forces hot-cold things to happen in the correct order explicitly -- without it you have to rely on the order in which you made the connections, which you can't SEE in the patch.
You should use [trigger] instead of the [pipe 0] construction you have as well, the number box should most likely be a message with a zero in it (to hardwire it to zero), and you should probably be sending it to the cold inlet of the [int] (so that it just sets the [int] state rather than passing the zero through once when you set it and then once again on the first bang of the [until]).
But again, master the use of [trigger] before you go any further -- multiple lines coming from an object should make you feel uncomfortable until you're sure you're doing it correctly.
I hope this helps.
MB
I've looked over the help patches, the FLOSS manual, and at a number of examples, but I'm clearly missing something.
I'm trying to build a proof-of-concept state table for a grid sequencer. I figured out to use an array to store my states, and I can write to and read from the table, except when I'm trying to use pack.
The reason for pack is to get the column, row, and state of each button in a range of the state table (will be a single column in my end use, but I'm doing the whole thing for now).
Attached is a patch with a 2x2 grid set up and you can click on them and set the state table. That works. It's the lookup part that doesn't. I'm stepping through the entire state table, deriving the column and row from the index and looking up the value of that index. This all works until I send those three pieces of information to a pack object, it re-arranges things in inconsistent manner. Clearly there's either a timing thing or I'm not understanding the data flow of what I'm doing. Or maybe I'm just not getting the point of pack.
I'm pretty new to this and every step is a struggle, so any suggestions are welcome. But if there are any tips or pointers on why pack is not working the way I think it should - or what I should be using to accomplish what I'm trying to do - I would appreciate it.
Long-winded description of how the attached patch is behaving:
Buttons are arranged in column, row order. I'm just storing 0/1 values in the state_table array. If I click on the first and last buttons, my array is then 1 0 0 1. So state_table[i] gets me the off/on value for the button. i div 2 gets me the column number and i mod 2 gets me the row number.
If I just print these three outputs I get everything out in the order I expect:
column: 0 row: 0 state: 1 column: 0 row: 1 state: 0 column: 1 row: 0 state: 0 column: 1 row: 1 state: 1
If I send the three values into a pack object and print the output of that, I get:
pack: 0 1 0 pack: 0 0 1 pack: 1 1 0 pack: 1 0 0
I would expect this:
pack: 0 0 1 pack: 0 1 0 pack: 1 0 0 pack: 1 1 1
So things are coming in the wrong order overall, and the state values are wrong.
Thanks,
-Theron
Hi,
On Tue, Feb 08, 2011 at 07:55:20PM -0800, Theron Trowbridge wrote:
That worked very nicely. I had to change the until input to 4 to get it to do the right number of iterations, since the input didn't also kick off the loop, but that's fine.
Btw: IMO it really helps to lay out your patches in a left-aligned matter, so everything, that happens last, also is on the left side. It's just cosmetics, but makes patches easier to read. For example, I would move the [0] object with "initialize [int] to 0 -->" to the right of the [4( message.
Try to read patched objects right-to-left and top-to-bottom.
Now... I have another [pipe 0] object in the button_handler sub-patch which delays a message while a [expr] object does its thing. Replacing it with a [trigger] doesn't work. But it's not coordinated with the other outputs of the [unpack] object.
You don't need the [pipe], if you connect objects correctly. In fact, [pipe] makes it harder to get things right here, because it breaks the usual "depth-first execution order", which you don't need to break here.
Again, left-alignement helps thinking about and reading patches. See the subpatch for a solution without pipe - and without triggers as well. [trigger] is important, but only when objects don't have enough outlets themselves. [unpack 0 0 0] already has three outlets that, just like [t f f f] fire from left to right, so triggering explicitly is not needed.
What is needed however are correct connections.
Is there an object like [trigger] that has multiple inputs and lets you control the timing of the outputs? [pipe] can take multiple inputs but doesn't have the same right-to-left coordinated output that [trigger] does.
Oh, [pipe] does have the same coordinated output like trigger, it also fires right-to-left! But you need to make a [pipe 0 0 0 0 0] with more than one outlet to see that.
The FLOSS manual says that the order you hook things up in part determines the order they do things. But I can't make that make a difference.
Just forget completely about this. The order you create connections matters in reality, but never, ever rely on it when patching. Treat every patch as if someone else created it and as if you'd have no idea, what order he made the connections.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Perhaps the wording of that section should more clearly state that creation order cannot be relied on, rather than inferring that one can use it as a proper way of patching. I would be very happy if someone wanted to have a look at that chapter and clarify things.
Best! Derek
On 2/9/11 8:52 AM, Frank Barknecht wrote:
The FLOSS manual says that the order you hook things up in part determines the order they do things. But I can't make that make a difference.
Just forget completely about this. The order you create connections matters in reality, but never, ever rely on it when patching. Treat every patch as if someone else created it and as if you'd have no idea, what order he made the connections.
On Wed, Feb 09, 2011 at 08:52:50AM +0100, Frank Barknecht wrote:
Again, left-alignement helps thinking about and reading patches. See the subpatch for a solution without pipe - and without triggers as well. [trigger] is important, but only when objects don't have enough outlets themselves. [unpack 0 0 0] already has three outlets that, just like [t f f f] fire from left to right, so triggering explicitly is not needed.
Oops. Please invert: "just like [t f f f] fires from right to left".
71 of 364 (19.5%) college professors and 311 of 1185 (26.2%) college students said that they occasionally, frequently or all of the time had difficulty when they had to quickly identify right from left. References:
1. Brandt, J. and Mackavey, W. Left-right confusion and the perception of
bilateral symmetry. International Journal of Neuroscience, 12:87-94, 1981.
2. Hannay, H.J., Ciaccia, P.J., Kerr, J.W. and Barrett, D. Self-report of
right-left confusion in college men and women. Perceptual and Motor Skills,
70:451-457, 1990.
3. Harris, L.J., Gitterman, S.R. University professors' self-descriptions
of left-right confusability: sex and handedness differences. Perceptual and
Motor Skills, 47:819-823, 1978.
http://faculty.washington.edu/chudler/java/hands1.html
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Thanks, everyone! The re-ordering of elements in the message so that they go in the desired order makes total sense. So does the the [ * 2 ] and [ + ] objects.
Works nicely and is much cleaner than what I had before. (Attached, but it looks basically like all the suggestions.)
Next question - is a table the best way to be storing the state table? This is for a 16x16 Monome, so I need 256 values, and I need to be able to access specific chunks at a time (column by column). Would [coll] make more sense? It seems to have good management tools with nth, nsub, etc.
-Theron ^
On Wed, Feb 9, 2011 at 1:16 AM, Frank Barknecht fbar@footils.org wrote:
On Wed, Feb 09, 2011 at 08:52:50AM +0100, Frank Barknecht wrote:
Again, left-alignement helps thinking about and reading patches. See the subpatch for a solution without pipe - and without triggers as well.
[trigger]
is important, but only when objects don't have enough outlets themselves. [unpack 0 0 0] already has three outlets that, just like [t f f f] fire
from
left to right, so triggering explicitly is not needed.
Oops. Please invert: "just like [t f f f] fires from right to left".
71 of 364 (19.5%) college professors and 311 of 1185 (26.2%) college students said that they occasionally, frequently or all of the time had difficulty when they had to quickly identify right from left. References:
- Brandt, J. and Mackavey, W. Left-right confusion and the perception
of bilateral symmetry. International Journal of Neuroscience, 12:87-94, 1981.
- Hannay, H.J., Ciaccia, P.J., Kerr, J.W. and Barrett, D. Self-report
of right-left confusion in college men and women. Perceptual and Motor Skills, 70:451-457, 1990.
- Harris, L.J., Gitterman, S.R. University professors'
self-descriptions of left-right confusability: sex and handedness differences. Perceptual and Motor Skills, 47:819-823, 1978.
http://faculty.washington.edu/chudler/java/hands1.html
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Happens to me all the time -- I have to point when I'm a passenger giving directions to a driver -- I usually say the wrong one first.
I thought it was because I'm left-handed (or slightly brain-damaged).
Phil
On 2/9/11 1:16 AM, Frank Barknecht wrote:
On Wed, Feb 09, 2011 at 08:52:50AM +0100, Frank Barknecht wrote:
Again, left-alignement helps thinking about and reading patches. See the subpatch for a solution without pipe - and without triggers as well. [trigger] is important, but only when objects don't have enough outlets themselves. [unpack 0 0 0] already has three outlets that, just like [t f f f] fire from left to right, so triggering explicitly is not needed.
Oops. Please invert: "just like [t f f f] fires from right to left".
71 of 364 (19.5%) college professors and 311 of 1185 (26.2%) college students said that they occasionally, frequently or all of the time had difficulty when they had to quickly identify right from left. References:
1. Brandt, J. and Mackavey, W. Left-right confusion and the perception of bilateral symmetry. International Journal of Neuroscience, 12:87-94, 1981. 2. Hannay, H.J., Ciaccia, P.J., Kerr, J.W. and Barrett, D. Self-report of right-left confusion in college men and women. Perceptual and Motor Skills, 70:451-457, 1990. 3. Harris, L.J., Gitterman, S.R. University professors' self-descriptions of left-right confusability: sex and handedness differences. Perceptual and Motor Skills, 47:819-823, 1978.http://faculty.washington.edu/chudler/java/hands1.html
Ciao
I had a friend who time to time had to call people on the phone and have them explain where is right and where is left, and then she soon forgot it again. It's not a brain damage, but a neurological thing. I suggest that [trigger] help feature an image of an arrow (<---) to reinforce the idea of "right to left".
Andras
On Wed, Feb 9, 2011 at 5:46 PM, Phil Stone pkstone@ucdavis.edu wrote:
Happens to me all the time -- I have to point when I'm a passenger giving directions to a driver -- I usually say the wrong one first.
I thought it was because I'm left-handed (or slightly brain-damaged).
Phil
On 2/9/11 1:16 AM, Frank Barknecht wrote:
On Wed, Feb 09, 2011 at 08:52:50AM +0100, Frank Barknecht wrote:
Again, left-alignement helps thinking about and reading patches. See the subpatch for a solution without pipe - and without triggers as well. [trigger] is important, but only when objects don't have enough outlets themselves. [unpack 0 0 0] already has three outlets that, just like [t f f f] fire from left to right, so triggering explicitly is not needed.
Oops. Please invert: "just like [t f f f] fires from right to left".
71 of 364 (19.5%) college professors and 311 of 1185 (26.2%) college students said that they occasionally, frequently or all of the time had difficulty when they had to quickly identify right from left. References:
1. Brandt, J. and Mackavey, W. Left-right confusion and the perceptionof bilateral symmetry. International Journal of Neuroscience, 12:87-94, 1981.
2. Hannay, H.J., Ciaccia, P.J., Kerr, J.W. and Barrett, D. Self-reportof right-left confusion in college men and women. Perceptual and Motor Skills, 70:451-457, 1990.
3. Harris, L.J., Gitterman, S.R. University professors'self-descriptions of left-right confusability: sex and handedness differences. Perceptual and Motor Skills, 47:819-823, 1978.
http://faculty.washington.edu/chudler/java/hands1.html
Ciao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 9 Feb 2011, András Murányi wrote:
It's not a brain damage, but a neurological thing.
But brain damage *is* a neurological thing :}
But the phenomenon of confusing left and right is so common, that in Québec, we routinely call «gauche» «l'autre droite» ("left" is also known as "the other right"), and call «droite» «l'autre gauche» ("right" is also known as "the other left"), whenever someone picks the wrong direction after being given an instruction.
(I don't know about the existence of such an expression anywhere else)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Here in belgium, in dutch, we also say other right/left, but since french is one of our languages, that could be the origin, on the other hand I dont really believe its language related: from inside a head your left eye is not the same as from outside the head (like face culling in OpenGL,...). Instead I would think its just a softening for pointing out a mistake through use of humor.
2011/2/9 Mathieu Bouchard matju@artengine.ca:
On Wed, 9 Feb 2011, András Murányi wrote:
It's not a brain damage, but a neurological thing.
But brain damage *is* a neurological thing :}
But the phenomenon of confusing left and right is so common, that in Québec, we routinely call «gauche» «l'autre droite» ("left" is also known as "the other right"), and call «droite» «l'autre gauche» ("right" is also known as "the other left"), whenever someone picks the wrong direction after being given an instruction.
(I don't know about the existence of such an expression anywhere else)
_______________________________________________________________________ | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 10 Feb 2011, Ludwig Maes wrote:
Here in belgium, in dutch, we also say other right/left, but since french is one of our languages, that could be the origin, on the other hand I dont really believe its language related:
I talked about my language because I can't speak about the others.
And the others include the English language, which I rarely use outside of computer stuff.
from inside a head your left eye is not the same as from outside the head (like face culling in OpenGL,...).
Or more commonly, people expect to see their own face mirrored as in a mirror, and other peoples' faces as non-mirrored, and this is how webcam streams have to be displayed on-screen (one straight, one mirrored).
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
yeah, I always thought that trigger should show the flow with a little
line drawing.
.hc
On Feb 9, 2011, at 12:03 PM, András Murányi wrote:
I had a friend who time to time had to call people on the phone and
have them explain where is right and where is left, and then she
soon forgot it again. It's not a brain damage, but a neurological
thing. I suggest that [trigger] help feature an image of an arrow (<---) to
reinforce the idea of "right to left".Andras
On Wed, Feb 9, 2011 at 5:46 PM, Phil Stone pkstone@ucdavis.edu
wrote: Happens to me all the time -- I have to point when I'm a passenger
giving directions to a driver -- I usually say the wrong one first.I thought it was because I'm left-handed (or slightly brain-damaged).
Phil
On 2/9/11 1:16 AM, Frank Barknecht wrote: On Wed, Feb 09, 2011 at 08:52:50AM +0100, Frank Barknecht wrote: Again, left-alignement helps thinking about and reading patches. See
the subpatch for a solution without pipe - and without triggers as well.
[trigger] is important, but only when objects don't have enough outlets
themselves. [unpack 0 0 0] already has three outlets that, just like [t f f f]
fire from left to right, so triggering explicitly is not needed. Oops. Please invert: "just like [t f f f] fires from right to left".71 of 364 (19.5%) college professors and 311 of 1185 (26.2%) college
students said that they occasionally, frequently or all of the time had
difficulty when they had to quickly identify right from left. References:1. Brandt, J. and Mackavey, W. Left-right confusion and theperception of bilateral symmetry. International Journal of Neuroscience,
12:87-94, 1981.2. Hannay, H.J., Ciaccia, P.J., Kerr, J.W. and Barrett, D. Self-report of right-left confusion in college men and women. Perceptual and
Motor Skills, 70:451-457, 1990.3. Harris, L.J., Gitterman, S.R. University professors' self-descriptions of left-right confusability: sex and handedness differences.
Perceptual and Motor Skills, 47:819-823, 1978.http://faculty.washington.edu/chudler/java/hands1.html
Ciao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Muranyi Andras _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I hate it when they say, "He gave his life for his country." Nobody
gives their life for anything. We steal the lives of these kids. -
Admiral Gene LeRocque
Hi,
On Wed, Feb 09, 2011 at 09:40:35PM -0500, Hans-Christoph Steiner wrote:
yeah, I always thought that trigger should show the flow with a little
line drawing.
As practically every object in Pd goes right to left, we'd need a lot of arrows. :)
Btw. because of that I think, it's good practice to make sure, your abstractions also fire right to left.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
-
András Murányi -
Derek Holzer -
Frank Barknecht -
Hans-Christoph Steiner -
Ludwig Maes -
Mathieu Bouchard -
Matt Barber -
Phil Stone -
Theron Trowbridge