meters2.pd

I am having some issues here with automating the tempo of second metro (denominator )
The structure is pretty simple
There are 2 metro objects , a red and a blue one
The red one (bottom left corner and left channel ) is triggering a sine , the blue metro is triggering another sine ( bottom right right channel).
Both are using a curve envelope ( cyclone )
The master tempo is located at the top , default is 90 bpm
This goes into a tbf , the float is first send to he right inlet of a division , then the bang is triggering a message of 60000 ms
The result is the time of a beat (one minute divided by BPM) .
It all works fine when disabling-enabling mast toggle but that's not what I want.
Now the issue , the purple and orange boxes all house different denomitor values , used to calculate the new tempo for the second metro ( blue right channel )
When manually triggered these go into a tff , the right outlet of tff goes into a division modue ( green box) and the left output
is trigerring a bang to redo the calculation .
As some of you have guessed , when doing this realtime the second metro is losing sync because of the recalculation .
I tried to automate this ( yellow box, enable spigot ) by sending a bang from the master RED metro into a count-selet module , the ouput is triggering new
denominator values that is send to the tff module (using send receive boxes ) , but again Blue metro is not starting on sync .
Anyone help is appreciated to keep blue metro on sync when receiving a new value .

@gentleclockdivider You missed my edit, generally wise to wait a few minutes before responding to me, I almost always have an edit, often many edits. I think one of us is missing something here. Why would you want to multiply them when you can just speed up the metro and make everything a division of that? Just as an exercise? Best I can think of for multiplication are the two options I outlined above, cheat with a delay or time the bangs, both have issues which are removed by just using a faster clock and dividing.

Apologies if I've overlooked something, but isn't the easiest solution to the original problem to withhold the new metro tempo until the metro outputs? Instead of new speed direct to metro, stash it in a [f] box; then the metro updates its own speed at the right time.

22-1125-polyrhythm.pd

This pattern -- forward to storage, then bang later when needed -- is really fundamental, solves hundreds of situations.

hjh

@gentleclockdivider said:

So how would you make faster bangs out of a single metro that slowly bangs at 1000ms ?

A scheduler queue can do this. I have one in my abstraction pack.

hjh

@gentleclockdivider Oh, figured out the confusion regarding division/multiplication, we were not talking about the bangs themselves but the math, at least I was, perhaps David had something else in mind? Anyways, this is the sort of setup we were discussing, believe you figured it out but for those following along.

Here is a scheduler-queue approach. It's a bit verbose because this isn't a common idiom in Pd AFAICS; I haven't figured out ways to streamline the flow. But it does work.

At left, it's ticking once per second, but it can handle any subdivisions you drop into the queue.

22-1125-polyrhythm-sched.pd

Requires abstractions from https://github.com/jamshark70/hjh-abs

hjh

@oid said:

Anyways, this is the sort of setup we were discussing, believe you figured it out but for those following along.

[sel 0 5] isn't right though, is it? I believe you need the LCM of the three divisions = 60. Otherwise the 3 division will really do 3+2 and the 4 division would be 4+1.

hjh

@oid
We we’re talking about the bangs , because someone said we could either divide or multiply the master metro .
My answer to that was that division would only make sense if the master metro was running at a fast speed .
A slow running metro can only produce faster bangs with inserting delays between additional bangs .
Haven’t thought about the scheduler
Dividing, multiplying counter outputs by use of modulo is straightforward and easy , your example is exactly what I’ve got in mind .
A verry fast metro that run to something dividable by 2,3 ,6

@ddw_music Well, it sort of is right since the [mod 5] before it means the [select 0 5] will never see a 5 so the polyrhythm will play properly in its entirety. The reset was a last minute addition and I clearly did not think it through all of the way. Fixed. Thanks for pointing that out.

you must either restart the second clock (and eventually break its own tempo) or precaculate the speed values and only perform the restart when two beats match.