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