Sync Metropolis @24ppqn?

Cwejman, Doepfer, Erica, MakeNoise, Mutable instruments, TipTop Audio, Analogue Solutions, and much more! The world’s most popular format.
Be sure to look into MANUFACTURER SUB-FORA as well..
Post Reply
User avatar
dbeats
Veteran Wiggler
Posts: 523
Joined: Mon Apr 18, 2016 3:50 am
Location: Kiel, Germany

Sync Metropolis @24ppqn?

Post by dbeats »

I want to sync Metropolis to an external clock and rhythm in 24ppqn resolution. 16th note is no problem, but I'd prefer the higher resolution in my system. From what I understand I can do it in two different ways:

a) Din24 mode: Set "Int/Ext" to "C_d24" and put a continuous "High" signal to the reset input. This works for tempo, but the problem is, I can no longer use the reset input to sync the "1", that is the beginning of bars and patterns.

b) Clock divider mode: Set "Int/Ext" to "C_EXT" and "DIV" to "di 06", dividing the input clock by 6 to get standard 16th resolution. Again, this works for tempo, and I can use the reset input now to reset the pattern, but I haven´t managend to sync exactly to the "1".

Metropolis has two different reset behaviours to choose in "CONFIG":

i) "If RST n then reset occurs on the next clock pulse."
This is not the default setting. Problem is, the reset occurs on the next clock pulse of the 24ppqn input clock, so it´s one pulse (or 1/6 of a 16th note) too late. You hear that, of course.

ii) "If RST F then reset occurs if the CLK input is high at the same time as RST jack is high."
This is the default setting. There seem to be two problems: First, Metropolis seems to reset only if the already reduced 16th clock pulse is high at the same time. So when the 24ppqn incoming master clock resets in between 16th notes, Metropolis ignores it.

Second, if the reset trigger does hit a 16th note but the reset high signal is longer than one master pulse (in 24ppqn resolution!), Metropolis performs another reset on the next 24ppqn pulse and so on. The Trigger Riot reset signal, for example, seems to be about 1/32 long, and when eventually hitting Metropolis on a 16th note it causes 2-3 fast resets in a row, after which the TRs "1" sits perfectly in between two 16th notes of Metropolis and remains there forever, never resets again.

Can anyone confirm this problem? Or help me out? Anything I'm missing here? Any help is much appreciated, thx in advance!
kat
miss modular
Posts: 183
Joined: Sat Jul 16, 2016 2:53 pm
Location: between the mountains and the sea <3

Post by kat »

wasnt that one of the updates on the last firm ware update?
User avatar
dbeats
Veteran Wiggler
Posts: 523
Joined: Mon Apr 18, 2016 3:50 am
Location: Kiel, Germany

Post by dbeats »

Dunno but according to their website I have the latest firmware 1.14 running in my Metropolis.
User avatar
eewee
Wiggling with Experience
Posts: 259
Joined: Wed Aug 26, 2015 2:34 pm
Location: Belgium, close to Brussels

Post by eewee »

Did you ever get this resolved? I'm trying the same thing:

- Trigger Riot in DAW clock mode (24ppqn clock, single reset pulse at start);
- TR clock and reset to Grids (who is playing a simple bass/snare rhythm);
- TR clock and reset to Metropolis, set to external clock, div_i=6, and rst_F;

Using start/stop on the Trigger Riot, most of the times the snare falls on the 5th step of the Metropolis, but occasionally it falls on the 4th, suggesting that the Metropolis reset too late.

Both TR and Metropolis are running the latest MW.
Why, say she now, is I not glean that one may say of thing while thing is not.
(Alan Moore, Voice of the Fire)
User avatar
dbeats
Veteran Wiggler
Posts: 523
Joined: Mon Apr 18, 2016 3:50 am
Location: Kiel, Germany

Post by dbeats »

Yeah, sounds exactly like the problem I described above. I finally solved it with an additional clock divider, and I´ve been running Metropolis in 4ppqn since. At least a stable solution.

I´ve recently updated my Metropolis to 1.30 (May 16, 2017), and the release notes say (among other points):
- Improvements to clocking and overall timing / performance
- Improved DINSync support.

But tbh, I´ve never examined the 24ppqn syncability again since updating. Are you sure you are running this major updated version 1.30, and still have the problem?
User avatar
eewee
Wiggling with Experience
Posts: 259
Joined: Wed Aug 26, 2015 2:34 pm
Location: Belgium, close to Brussels

Post by eewee »

