Still 404 on the mac file… and the one on Intellijel.com/firmware-updates is only version 1.30
Worked fine for me!
Maybe try this link? https://www.dropbox.com/s/v4ozx2bn9hwpbp5/Intellijel%20Firmware%20Updater.zip?dl=0
Yeah, I just double-checked the website and it’s got the version with 1.33 there…
Also updated the link in this thread.
wow, superfast response! tnx. This also fixed the " ELLO" bug (during boot, instead of “HELLO”) 
I seem to have problems with the glide, it doesn’t do anything anymore. Anyone else?
Ok … user error… i rotated the slide knob to zero while moving the metropolis for the update…
1 Like
I’m having trouble with transposing with P.PrE or P.PoST.
0V is stable, but between 0V and 1V it’s more unstable the smaller the voltage. For example D0 is D0 or C#0 like 50%, G0 becomes F#0 25% and 1V is C1 and it’s almost stable (sometimes C1 is B0). Between 1V and 2V it’s quite stable.
The CV sources are stable (Rene or Roland System8, with or without quantized by DistingMk2) according to O’Tool+. I’ve calibrated after updating to 1.33.
Hello @Kamil - appreciate the ongoing firmware work for the Metropolis…
Safely arrived at v1.33. Unfortunately, still having issues around clocking / clock division.
Bug - behaviour when clocking externally at higher rates (still lower than the internal max 320 BPM) and selecting a clock division larger than 10. I.e. DIV -> DI -> DI_11, DI_12 and further. In this case, the internal sequencer starts stepping erratically / double triggering. When looking at the CLK output, it looks like it actually starts generating a double pulse - like it’s erratically combining the pulse of 10 division with another division, or something like that.
Bug or feature request - not sure… the current implementation of DI and DO clock division.
Right now, there is a direct dependancy between DI and DO - a higher DI division always resulting in the CLK output slowing as well. Essentially, DI clock rate is passed to DO for further division to CLK output. For me, it would be much more intuitive to have DI and DO working independently (‘in parallel’) to the master clock rate, so that changes to DI leave the CLK output rate unaffected and controlled by DO only.
What I am trying to accomplish, is having a higher CLK out rate (controlled via DO) than the internal sequencer clock rate (controlled via DI). Example: (external) master clock rate set at 160 BPM. Setting DI_4 and DO_2 then results in internal sequencer rate moving at 40 BPM, external CLK output triggering at 80 BPM.
Actually, the manual seems to imply that it works this way, but perhaps that’s just me misreading it?
Feature request - on top of all this! - would be that DI and DO supporting basic multiplication of the BPM master rate instead of only dividing. So: DIx2 in addition to DI_2, etc.
This would be completely awesome, removing the need for an external clock multiplier (or even an external clock generator at all).
3 Likes
Really wish I didn’t get my hopes up and kept the Metropolis in the closet.
First I spent hundreds finding a workaround to get it properly transposing.
Then new firmware seemed to fix it at the expense of clock issues and weird crashes.
Then the latest public firmware fixed some clock problems while creating others.
Now the beta firmware screws reset to be virtually useless while retaining some clock problems.
Frankly it’s unacceptable. I can’t even stretch to call this a worthy product. It simply could be a worthy product.
Fix it. Period.
2 Likes
Thanks for your patience. We are shipping Tetrapad 1.00 this week so I’ll finally have some time to work on the Metropolis firmware.
Just to be 100% sure, is 1.33 supposed to get rid of Reset Run Mode featured in the 1.30 update video?
can i get the version that was before 1.30 anywhere? all sorts of weirdness going with 1.33
I get the double note issue and all sorts of weird issues with the sync out pulse.
No, I don’t think removing it was ever part of the plan.
Here’s the Metropolis 1.34 Beta
It should improve the reset behaviour and other timing issues.
1 Like
I’m still seeing some differences in relation to reset behaviour when comparing the Metropolis with some of my my other sequencers. I ran the test described below before (with v1.33) and after (with v1.34) updating with the latest firmware and did not observe a difference in behaviour (in relation to this specific test). I also tried replacing the Quadra EOC as clock with the square output from a Doepfer A-147-2 LFO (as I wondered if pulse-width might matter), but did not observe any difference in behaviour between these two clock sources.
Patch:
Quadra EOC -> Passive multiple
-> Intellijel Metropolis Clock In
-> RYO VC Sequencer (8 stage) Clock In
-> Doepfer A-160-2 Clock Divider Clock In
Doepfer A-160-2 Clock Divider 1/5 Division (or any division greater than 1 and less than the number of sequencer stages (8)) -> Passive multiple
-> Intellijel Metropolis Reset In
-> RYO VC Sequencer (8 stage) Reset In
Configuration:
Metropolis:
Clock: external
Reset: rST_F
Stages: 8
A-160-2:
Trigger/Gate Mode: trigger
Division Mode: integer
Clock Edge Detection: rising
Output: normal/non-inverted
Observed Behaviour:
The RYO sequencer is reset to the first step on the clock signal synchronous with the reset signal.
The Metropolis is reset to the first step on the clock signal AFTER the clock signal synchronous with the reset signal, making it lag the RYO sequencer by one clock cycle.
Thanks for the detailed feedback, I’ll look into this.
It seems significant that the reset signal being derived from the divider (which is being driven by the same clock signal driving the sequencer) is delayed by some small amount of time (I haven’t quantified this amount). In fact you can see the LEDs on the RYO light up momentarily on the stage after the last stage, before the reset signal makes it return to the first stage. This is the same with my Doepfer A-155 (perhaps it’s common to CMOS logic based sequencers).
I tried a variant of the patch described earlier, where the clock signal was used directly to drive the clock divider providing the reset signal, but the same clock signal was delayed slightly (EOC of Quadra envelope with short delay triggered by original clock signal) before being fed to the sequencers.
This resulted in the sequencers being synchronised. It’s worth noting that it only worked across both sequencers when I used the A-147-2 as the original clock signal. When I used the EOC of a cycling Quadra envelope as the original clock signal (as well as the EOC of a separate triggered envelope as the delayed signal), it seemed to undermine the behaviour of the RYO, causing it to advance to step 2 on reset, possibly because the narrower pulse-width of the reset clock signal made it finish before the delayed clock signal arrived and caused another step to advance.
From these observations, it seems possible that the Metropolis logic is such that a decision to reset or not is made each time the rising edge of the clock signal is detected; if the reset signal is found to be high at that moment, a reset occurs; otherwise it doesn’t. If this is the logic, it would explain why a reset does not occur if the reset signal is delayed. The RYO VC Sequencer and Doepfer A-155 both seem to reset immediately when the rising edge of the reset signal is detected
Assuming that this analysis is correct, would it be possible to introduce another reset mode that is based on detection of the rising edge of the reset signal, and forces a reset the moment that condition is detected?
FWIW, on the surface it seems as though my Malekko Varigate 8+ behaves like the Metropolis. I haven’t done a thorough comparison.
To make a general point: a reset strategy based on a high level being detected at a particular clock cycle event clearly avoids the possibility of timing issues (no matter how imperceptible they are). For this reason, if there are no other constraints, it seems preferable to resetting immediately on detection of a reset signal edge.
However, when multiple modules are working together, there will probably be less issues if they use the same reset strategy (whichever that may be). Because there can be no guarantees in relation to the design choices made by the manufacturers of other modules, making the reset behaviour configurable would be helpful.