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.
The reset is already edge triggered, but the next step is not output until the next rising clock edge, which is why it may appear that it is actually level triggered. This is also probably why in some it seems out of sync when a reset and clock pulse are received simultaneously.
Under the current scheme, if the clock pulse is serviced before the reset, the module will first process the clock pulse and advance the sequencer, but then when it processes the reset pulse it will return to the first stage and await the next clock. If the reset pulse arrives slightly before the clock and is processed first, then the module would respond by first being reset and then outputting the first stage once it gets to processing clock.
If the reset signal also caused the first stage to be output, the problem would just be inverted. If the reset came just slightly before the clock it would reset and output the first stage, but then immediately advance to the second stage. If the reset came slightly after then it would first advance to the next stage, but then immediately reset to the first and output that, appearing to behave as expected.
I guess the only solution is to allow both behaviours and have them be selected. Actually I think that’s how the rST_n and rST_F options behaved in earlier firmwares but their behaviour changed due to some other timing and clock changes. I’ll see if I can resolve this.
Unable to update to 1.34. Currently on 1.33. I couldn’t select and highligh tthe log so had to do a screenshot. I am using the same third party programmer as before.
I have been able to upgrade it to 1.34 and used it for a couple of hours last night without any issue, but today it is stuck on HELLO after showing Ver 1,34.
I have already uploaded the 1,34 firmware to different atmega328 and all do the same.
Now I had uploaded the 1,33 and everything works normal…
I am using Arduino Uno + HexUploader.
What can I do?
when can we expect a final version of 1.34? is it going well? I’m a bit hesitant to update with the beta firmware.
Just prepping some stuff for NAMM, but I may get time to do another beta this week. It seems that the reset behaviour is the one major outstanding bug in this, hopefully it’s not too difficult to fix.
Ok, I’ve posted the 1.35 firmware. Please have a go.
1 Like
Here are the download links:
For Mac users:
and for Windows users (still 1.33 for now):
https://intellijel.com/downloads/firmware/Intellijel_Firmware_Updater_Windows_2017-10-04.zip
the mac link above seems to be broken, but the one Kamil updated at the beginning of this thread seems to work.
Weird, I copied and pasted it from Kamil’s post and it added a 3 at the end of the link. It’s corrected now.
The 12 at the end of the windows link breaks that one too - works fine if the 12 is deleted.
D’oh! Fixed that one too now.
Hi all – about two weeks ago I purchased a new metropolis. It was loaded with 1.34. All good until two nights ago. I switched clock to external, reset_r, works good --> save --> turn power off --> turn power on --> metropolis displays “hello” and nothing else, can’t access any configuration menus, regardless of whether clocks/resets are being fed in or not. I was effectively locked out.
Last night updated to 1.35, and I’m stoked to see everything in expected working order again. Sequences are running and I can access configuration menus. I try once again: set clock to external, (but this time keeping reset on default behaviour) and save. turn off power -> turn on power -> metropolis displayed “hello”, no running behaviour, no access to configuration menus.
Tonight I’ll try flashing it again, if it’s even possible (since I’m already on 1.35).
Kinda frustrating. Please let me know if I’m missing something, or if there is something I can do to help with troubleshooting. There’s still no “factory reset” shortcut on boot, hey? Thanks all.