ok, power on issue - interesting findings
tl;dr; I think its a corrupt midi stream.
when using a direct DIN connection.
is DIN and USB disabled on Osmose?
DIN is not working, even when used from above hardware device.
USB however is working still.
so its just disabling the DIN.
this one was interesting…
so I tried all combinations going via the mioXM.
ET (usb) → mioXM → Osmose (usb)
ET (din) → mioXM → Osmose (usb)
ET (usb) → mioXM → Osmose (din)
of course, I then noticed that Ive got sysex filtering turned on in the mioXM - doh.
so I turned off sysex filtering, so nothing is being filtered
and… drum roll…
ET (din) → mioXM → Osmose (din)
it still worked !
SO where are we , well, essentially the mioXM is just doing a pass thru on DIN now.
and it works fine, whereas a direct connection does not.
I have had similar experience before where the mioXM fixes things… even when acting as a pass-thru.
I believe the reason is, the mioXM is a ‘soft thru’ , it is interpreting every midi message and then re-broadcasting it. (it has to , as it can filter, go to multiple targets etc)
Ive noticed, before the stream is NOT identical to the stream out… ( * ) and this cleaned up stream seems to be more compatible, which could be the reason.
the other reason, is perhaps, the mioXM is a bit better at things like flow control… perhaps the ET is overflowing the input midi buffer on the Osmose, but the mioXM prevents this.
obviously it provides a solution for me (go via mio xm !), but it makes it difficult for me to track down the exact issue… and to know if its an ET/Osmose/Haken Engine issue.
ok, now to reassemble my setup… put cables back where they should go!
testing is such a mess!
( * ) there is a notion of ‘running’ (?) messages in midi, which allows you to reduce the amount of data transmitted in the case to sending the same CC consecutively … it was used extensive for midi din, with its limited bandwidth, but does not buy you anything over USB (USB MIDI uses fixed 4 byte packets)
what Ive noticed in the past is the mioXM will convert these running message into ‘standard’ 2 byte packets… this can help with some devices that don’t support this running message.
so it could be this the source of the issue during startup.