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