[Beta] Midihub 1.14.0 - Small Issues

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!

1 Like

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.

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.

(1.14.0 → PID 31703, 1.13.2 → PID 86493)
Let me know if you want me to do logged side-by-side runs

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! :zipper_mouth_face:

1 Like

Midihub Editor takes 0,3% of CPU on M1, nothing worrying.


is that when the KS arp is running too?

Can you consistently reproduce this CPU usage? :slight_smile:

What I’ll do later today is

  • do a Mac restart
  • run a LIBSERIALPORT_DEBUG for each of 1.14.0 & 1.13.2
  • keep an eye on Activity Monitor while I repeat the KS37 arp,
    and see whether what’s in focus on screen is relevant.

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. :smiley:

1 Like

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!
Screen Shot 2023-11-27 at 22.58.41

1 Like

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.

1 Like

The event count in MIDI monitor is currently unlimited - it’s not optimized for huge amounts of events. :slight_smile:

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.

1 Like

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.

1 Like

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:

Screen Shot 2023-11-28 at 17.05.49

Incoming Channel is available even tho none such exists:

Screen Shot 2023-11-28 at 17.05.22

It can be selected…
Screen Shot 2023-11-28 at 17.05.33

…but everything corrects itself when the combobox “loses focus”:
Screen Shot 2023-11-28 at 17.05.49

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,

1 Like

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.