This topic is just a migration of the small number of minor issues uncovered thus far from Beta 1.14.0
I have included a couple of things raised that transpired to be non-issues (or performance issues not particular to 1.14.0)
Hopefully this leaves the main topic less cluttered
For anyone who’s been following the main topic, you can skip entries 2-18!
Just asking, did you also update the firmware? I was having similar issues until I realized that I not only had to update the editor but also the firmware.
@Giedrius
1.14.0 CPU Usage Observation
After looking @Unroot’s Timed Chance thing I need to close down FFox cos it was hogging memory on my antiquated Mac.
I then noticed Editor was using a lot of CPU (highest seen 69%)
Partly to do with fact that KS37 was still streaming 1/4 notes
using same set up on my 1.13.2 Midihub the difference is significant.
PS. @Unroot Artur if you are using a Mac what sort of figs is Activity Monitor showing when you’re doing this (I’m running at 120BPM )
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! 
Midihub Editor takes 0,3% of CPU on M1, nothing worrying.
Thanks,
is that when the KS arp is running too?
Can you consistently reproduce this CPU usage? 
What I’ll do later today is
I suspect it’s partly the old beast getting constipated…
(Both instances are down at a more familiar 0.1% now that everything’s off)
…I was more intrigued by the delta tween 13 & 14
Thank you!
Skip this one, as it will add some more % to the CPU line. 
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!)
Finally stopped being distracted for 10mins.
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.
This with 1.14 Joey or with 1.13 too?
I have an old 3.2 ghz amd cpu and 16 gbs of memory
Such power!
1.14. I didn’t seem to have this issue with 1.13 or at least I didn’t notice it because I usually have clock messages off.
The event count in MIDI monitor is currently unlimited - it’s not optimized for huge amounts of events.
If this is something that a lot of users hit, we’ll optimize it for that, but it’s also sort of conveniently avoidable by deselecting the pipe or filtering out the spammy 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.
Transform: Set Channel to property:
From {Transport} Set Channel to options incorrect
Not what I’d call a bug, more just “dotting 'i’s & crossing 't’s”
E.g. Start → Control Change:
Incoming Channel is available even tho none such exists:
It can be selected…
…but everything corrects itself when the combobox “loses focus”:
your alpha-tester should have picked this up, I’ll have a word…
hi threre
if i make e.g. 4 CLOCK pipes to MIDIOUT A,B,C,D
and all four are set to react to STOP/START from MIDI IN A
if i send START to MIDI IN A ,the lights A,B,C,D blink at the same rate but do not blink at the same moment,
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.
