Midi Beat Clock 0xF8 being forwarded from MIDI In to Out

[dimitre]

Hello, I've been using this library and I think it is forwarding midi beat clock message from midi in to midi out. As I'm using the same device in midi in / out I'm getting a kind of feedback loop.
Is there some way of turning this off?
Thank you

[designerfuzzi]

Clock signals 0xF8 are meant to pass but if your circuit is treating the received midi messages with the library before sending out again you have to filter them your self. Otherwise you will allways have cycles and typical passed signals would produce panic (fill up the buffer ending in unexpected behaviour).
Specially when you send to and receive from the same midi device connected. So set your midi callback so it can handle it. There is no library switch as i know.
The other way around is blocking pass thru on your midi device but as you connected it so you want to receive and send.. ergo you are programming a filter and there for your code is responsible to handle the signal cycles. The logic in yoyr receiver code will have to know what was send out to filter the feedback. Dont forget even if connected that way there will be latency, so dont expect incoming feedback arriving early to compare them tick per tick.

[franky47]

@designerfuzzi is correct, at the moment there is no "smart thru" that allows per-type filtering, only channel-based messages (to avoid sending messages to the wrong device).

Such a feature was proposed in #40.

[dimitre]

It would be great at least to disable it via some #define directive.
Thanks

[designerfuzzi]

The serial-buffer is not send out by default. Its just a buffer where you decide when to read and process data from with your callbacks. Not difficult to handle once you read about in the wiki under Callbacks.
Of course you can fall in the mistaken trap to send the serialbuffer out again with some amazing code or you did wire up your RX and TX with each other in a direct way in fact shorten your circuit.
The often mentioned latency is happening (existing) because the reading and sending plus processing of the buffers needs cpu-clock-cycles/time. If those buffers would be directly connected by default, that would be a huge mistake by design first and second with much much less latency. The effect would be your circuitry would just stop/freeze when you start it or doing nothing. Which is as far i read about your troubles not the case. So it may be a good idea to look into your hand crafted source code if there is a sorting problem of the commands or similar.
Before you loop:
Setup midi,
setup the callbacks to process the serial input buffer with, where for all major midi data types there is a specific callback existing.. so you could even set a callback doing nothing when called

In the loop:
Call midi.read as often you want
You react with your logic and send midi out

Finally you can unset the callbacks or /and stop midi or repeat the loop