Metropolis v1.30 Update

Firmware Updates
#22

It did for some people, not for others.

I’m actually going to add an option to the firmware updater software to slow down the data rate, see if that helps some people as well…

#25

Hey Guys,

after the Firmware update my reset is not working anymore.
Sync Start and Reset both come from my tanzbär. the sync is working fine but the reset is doing nothing.
its set to rst_n. also when i change it to, i think _F, sync and clock Led light up and i cant change anything anymore. even setting it back to rst_n doesnt work…

am i doing something wrong here?

thx

#26

I had no issues with the update process but having all sorts of issues with the 1.3 OS. I can not SAVE any patterns or LOAD any patterns. Nor can “unload” the pattern using the LOAD and pushing EXIT. That is not working either. Anyone else experiencing this?

#27

Hi,
After reading these posts on the forum, I moved the power jumper off the two pins of the USB ISP and I am also getting an error.

I am running Windows 10 but have installed the win8x32 drivers. I tried using the Win7 drivers with the same results. I have sent in a question about win-10 drivers before I found this forum, but have not received a reply since it is the weekend.

Here is the log from my latest attempt to update to 1.30:
C:\Users\Ray\AppData\Local\Temp\vyoixkxw.bkf\avrdude.exe -F -Pusb -cusbtiny -patmega328 -C"C:\Users\Ray\AppData\Local\Temp\vyoixkxw.bkf\avrdude.conf" -Uflash:w:“C:\Users\Ray\AppData\Local\Temp\vyoixkxw.bkf\Intellijel_Firmware_Updater.Firmware.metropolis_1.30.hex”:i -Uefuse:w:0x05:m -Uhfuse:w:0xDA:m -Ulfuse:w:0xFF:m

avrdude.exe: initialization failed, rc=-1
avrdude.exe: AVR device initialized and ready to accept instructions
avrdude.exe: Device signature = 0x666c61
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.

avrdude.exe done. Thank you.

==> Error occurred during update.

#28

HI,

i posted this on the muffs but thought i would bring it here too. i updated my metropolis the other day and i love the additions! through experimenting with the ratcheting and internal clock divider functions i think i found a little bug.

it seems as though no matter the division using the internal divider the ratchets are still based on the tempo of the master clock. ie when using a mater of 120 and dividing by 2 there is no distinguishable difference in gate timing between the divided and undivided clock. on the other hand if i reduce the master by two the gates seem to function as i would expect.

has anyone else experienced this?
thanks

#29

Hm, the ratcheting code definitely takes the clock divider into account when calculating the gate length. If you can film a quick demonstration video and send a link to support@intellijel.com maybe I can figure out what’s going on.

#30

i was wondering (with the reset not working for me) if i should consider going back to the last firmware it was still working depending how much it would take for a fix!? also how would i go back to the latest working firmware? much love

#31

Now we have have multiple saves available does this mean we lose the ability to have a default power up state? Is it possible to have save 1 be the default? Getting annoyed with having the unit reset on power up right now

#32

just checked the new manual (old manual is still up in some places surely the new one should be default now).

it says “The last saved slot is loaded the next time the power is turned on to the sequencer.” This doesn’t seem to be the case on mine.

#34

I discover exactly the same issue as stalkeramongstars posted on Jul 29 .
Sync is fine, but reset (start
Metropolis with step 1 of the sequence) nothing, Metropolis simply
starts where he stopped before.
Clock and reset coming from Analog Rytm through MI Yarns. Reset pulse is coming when the Rytm does start, confirmed by LED.

Beside this my reset (and the run button) do not react reliably, so it is much frustrating with the Metropolis at the moment.

BTW, I am somehow surprised that after 25 days of stalkeramongstars post there is still no reply from intellijel …

Hope someone can help me how to overcome my/our difficulties.

Thanks,
Frank.

#35

That’s another bug that seems to have have crept in during the beta testing of 1.30. I’ll fix it in the next patch release.

#36

Why is it that the root setting jumps from C0 to C#1 (the next step is 13 semitones higher then the first). After that the root notes climbs 1 semitone at a time as expected. Why is this? Can this be fixed?

I’m on 1.3 (updated, i purchased it before that)

#37

Already have a fix for this which will be in the next patch release.

#38

Good evening!

I’m trying to clock and reset my Eurorack from a TipTop Trigger Riot, running in DAW mode (meaning 24ppqn clock, with a single reset pulse at every start).

This works fine with a Mutable Instruments Grids, but I’m having a problem with my Metropolis (running 1.30 firmware). I am using c_ext, di=6, and rst_F, and what I see is that with a simple bass/snare rhythm on the Grids, the snare usually falls on the 5th stage, but occasionally, after stop/start on the TR, it falls on the fourth (as if the Metropolis reset too late).

So a few questions:

  • am I doing something I should not be doing?
  • can somebody explain where things go wrong, and how they should be fixed?
  • in a related MW thread (https://www.muffwiggler.com/forum/viewtopic.php?p=2599222#2599222), somebody is suggesting to use an external clock divider, rather than the internal one - would that change anything (especially in the way that rst_f setting works)?

I also noticed that the Metropolis is getting rather sluggish in button reaction when feeding it a high speed clock: most of the buttons need to be pressed long or several times before they react (if at all). At some point I even thought it had crashed.

Any thoughts? I’d like to hear them. Thank you for your time!

#39

Have you tried the c_d24 mode instead?

#40

yes, briefly. But that includes the run/stop gate behaviour on the reset input, which is not what I want. I need a pulse style reset that I can distribute.
Please also check the MW thread I mentioned, somebody is looking for the exact same thing there.

#41

two MW threads discussing 1.30 strange/incorrect reset behaviour now :slight_smile:

Is there a possibility of giving some insight on whether this is indeed a bug, or a misunderstanding (or the seed of a feature request :slight_smile:

thank you!

#42

Sounds like it could be a bug. I’ll need to look at it in more detail when I have some time. It would be helpful if you could summarize the exact reproduction steps, it’s very time consuming to dig through muffwiggler posts.

#43

Sure - although my original post already describes it in some detail:

  • DAW style clock out of a Trigger riot (that’s 24ppqn, and a single reset pulse at start);
  • Metropolis set to external clock, input divide by 6, and rst_F reset style behaviour;
  • mult the clock and reset to something else to get a reference (I used Grids, with a simple snare on the third beat (meaning the 5th stage on the Metropolis);

Then just start/stop a few times, and sometimes you’ll hear the snare already on the fourth Metropolis stage (as if it missed the first one after the reset, and only reacted to the second /6 clock trigger).

I tried rst_n as well, but it looks like that is not working (except when the clock is running, not when the Metropolis is stopped). And of course rst_F suspiciously looks like what rst_n is supposed to do.

If you have time to go through the (rather short) thread I linked to, you’ll see that somebody even hooked up a scope to ‘prove’ what I am describing.

Let me know if I need to test or describe extra stuff.

#44

@kamil
Any news here?
I discover same problems (reset not working and sluggish run and reset buttons.

Thanks,
Frank.