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 Does sending a start at the same time to the [metro] left inlet help?
Between the green [/ 3] and the left inlet of the blue [metro] put the message [1 $1(
The parts of the message are distributed across the inlets of the [metro] so you know it gets them at the same time.
Disconnect the direct cord between [/ 3] and the right inlet of the [metro] of course.

When you say... "out of sync" ..... out of sync with the red [metro]..?
You might need to do the same for both?
David.

When I mean by losing sync , I mean the second metro is not starting on sync when receiving new denominator values .
These are polyrhytms , it should start on the same beat ( which they do when using the toggle ° )
I don't understand what you mean by sending message 1$1 variable to get the messages at the same time .
This is already done , because the right inlet of the green box division is receiving a value by tff second outlet( denominator float ) ,
The letft inlet of he green box division is just waiting for the master beat value ( which is the same value as long as the bmp is not changed °) , the tff first float outlet is just used to retrigger the calcuation.
In hindsight I could just use a tbf instead of tff , since the first float outlet is used to bang , but it doesn't really make any difference
Here , upon every beat change , the blue osc frequency is also changing (appearing at right channel ) , it should make it obvious (enable spigot for automating )

meters2.pd

@gentleclockdivider When you use the toggle you stop and then start both [metro] at the same time.
For them to sync you need to do the same when you change the timing for the blue metro.
You don't need to stop them, as a 1 to the left inlets will restart them.
I cannot edit your patch (using vanilla) so here is a partial screenshot..
David.

Changing just the tempo doesn't restart the [metro].
It bangs effectively after a delay...... changing the delay time during that delay "does just that" and it doesn't output a bang as the message arrives...... only as the delay expires... so it no longer syncs.

@gentleclockdivider A simple way to avoid this is just to reduce this down to a single metro banging a counter which you use to derive your timing information for everything through basic math and the use of [select] to get your bangs.

@oid Yes, I was going to get around to that.
I remember there was once a debate about whether a fast master and division or a slow master and multiplication would be better.
David.

@whale-av I was surprised you did not mention it, fairly certain you are the one who pointed this out to me in the first place. I believe I found that division works better despite computers being more efficient with multiplication, I have a vague memory of discovering that there is something regarding the PD gui, when it starts lagging there is less chance of the metronome lagging/audio lagging when dividing. But that was a very gui intensive patch and is only a vague memory. I think all that matters is being aware that switching to division or multiplication may solve issues with lagging for those rare occurrences that it is actually an issue, the rest of the time we can just go with what is easiest/most readable/most intuitive and enjoy the ignorance.

A single master metro makes sense if it has a fast rate , then we can drive a counter and a select module etc ,
But how could one get a faster rate out of a slow tempo clock ?
You can’t get more bangs out of slow banging metro ?
Perhaps delaying a bang multiple times ?

@gentleclockdivider Division by 2 is the same as multiplication by 0.5

Edit: or are you asking how to make it work with a slow clock and not just confusing yourself by over complicating things? As someone who constantly confuses themselves by over complicating things, I can not tell when others are doing it or just asking a question?

Properly timed multiplication would be by cheating with a delay, I think, I can not think of any other reliable way. But you could certainly measure the time between two bangs to output one between, but things would get hairy rather easily.

I know that 😀,
But we can’t multiply bangs of a metro , we can only works with the nr’s date coming out of a banged counter.
We can only use the bangs into a counter ,
So how would you make faster bangs out of a single metro that slowly bangs at 1000ms ?

@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.