The Aux inputs are mutually exclusive. So if Aux B is set to P.PrE (the default) you won’t be able to set Aux A to that.
I’ll look into the div thing.
The Aux inputs are mutually exclusive. So if Aux B is set to P.PrE (the default) you won’t be able to set Aux A to that.
I’ll look into the div thing.
Of course. Sorry about that.
I seem to recall it’s in the manual as well.
Any chance of windows version as my Virtual Mac couldn’t manage the update. - Thanks
Windows version is now available, link is in the first post
I’m getting a 404 when trying to download the 1.33 Mac firmware.
I’m wondering what it would hurt if you were to make a “forced reset” setting upon reception of the reset signal without having to receive a clock signal at the same time? Most of the other modules I have behave in this manor and I have had to create a special “Y” cable using diodes to get my Intellijel modules to do this as well.
Is this something that could be added in the firmware or somewhere?
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…
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).
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.
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.