The new firmware and manual are now ready for download! We are calling it version 1.30.
New features
Watch this video for a quick tour of all the new features:
Improvements to clocking and overall timing / performance
The AUX inputs can now track 1V per octave in P.Pre, P.PoST, and RooT modes. Config menu option added to calibrate them.
New aux destinations P.PreL P.PoSL and RooTL which work like the old ones used pre-1.30.
Ratcheting enabled by hold holding a stage button and turning the encoder.
TunE option in the CONFIG menu for assisting with tuning oscillators.
bSLId / bSKIP option in the CONFIG menu to toggle the default behaviour of the stage buttons between slide and skip.
rsT option in the CONFIG menu now has rST_r, “run” mode. In this mode the RESET input functions as a RUN input which is a gate input complimentary to the RUN output of the µMIDI. When the gate is high the sequencer runs. When the gate is low, it stops and resets.
Shortcut keys: Hold MODE, STAGES, STEP/DIV, SCALE, SWING or DIV and then press one of the stage buttons to quickly access commonly-used values.
Improved DINSync support.
Pattern saving, with 8 slots. Hold the SAVE button and click one of the stage buttons to save the current pattern. Hold The LOAD button and click one of the stage buttons to load a previously-saved pattern.
8 slots for global settings. In the SAVE and LOAD menus you can use the encoder to select a slot from 1-8 before clicking it to load and save the global settings.
I have to do the calibrate every power cycle other wise the aux input do not do anything. is this normal or am i missing something to save the calibration?
EDIT
well is seams like the problem is only with P.Pre on the aux a it only works if i calibrate it. but it works fine on aux b.
Hm yeah, there seems to be some kind of bug only affecting P.Pre on Aux A. Doesn’t affect the other destinations or P.Pre on Aux B. I’ll look into it when I have time, but for now just use P.Pre on Aux B.
Having an issue with the update.
I have rev12, see attached pic for pin placement.
Zendesk gives the following error when using contact us, so using the forum:
“There was an error processing your request. Please try again later”
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000 (retrying)
avrdude: Device signature = 0x000000 (retrying)
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATmega328 is 1E 95 14
avrdude: NOTE: “flash” memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
If you received a USB ISP in a blue enclosure, you need to adjust it before use:
Open the enclosure by releasing the 4 small plastic tabs on the back with a small screwdriver.
On the circuit board inside, either remove or move the small jumper near the red stripe of the cable labelled “PWR” so that it’s not shorting the two pins on the header together.
Close the enclosure back up and use the ISP!
Similarly if you’re using any third-part ISP, make sure that it is not set up to provide power to the device being programmed. Most of them have a jumper for this. The Metropolis CPU gets its own power from the Eurorack bus already and if the programmer is also providing power it can interfere with the process.
HI Kamil. I just received the blue cased one direct from Intellijel and got issues described. Moved the jumper and it still said issue with device signature. Tried to again on a different Mac and the process looked like it was working correctly on updater, but then said failed near the end.
Power cycled metropolis and it won’t power up at all now. At a guess, have I now bricked this unit?
as metropolis wasn’t powering, I moved the header on USB ISP for PWR again, then ran the update with the hope USB ISP would power it enough. This worked and the unit updated and all screen and LED’s flashed back to life.
I have my Windows machine user account devoid of admin privs for security. I had to run the Updater program as administrator before it worked correctly. My Metropolis had actually gotten unresponsive before I successfully got it updated. Don’t give up!
I haven’t been able to figure out yet what makes the update more finicky for some people than others. It seems we didn’t have as many problems with the programmers in the past as with this last update, or maybe a lot more people are updating now because it’s more worthwhile.
In any case, there’s basically no circumstance where you can completely brick your module. There’s always some way to recover. Usually the PWR header on the programmer helps, or using a different USB port, hub, or computer. In the worst case it’s always possible to replace the ATMega328 chip which only costs a couple of dollars.
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: error: programm enable: target doesn’t answer. 1
avrdude.exe: initialization failed, rc=-1
avrdude.exe: AVR device initialized and ready to accept instructions
avrdude.exe: Device signature = 0x740000
avrdude.exe: Expected signature for ATmega328 is 1E 95 14
avrdude.exe: NOTE: “flash” memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
Note: make sure your hex file is in the same directory you are working in. This worked fine in Linux. Also check your board revision and download and alter the command to the appropriate hex file.
Greetings! Has anyone been able to recover once the Metropolis is bricked? I have several emails out to support and have not had any response as to how to recover. I have tried the updater under multiple computer/cable pairings and nothing works.
Mine was totally unresponsive before the updater worked. It took me fifteen attempts, at a guess, before it finally worked. I tried from Windows and Mac OS X. Windows running the updater “as administrator” finally did the trick for me.
I kinda wonder if some computers aren’t spitting out the update faster than the MCU can read it off the ISP.
That was one of my theories. Weird thing is we never see this happen at any of the machines in the office, or on my dev machine. In the next version of the updater software I’m going to add a preference to throttle the speed, see if that will help people.
