I am trying to generate some commands, in order to be used in a sequencer. The [metro] object generates the values and with the

Here are all the instances I found:

print: 6.17274 play granular object 2 0 1 0 1.02879 0 0 100
print: 6.06735 play granular object 3 0 1 0 1.21347 0 0 100

print: 10.9295 play granular object 1 0 1 0 1.09295 0 0 100
print: 10.9212 play granular object 3 0 1 0 1.21347 0 0 100

print: 17.4894 play granular object 2 0 1 0 1.02879 0 0 100
print: 17.4872 play granular object 1 0 1 0 1.09295 0 0 100

print: 21.859 play granular object 1 0 1 0 1.09295 0 0 100
print: 21.8425 play granular object 3 0 1 0 1.21347 0 0 100

print: 26.7485 play granular object 2 0 1 0 1.02879 0 0 100
print: 26.6963 play granular object 3 0 1 0 1.21347 0 0 100

print: 32.7885 play granular object 1 0 1 0 1.09295 0 0 100
print: 32.9213 play granular object 2 0 1 0 1.02879 0 0 100
print: 32.7637 play granular object 3 0 1 0 1.21347 0 0 100

print: 34.9789 play granular object 2 0 1 0 1.02879 0 0 100
print: 34.9744 play granular object 1 0 1 0 1.09295 0 0 100

print: 40.1228 play granular object 2 0 1 0 1.02879 0 0 100
print: 40.0445 play granular object 3 0 1 0 1.21347 0 0 100

print: 46.2956 play granular object 2 0 1 0 1.02879 0 0 100
print: 46.1119 play granular object 3 0 1 0 1.21347 0 0 100

print: 52.4683 play granular object 2 0 1 0 1.02879 0 0 100
print: 52.4616 play granular object 1 0 1 0 1.09295 0 0 100

print: 53.4971 play granular object 2 0 1 0 1.02879 0 0 100
print: 53.3927 play granular object 3 0 1 0 1.21347 0 0 100

print: 54.6475 play granular object 1 0 1 0 1.09295 0 0 100
print: 54.6062 play granular object 3 0 1 0 1.21347 0 0 100

print: 60.6986 play granular object 2 0 1 0 1.02879 0 0 100
print: 60.6735 play granular object 3 0 1 0 1.21347 0 0 100

print: 65.577 play granular object 1 0 1 0 1.09295 0 0 100
print: 65.5274 play granular object 3 0 1 0 1.21347 0 0 100

print: 66.8714 play granular object 2 0 1 0 1.02879 0 0 100
print: 66.7409 play granular object 3 0 1 0 1.21347 0 0 100

print: 69.9577 play granular object 2 0 1 0 1.02879 0 0 100
print: 69.9488 play granular object 1 0 1 0 1.09295 0 0 100

print: 74.0729 play granular object 2 0 1 0 1.02879 0 0 100
print: 74.0217 play granular object 3 0 1 0 1.21347 0 0 100

print: 76.5065 play granular object 1 0 1 0 1.09295 0 0 100
print: 76.4486 play granular object 3 0 1 0 1.21347 0 0 100

print: 80.2456 play granular object 2 0 1 0 1.02879 0 0 100
print: 80.089 play granular object 3 0 1 0 1.21347 0 0 100

print: 87.4472 play granular object 2 0 1 0 1.02879 0 0 100
print: 87.436 play granular object 1 0 1 0 1.09295 0 0 100

print: 93.6199 play granular object 2 0 1 0 1.02879 0 0 100
print: 93.4372 play granular object 3 0 1 0 1.21347 0 0 100

What I found weird at first is that it didn't seem to correlate with differences below a certain threshold. For example, 93.6199 - 93.4372 = 0.1827, but you can find examples with a smaller difference in time that are aligned correctly. For example, 31.5502 and 31.6956 only have a difference of 0.1454, but they show up like you expect them to. So what gives?

In pd, the order in which you connect things determines the order they happen in. While you have a single bang at the top to start it off, that doesn't mean that these things are really happening at the same time. If you go through all the errors I've listed above, you'll notice a few patterns. First, 2 is never "late" (though as we'll see in a second, I don't think that's really what's happening). So we can assume if they're offset, 2 is ahead of the other two. That means, I would guess you connected the top bang to object 2 before the others. Next, you'll see that 1 & 3 are always late, but that 1 is never late after 3. So I'll guess that you connected 1 after 2, but before 3. How is this relevant?

I believe what's happening is that there is a computational delay between the three bangs that offsets your three separate timers from the get go. Since you have three rather than two, it makes it harder to figure out why that's happening. But essentially I think if you can find a way to use a single timer, then you will be able to get the results you're looking for. I'm not sure what your goals are though, so I don't know if that's really feasible. Otherwise, you could try to sort them before you print, but I'm guessing that's an even less helpful solution. Other than those two choices, I'm out of suggestions. But at least, you know where your problem lies now.

Thank you Psiforce for your reply! I finally solve the issue with only one timer. It is really awful generating algorithmically sound events with PD. There is lack of many tools... For example, if I generate randomly the first elemnt of the "list", which represent the time this sound event will occur, there is no way to sort all messages and store them in the sorted order in a txt file for future use... So I needed to work also with other programming languages to control better the generative process (SuperCollider is much more convenient in this aspect!)