[Feature request] Filter clock cues from MIDI

[xorik]

Hi.

I've using launchkey mini controller, and it sends hundreds of clock messages every minute (few per second), so I cannot see any useful messages, and I cannot scroll either (because it jumps to end when new message appears, at it happened continuously).

Demo: https://youtu.be/fOXDevv9Gac

So I have to disable the cue log, because it unusable and takes a lot of CPU.

Can I filter those messages anyhow?

Thank you

[samaaron]

Hi @xorik - unfortunately we don't yet have any options for filtering the queue messages at this point.

However, it's definitely something we need and I hope to be able to work on it soon.

[llloret]

I have added an issue to sp_midi to track this. Perhaps we can filter at the low level? Guess we can discuss this once the beta is done.

[samaaron]

@llloret yep, there are four places we could potentially filter this:

1. In the GUI (just that they don't show up in the log, but are registered in the cue system)
2. In the Ruby cue system
3. In the Erlang layer
4. In the sp_midi layer

I'm currently leaning towards just filtering it out at the Erlang layer. It would be prudent to do some performance tests, but I'm pretty sure sp_midi -> Erlang can easily handle these messages.

On a side note, ultimately it will be nice to be able to tell sp_midi which ports we should connect to and which not to (currently it connects to all available ports). Perhaps if this API is added, we could also add an ability to toggle MIDI clock messages.

[xorik]

Thanks, guys! I've added a video to demonstrate the problem

[samaaron]

@xorik thanks for the video - I also have a device that always sends MIDI clock messages and am also similarly annoyed by it. This is also a problem for large amounts incoming OSC messages and also lots of live loops generating cues.

As it currently is implemented both the cue log and the print log in the GUI only work for small volumes of messages. As soon as lots of things start happening then both logs look pretty but take a huge amount of CPU (it's crazy how expensive printing text seems to be?!) and are completely useless for figuring out what's going on :-)

[samaaron]

If anyone has any ideas/sketches/thoughts about what an interface for filtering arbitrary cue messages might look like then I'd love to hear.

Currently I think we need some sort of list of patterns to ignore - likely to be OSC pattern matches such as:

/midi*/clock

[xorik]

Yes, just list of patterns is more than enough! E.g. multi-line editor with one rule per line.
Or just a checkbox to hide the clock cues.
Or just hide them silently, nobody cares about clock cues :)

Thanks a lot

P.S. on a side note: some time ago I added a simple waveform render in another QT opensource project (mixxx), and it's crazy slow, if you need real-time. Even now my 2 y.o. macbook struggles to run that code with smooth frame rate.