dbeats wrote:Are you sure you are running this major updated version 1.30, and still have the problem?
Yes - maybe not as bad as you described it in the original post, but still occasionally. The DINsync support is an extra 24ppqn clock option, but it requires a run gate on the reset input (which I dont want).

Not sure about the difference between using the internal clock-in divider and an external one, as you do. Any thoughts?
Why, say she now, is I not glean that one may say of thing while thing is not.
(Alan Moore, Voice of the Fire)
User avatar
dbeats
Veteran Wiggler
Posts: 523
Joined: Mon Apr 18, 2016 3:50 am
Location: Kiel, Germany

Post by dbeats »

eewee wrote:The DINsync support is an extra 24ppqn clock option, but it requires a run gate on the reset input (which I dont want).

Not sure about the difference between using the internal clock-in divider and an external one, as you do. Any thoughts?
The 24ppqn option that requires a run gate is nothing new, see my initial post above. I didn't want that either. Really curious to know what exactly was changed in v1.30. Anyway, I'll check it out again myself tonight.
User avatar
eewee
Wiggling with Experience
Posts: 259
Joined: Wed Aug 26, 2015 2:34 pm
Location: Belgium, close to Brussels

Post by eewee »

OK - thanks for looking into this again. In the meantime, I'm also starting a thread on the Intellijel forum, to see if they have an idea on how best to approach this.
Why, say she now, is I not glean that one may say of thing while thing is not.
(Alan Moore, Voice of the Fire)
User avatar
dbeats
Veteran Wiggler
Posts: 523
Joined: Mon Apr 18, 2016 3:50 am
Location: Kiel, Germany

Post by dbeats »

Just spent quite a few hours with my Trigger Riot, Metropolis and an oscilloscope. I´m a little confused now.

There seems to be an issue with the clock and reset sync between my TR and my Metro that has nothing to do with 24ppqn, because I also encounter it using 16th clock out on the TR and normal ext in on the Metro.

Most of the time my TR reset out signal executes one clock pulse later on the Metro, but only the cycle-based periodical resets and not the manual resets. As if I was using RST n, but I am surely using RST F. So, in terms of 16th notes, a TR cycle reset on 1 happens on the Metro at 2. This leads to the Metro playing the first note on 1 twice, then playing the full pattern 1/16th behind.

Then I used SSF Propagate to modify the signals: Proper-gating the reset signal in every possible way didn´t help anything. But sending the clock out signal from the TR through the Progagate into the Clock input of the Metro fixed the problem immediately, regardless of the clock pulse width setting (i.e. worked with minimum pulse width already). I really don´t understand that, as the clock out signal from the TR seems ok, almost too strong. I couldn´t fix it with either a VCA or a buffered mult though, only Propagate fixed it.

WTF?
User avatar
dbeats
Veteran Wiggler
Posts: 523
Joined: Mon Apr 18, 2016 3:50 am
Location: Kiel, Germany

Post by dbeats »

I don´t know if anyone else is interested in this, but for me it´s pretty relevant.

I´ve included two snapshots from my oscilloscope. The regular yellow peaks are the 16th clock pulse output signal of the Trigger Riot. The single blue square wave is the reset output signal of the Trigger Riot.

In this first example I run both the clock pulse and the reset signal directly from TR into Metro. The rise of the reset signal happens exactly at the same time as the rise of the 16th clock signal. In this case Metropolis does NOT reset immediately, but at the next 16th clock pulse, causing the sync issue described before.
Image

In this second example I still run the reset signal directly from TR into Metro, but the clock pulse through my SSF Propagate with minimum delay and minimum pulse width dialed in. As you can see, apart from being shorter, Propagate adds a little bit of delay to the clock pulse signal, so the rise of the reset signal happens a little bit earlier than the rise of the corresponding clock pulse. In this case, Metropolis does reset correctly and stays in sync.
Image

Is this old hat, or a new finding for some of you?
User avatar
eewee
Wiggling with Experience
Posts: 259
Joined: Wed Aug 26, 2015 2:34 pm
Location: Belgium, close to Brussels

Post by eewee »

