Of course I missed the obvious, sorry for that! In my defense I can only say that my mouse is getting old and jums around sometimes, what drives me crazy, I probably moved the filer from another line accidentlally, and I didn’t noice that the filter is also blocking the clock. I was making too many updates of my old patch with the new feautres, I guess I need some rest. Apologies for the noise!
One more thing to note - if you manage to reproduce the high cpu usage, please try and click the Disconnect button - see if it makes the CPU usage go down. Then see if reconnecting goes to the same usage levels.
Highly likely as % dropped just when I turned KS37 arp off
(being a peasant, I have no idea how much is due to the arp processing and how much just the QT monitor display update – I think I’ll try unfiltering Clock monitoring and watching the % change)
I’m not overly concerned as this…
…is what a post-Covid Mac looks like
(mine’s not just pre-Brexit, it’s pre-Maidan!)
Started with newly restarted Mac (just BBEdit, Terminal, Chrome & MIDI Patchbay running)
Observations & hunches
No significant difference between 1.14 & 1.13 so in terms of Beta: “nothing to see here, move on”!
Disconnect/Reconnect not relevant but what is …
…is demands being made of (I guess) QT when Editor visible:
selecting a pipe with Monitor flow will crank CPU >20 <30†
no pipe selected drops to 4<CPU<6
hiding → <1
(resizing to make both monitors visible cranks briefly > 50)
† CPU~23 before Firefox, CPU~29 after (Interestingly, restarting Firefox to report back had them both up into the 90s whilst typing this making typing laggy. Again fell to <1 on Firefox Hide Others. Apparently QT doesn’t like Firefox Isolate Web Content…)
Verdict: 1.14 OK, Mac ploddy as f**k!
won’t be offended if you delete this or move it to a new Why you need to Upgrade your Computer thread
I’m not sure if it’s my windows 10 computer because it has its own issues but I noticed when I have clock messages for too long in the midi monitor I get massive cpu usage from the editor and it slows to a crawl. Closing the editor fixes the cpu spike and when I turn off clock messages in the midi monitor I don’t have the issue anymore. I have an old 3.2 ghz amd cpu and 16 gbs of memory.
I also had a few freezes and had to close the editor from the task manager. The only freeze I have is when the clock messages are being populated in the midi monitor. I had some overflow loops and those messages didn’t seem to cause a spike, although I caught the overflow after a few minutes vs 10-15 minutes of clock messages.
Ok I see. The clock shoots off a massive stream of messages in quite a short time. I can understand how that can cause hiccups. Best to be wary of having clock messages on in the midi monitor then I suppose.
Thank you for the report, this is likely working by design - the beat monitoring on the LEDs react to the Start or Song Position Pointer message reaching the relevant output to reset/align its internal clock counter on which the blinks are based on. That also mean the receiving devices position in their sequences can also remain misaligned, so they should also be receiving a Start or SPP message.
I’m starting to think the BPM Clock pipe should also be possible to place in-line, like the CC LFO, in that case you would have full control over starting it with a Start message, and then making sure the Start message reaches the output, if that is desired, or dropping the Start message before it reaches the end using a Filter pipe.