[PD] Need Help Understanding pack

[Matt Barber]

Check below:

On Tue, Feb 8, 2011 at 10:55 PM, Theron Trowbridge
<theron.trowbridge at 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 at 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 at 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
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: state_table_v4.pd
Type: application/octet-stream
Size: 2885 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110209/d026caf8/attachment-0001.obj>