Getting more and more interesting. FWIW, I also started a thread at Intellijel (https://forum.intellijel.com/t/metropol ... -reset/249), pointing at this one. I am sure they will come up with a good explanation.
Why, say she now, is I not glean that one may say of thing while thing is not.
(Alan Moore, Voice of the Fire)
User avatar
eewee
Wiggling with Experience
Posts: 259
Joined: Wed Aug 26, 2015 2:34 pm
Location: Belgium, close to Brussels

Post by eewee »

Looking at your scope screens, if I were to guess, you'd be in rst_n mode: in the first one, the reset is recognised too late, and only gets effective at the next clock, in the second it also gets effective at the next clock, but is now recognised in time.

rst_F would not work in the first case, as your reset is never high when a clock is passing by.

I know you said you were sure you were in rst_F, but over the last days I noticed that it had changed in my setup as well after a reset, forcing me to load a config before it was in rst_F again.
Why, say she now, is I not glean that one may say of thing while thing is not.
(Alan Moore, Voice of the Fire)
User avatar
dbeats
Veteran Wiggler
Posts: 523
Joined: Mon Apr 18, 2016 3:50 am
Location: Kiel, Germany

Post by dbeats »

eewee wrote:Looking at your scope screens, if I were to guess, you'd be in rst_n mode
Yeah, exactly! But I am not.

Next problem is, I´ve just tried rst_n and that mode does not work at all here for my module, never resets to any reset input, only at the end of the Metropolis stages. Maybe my reset mode is somehow corrupt? Could that be a result of the latest v1.30 update flash process? I´m pretty sure I didn´t have that problem with my old firmware. rst_r works correctly, though, as the whole module itself, everything except the reset behaviour.

Something must be buggy here. I tried different modules with clock and reset output (Trigger Riot, MI Grids, Brains/PP, Tuesday), and they all reset one clock pulse too late except if I put a short delay to the clock pulse as described above. Really looks like my rst_F works as a rst_n.

Could someone please check if they also have this problem with the v1.30 firmware?
User avatar
eewee
Wiggling with Experience
Posts: 259
Joined: Wed Aug 26, 2015 2:34 pm
Location: Belgium, close to Brussels

Post by eewee »

dbeats wrote:Next problem is, I´ve just tried rst_n and that mode does not work at all here for my module, never resets to any reset input, only at the end of the Metropolis stages.
Yup, saw that as well. I figured I could work around the problem by manually resetting when stopped, either on the TR, or with a manual switch. But it looks as if the reset is not seen if there's no clock input.
Why, say she now, is I not glean that one may say of thing while thing is not.
(Alan Moore, Voice of the Fire)
User avatar
dbeats
Veteran Wiggler
Posts: 523
Joined: Mon Apr 18, 2016 3:50 am
Location: Kiel, Germany

Post by dbeats »

eewee wrote:I figured I could work around the problem by manually resetting when stopped, either on the TR, or with a manual switch. But it looks as if the reset is not seen if there's no clock input.
I think you can stop, then manually reset on the Metro, then start externally and never reset again, leaving the reset input unused. Metropolis should start and stay in sync based on the incoming clock pulses. But then you can never again execute a reset during play, and Metro resets itself each time when the end of the number of stages configured is reached. Not very satisfying though.
cowboy
Learning to Wiggle
Posts: 23
Joined: Wed Aug 16, 2017 10:25 am
Location: Boston, MA
Contact:

Post by cowboy »

I don't know if it's related, but I'm also having trouble with my Metropolis and timing issues. I posted about it in another thread!

viewtopic.php?t=188089
User avatar
dbeats
Veteran Wiggler
Posts: 523
Joined: Mon Apr 18, 2016 3:50 am
Location: Kiel, Germany

Post by dbeats »

Today I once again patched my Trigger Riot as a master clock and master reset source for some slave sequencer modules: PP/Brains, A-157, Tuesday, Grids, Octocontroller ... and Metropolis. Metro v1.30, and standard 4ppqn clock this time. CYCS 4 CYCE 68, so resetting every 64 pulses.

I didn`t have to wait long, only a few cycles, to encounter the well-known reset issue on the Metropolis: Metro sometimes resets twice and is then 1 pulse behind. Sometimes it corrects after a few resets, only to fail again on one of the next resets.
All other modules clock and reset correctly, why not the most expensive one? This major bug is well-documented now for 5 months :bang:

Anyway, I seem to have found an acceptable workaround: If you want to use TR as master and Metropolis as slave, you can sacrifice one row or column of your TR and use the corresponding output as a dedicated reset output for the Metropolis reset input. And then you program one single short gate just before the master reset happens. So in my example:
divide 67
pulse width 1
time shift 4


The small time shift is needed to avoid a reset 1 pulse too early. It works with several numbers, in my example in the range of 1-5. You can see the timing of the reset gate (blue) compared to the normal 4/4 beat triggers (yellow) here, it rises a little bit earlier:

Image

Please note that the Metropolis reset config is still rst=F. This should stay in sync forever, or at least until the next fw update.

dbeats
Post Reply

Return to “1U & 3U Eurorack Modules”