personal_username

I'm trying to understand why this patch is not working as I would imagine.

Basically is just a super-simple timing patch, with a metro and some rhythm in it.

All I'm asking is to have a consistent behavior with this patch *while* maintaining quantization. But I don't understand why its behavior is erratic if i want it to be quantized: sometimes it works correctly, other times it does not (messing a lot with the tempo, as you can see and hear).

So... I kinda feel stupid for asking this super-simple and basic question about timing, but i really cannot understand what is wrong with this patch...

I'm trying to understand why this patch is not working as I would imagine.
Basically is just a super-simple timing patch, with a metro and some rhythm in it.
All I'm asking is to have a consistent behavior with this patch *while* maintaining quantization. But I don't understand why its behavior is erratic if i want it to be quantized: sometimes it works correctly, other times it does not (messing a lot with the tempo, as you can see and hear).

please-help-me-understand-why-this-is-not-working-timing

yeah, this one is a bit hard to grok, since it has that feedback component to it.

The way I understand it; you're actively changing the quantization of the delay, but since the metro at the hard of it isn't quantized, the timing of your click there really matters a lot for the outcome of the click sequence.

Note how the rhythm gets a lot more predictable? It's still phasing in and out of the intended rhythm, I guess, but it's a lot tighter.

My expectation was that I could add @quantize 1n to the metro to fix it, but that didn't seem to work.

The way I understand it; you're actively changing the quantization of the delay, but since the metro at the hard of it isn't quantized, the timing of your click there really matters a lot for the outcome of the click sequence. 

Note how the rhythm gets a lot more predictable? It's still phasing in and out of the intended rhythm, I guess, but it's a lot tighter. 

My expectation was that I could add @quantize 1n to the metro to fix it, but that didn't seem to work.


Timing is better, but it's indeed playing a binary rhythm (one right, the other wrong)...

I really guess if this is some kind of technically impossible thing (for whatever reason that I'd like to know..., but I would find it pretty strange since consistent timing should be fundamental in this program) or a bug.

Hi Wetterberg, and thanks for your time.
So... it's kinda strange, no?
Timing is better, but it's indeed playing a binary rhythm (one right, the other wrong)...

well I think the fact that you're cycling through a system, and one's synced (the transport itself) and the other isn't (the metro you're using. Well, it's synced, but not quantized)

IIRC the coll quantize patterns don't add up to a full bar exactly, maybe this could be the cause of the sometimes-it-works nature of the one I posted?

well I think the fact that you're cycling through a system, and one's synced (the transport itself) and the other isn't (the metro you're using. Well, it's synced, but not quantized) 

IIRC the coll quantize patterns don't add up to a full bar exactly, maybe this could be the cause of the sometimes-it-works nature of the one I posted?


just tried it... if i substitute coll with a [sel 0 1 2 3 4] triggering [8n 4n 8n 8n 16n] the result is the same...

btw, i could quantize metro directly but it doesn't seem to solve...

just tried it... if i substitute coll with a [sel 0 1 2 3 4] triggering [8n 4n 8n 8n 16n] the result is the same...
btw, i could quantize metro directly but it doesn't seem to solve...

Is 0n a valid time designation? It's not explicitly listed in the doc. Maybe using it is causing undetermined behavior?

i use it regularly and no issue about it.

"0n" causes troubles only if given to a metro as rhythm: it goes in overflow and for obvious reasons! ;-)

Thanks Luke,
i use it regularly and no issue about it.
"0n" causes troubles only if given to a metro as rhythm: it goes in overflow and for obvious reasons! ;-)


"just tried it… if i substitute coll with a [sel 0 1 2 3 4] triggering [8n 4n 8n 8n 16n] the result is the same…"

That's not my point. 1/8+1/4+1/8+1/8+1/16 = 0.675, which could mean that sync is weird when looping through it like this.

yes. the patch is strange, to be precise. I can't produce a predictable rhythm, since I can't fully read what is expected to happen.

I'm fairly certain this isn't buggy behavior at all, btw. This is just a weird patch that none of us fully grok.

Honestly,
>So… it’s kinda strange, no?
yes. the patch is strange, to be precise. I can't produce a predictable rhythm, since I can't fully read what is expected to happen. 

I'm fairly certain this isn't buggy behavior at all, btw. This is just a weird patch that none of us fully grok.


It is clear that something is at least starting to make sense.

So, bottom line: I assume this patch (or the likes) can't be be correctly e consistently behave.

Hey!
thanks for the tip Raja!
It is clear that something is at least starting to make sense.

I was re-reading RAJA's first reply and, I don't know if I now get it right or not, but it looks like there could be a workaround for this. Especially when he says "master-metro that’s always going from which to sync the start of all other sequences".

Here's my first attempt, of course there may be some ingenuity, but it is actually the first time I decide to deal with a master tempo, so I hope this approach is correct.

Basically it should act as a quantization without a proper one. If i get it right.

And this approach could avoid placing any @quantize in my patch, avoiding the rhythm inconsistencies we were seeing before. Again: I guess.

I also hope that this way there will be possibly no asynchronous event however long the patch runs.

Basically it should act as a quantization without a proper one. If i get it right.
And this approach could avoid placing any @quantize in my patch, avoiding the rhythm inconsistencies we were seeing before. Again: I guess.

seems like you only copied your presentation, not the actual patch?

it's the first time i copy a patch in presentation mode, and i thought all the informations would remain in! ;-)

Thanks Wetterberg!
it's the first time i copy a patch in presentation mode, and i thought all the informations would remain in! ;-)

Please, help me understand why this is not working... (timing)