Unexpected MIDI message transformations

Hi,

I first want to thank Blokas for their excellent service, the Midihub arrived within a week of my ordering it. Just unbelievable – rarely get that speed of delivery locally within Australia.

I’ve been experimenting with it in my home studio and guitar rig and predictably I’m hitting some early roadblocks in my knowledge which I’m hoping this community might be able to help me overcome. I’m asking here first given I’m using the Midihub but I expect I’ll have to follow up with the vendors (Boss, Strymon, et al)

I know it’s a big ask for anyone to read through all this but I was hoping the Midihub could become an essential and permanent piece of my guitar pedalboard (for live performance) and home studio. If anyone is at all interested, I’d be more than happy to share my written-up ideas and rationale for this project.

In the following simple example, the context is a Boss ES-8 Editor (running on a computer connected to a Focusrite PRO40) trying to connect to the ES-8 switcher/looper.

I’m monitoring at ‘TO ES-8’(as highlighted in the jpeg snapshot below).
ES-8 schema 01
(my 1st post to this forum so I don’t know if this Midihub screenshot will be visible - I hope so!)

To keep the monitor log ‘uncluttered’ I set the filter to filter out “Active Sensing”.
In the monitor output of ‘TO ES-8’ my understanding is that:
Incoming msg = what the filter is sending to ES-8 DIN Input
Outgoing msg = what is being received by the ES-8 DIN Input for processing

As a small sample of the event stream, the first few messages in the monitor output are:

Event Type Incoming Outgoing
Event SysEx f0 41 00 null
Event SysEx 41 00 00 SysEx 00 00 00
Event SysEx 00 14 12 SysEx 7f 12 7f

Q: In these three example messages from the ES-8 Editor, why is the Editor SysEx message either being changed or in some cases not being passed on to the ES-8? What could be changing the messages?

The second thing that has me puzzled involves MIDI channels.

  • I have set the ES-8 internally to receive only MIDI channel 16.
  • Because SysEx messages do not involve any MIDI channels I first thought it was impossible to insert a MIDI Channel Filter (as per the above Midihub schema) because then by definition the Filter would only pass on messages with specified channel(s) to the ES-8 and the SysEx messages wouldn’t get through.
  • Noting that everything works correctly without a Channel Filter.
  • My initial goal was to restrict messages to the ES-8 to those only on channel 16 because the ES-8 is very prone to buffer Overflow.
  • The very strange thing is that when I inserted a Channel Filter (as in the above Midihub schema) the Editor-ES-8 connection all works (SysEx getting through) and the Editor connects and retrieves all the ES-8 presets. The Filter can block all channels except channels 1,2,5,6,7, and 14. Without any one of these channels the connection isn’t made
  • So that’s a question I will have to ask Roland/Boss technical support.
  • Also very strange is that appearing in the ES-8 output to the Editor (the bottom Midihub pipe) are long sequences of Overflow events on channels 3,8 and 16, and random Overflow instances for Ch 2.
  • Another question for Roland/Boss technical support - how and why are they using MIDI channels 2, 3, 8 and 16 in the communications between the Editor and the ES-8?

Some random selections of events taken from the very long ES-8 Output Midihub monitor trace log:

Event Type Incoming Outgoing
Overflow null Ch. 3 CC 111 60
Overflow null SysEx 14 09 14
Overflow null Ch. 8 Aftertouch F#9 31
Overflow null Ch. 2 Note Off A-1 110
Overflow null Ch. 16 Aftertouch C-1 0
Event SysEx 2d 38 20 Reset
null null Unknown 20
null null Ch. 2 Note Off C#1 103
Event Ch. 2 Note Off B5 32 Ch. 2 Note Off A4 83
Event SysEx 00 00 00 Reset
null null Unknown 00
null null Unknown 76
null null Ch. 2 Pressure 0
Overflow null Unknown 79
null null SysEx f0 41 0f
Overflow null SysEx 00 00 00
Overflow null SysEx 00 12 00

Again, just repeating myself - even with these Overflow events happening and the Midihub Filter set as stated above, the Editor and ES-8 communicate ok. I just would like to understand what is happening.

You might be wondering why I’m exploring all this. One of my initial goals for using the Blokas Midihub is to enable many device editors to be running concurrently on the PC. I want to be able to create ES-8 loop presets and at the same time customize (say) Strymon Timeline “presets’ - and any other such pedals/devices - save them to the device and an editor library.

The ES-8 Output will also include footswitch MIDI messages for each of the ES-8 presets - each guitar FX pedal being set to a unique (specified by me) MIDI channel. For non-live performance the computer and the various Editors will be connected and running concurrently and I don’t want ES-8 Editor messages being sent to any of the looped pedals. I have a draft Midihub to achieve this which I thought would work but in light of all the above I may have to significantly revise my design. [Just noting that I’m seeing some similar MIDI strangeness with my Strymon Timeline - maybe this ES-8 situation will clarify that too.]

A big thank you in advance for any light thrown on these conundrums.

Pete

Hi @HazyPete, welcome to the community. :slight_smile:

The Channel Filter operates only with channel messages, it let’s the rest of the messages pass through. You can use regular Filter next to it to drop non-channel messages if necessary.

The Midihub always gives highest priority to actual work on the data coming through and sending to where it needs to go. The MIDI message monitoring has a low priority and has a limited area of memory to log the MIDI data which has to be read out by the host computer. If there’s more data than can fit and the computer is not able to read it out in time, an overflow event occurs. There might be some issue/bug in the MIDI monitor state machine after an overflow that can affect how it interprets the rest of the traffic going through (for example, it could be problematic missing a sysex start / end bytes), so it may provide some inaccurate data after an overflow occurred, if the resulting state is incorrect. This does not impact the actual communication and data processing though.

It should be possible to reset the MIDI monitor state machine by simply selecting any other pipe and then selecting the originally selected pipe.

As overflows are occurring and weird messages are getting logged in the MIDI monitor pane, it may make sense to actually forward the same data to the host computer, and have a MIDI monitor software log it, as sending it directly to the computer would have high enough priority not to loose any data, and then check for messages on various channels.

Hi Giedrius,
Thank you for your very quick reply. I’ll do some more sleuthing using a PC MIDI message monitor and will report back on progress.
Cheers,
Pete

1 Like