Metro randomly stops while starting/stopping with velocity
Video of the problem in action after applying Source Audio's fix. Notice the button coming out of metro, and how it just stops registering bangs and the midi output stops in the recorded loop.
Forgive me if I'm missing something obvious, I'm quite new and I've been trying to solve this for 2 days now.
I've included my Audio Status settings just in case.
Desired Behaviour: I want metro to only run while receiving Note-on, and I want to reset its count on Note-off, to drive a counter which in turn drives a grid.
Issue: metro will randomly stop sending bangs after stopping and then starting. It will always send at least one bang.
The issue is inconsistent, but seems to always start occurring some time after the patch has been opened in max device editor. Sometimes it will occur on a fresh load.
Steps Taken:
- I've confirmed the issue is with metro by verifying what is being sent to and from metro with messages and bangs
- restarting Max, restarting ableton, restarting PC
- configuring metro with as every combination of @active @quantize and @transport
- lots of experimentation with various on-load bangs like loadbang, live.thisdevice. Even when I can keep the metro running and just gate the makenote with velocity it behaves inconsistently (and I don't want metro to always scroll through the grid)
What's really making me tear my hair out though is that this was originally working at the beginning of the week. It's leaving a bad taste in my mouth with how inconsistent Max's behavior and I don't really know how to troubleshoot this further.
Any insight would be greatly appreciated, thank you.
Thank you. I was hopeful at first but unfortunately this doesn't work. I made a video demonstrating the problem, I'll add it to the opening post as well
Edit: yes I know sel 0 is going into a different inlet on counter; it doesn't matter which inlet it's in. The problem is metro, you can see its bang out and how it just stops running.
I am not using Live and can't help you with that.
All I can say is that in Max metro never has such problems,
and that you are somehow overloading Live.,
probably with too fast messages to GUI objects.
Nothing to do with metro itself, I guess.
Yes, you are doing something wrong somewhere. I use metro (and metros underlying clock mechanism) extensively in Live with Scheme for Max and it's definitely solid, reliable, and consistent - if you aren't somehow making the patch misbehave elsewhere. Don't get confused by misinformation on "how bad Max's metro is" online - there are a lot of people who happily repeat something they've heard that goes back to pre Max 5. Metro was overhauled several Max versions ago.
Can it be confirmed that I have this wired correctly then? Should this work the way I want it to?
What should work ?
Post the patch so that one can see what could be wrong,
It is no help at all to watch videos.
The patch is posted in the opening post... I thought that's what you edited to post your screenshot. Nothing has changed. That patch is making metro stop sending bangs as shown in my video. I want to know if it's because I wired it wrong, because if it's correct, I need to open a bug report.
I corrected your patch only to make metro start, stop and reset
correctly.
Your original patch has double notes on every start etc.
That hickups are not caused by metro, but by some other things you do.
Make new live set, load only that metro patch, don't drive anything with it, just let it run.
Than report if you still have problems.
alright, I'll try this. Thanks for your help btw, this is very frustrating.
I rebuilt the patch from scratch making sure I only used screenshots so that everything would be fresh. I'm testing by leaving it to record midi output for long stretches of time. So far, so good. It still misbehaves if max is open. Hoping the problem doesn't return.
I wish I understood what was causing it, but thanks again.
Alright, here is my current patch, remade from scratch in a new Live session with nothing else in it. Metro is still randomly stopping.
It started dropping after about 12 minutes of continuous use this time.
Edit: on reload, it's stopping after the first loop.
Assuming the patch should work, should my next step be a bug report?
I’ve noticed some similar behavior recently. . Metro will occasionally stop or attached counters will start outputting random numbers. For me everything works fine in session view though, no problems at all until I switch to arrangement.
At least it's not just me then. I work almost exclusively in arrangement though.
It only started happening to me in the last few days, I’d be surprised if it wasn’t a recent update bug. I’m sure it’ll get sorted out.
Set up a full bug report, hopefully it'll help. I think I updated recently (before it started) so ideally it's just a bug in the latest version.
metro is only one of several objects that can produce bangs quantized to live transport.
you could replace it with plugphasor~ and rate~ for example , and use
gate to pass bangs on note on.
running exactly this in parallel will tell you if metro is really buggy.
With exactly this I mean don't hang any other objects to it.
I believe I will have to go this way just to get back to making the patch, thanks for the example, makes sense.
Finally set up your example Source Audio, and I am indeed receiving smooth counts from plugphasor vs inconsistent results from metro. Someone reached out to me with their bug report from a few versions back with the same issue; specifically metro breaking while ableton is in arrangement view and looping, so I'm wondering if that made it into the newest version. I'm testing it and have a ticket open now. Thanks again for explaining how to convert a phasor to bangs!