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 < [email protected]> 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 <[email protected]> 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 >> > >
state_table_v4.pd
Description: Binary data
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
