Osmose - midi density?

Expressive-E Osmose
1

Has anyone else noticed the Osmose seems to have an issue with a high volume of MPE data?

its latency is ok, but its easy to overwhelm the midi data stream (with an appropriate controller).

so I was testing a new version of the Eigenharp software, and notice if I ‘strummed’ the Alpha keyboard quickly, lots of notes, lots of mpe data.

after I finished the strum, the Osmose would be still playing 2 seconds later !
i.e. was taking 2 seconds to catch up.

ok, this was not ‘normal’ use, if you play then it seems to be ‘ok’ , though I could provoke latency if I really tried.

even throttling didn’t seem to help much…

naturally, I assumed it was my software, even though Id need no real evidence elsewhere…

so,
a) I plugged in my Eagan Matrix Module, exact same setup, works perfectly…
no latency or backing up what so ever !

b) I recorded the MPE notes in Ableton.
perhaps the Eigenharp was bottlenecking?
nope, looked fine in Ableton, and again send that MPE stream to Osmose, and it backs up…

I also tried direct connecting osmose to Mac… in case hub was overloading, no difference…I also tried via usb->din , same issue.
(runs on the osmose keys are fine… so it feels like an interfacing issue)

it truly looks like the Osmose has some kind of buffer / bottleneck between the EM within the Osmose and the ports usb/din, that is somehow throttling the input.

odd, thing is… Im sure I tried this when I first got the Osmose, and don’t remember it - so perhaps a change in Osmose FW?
or off, its possible I didn’t to this exact same test, but it does feel like it’d be pretty noticeable!

anyone else with a similar experience?
note: you’ll need very high density to provoke

edit: sent an email to expressivee , not sure if they will be interested… as more complex setups are hard to ‘trust’, and it may be considered an ‘extreme’ use case.

1 Like
2

Yes (as written in the other thread), I also have to set decimation in EigenD to 20 or higher, otherwise fast arpeggios lead to noticable event queueing. Only tested with USB-MIDI on the Osmose side. I use Osmose firmware 2.1.21 and “haken version” 10.52.

1 Like
3

Glad to hear that the EMM is not, as yet, affected!

4

this is likely down to the SoC used by the Osmose for all the processing outside the EM. e.g. all the physical bits.
we know this also handles the USB → EM, as its also how the Osmose does its own custom preset handling.

so yeah, the continuum / emm likely have a different implementation.
its why I was keen to test the emm - id suspect continuums will be also ok.

just odd that Id not noticed before, it was pretty obvious, until you start throttling the data feed.

5

I have experienced the same by doing some slides on my linnstrument.
The setup is:
Linnstrument->PC->bitwig->hydrasynth
A basic fast octave slide ended up taking a minute.
But I then changed from bitwig to reaper and then everything works fine?
I suspect some software simply limit data rate to the original midi spec, even when midi over usb can be faster.

6

not applicable in this case,
a) I send directly from EigenD, so I know there is no such buffering going on (I dev for it)
b) I’m using USB, and the data rate would only be applicable for TRS/Din.

so, its def buffering on the Osmose side. and we know its not an EM limitation (on its input), as this is not present on the EMM (nor I suspect continuums etc).

btw: for a slide you should be able to improve this by using decimation, pretty sure Linnstrument supports this. it’ll possibly make it less smooth.
this is what we can do with Eigenharps.

(doesn’t solve situation for flooding with notes as it’s difficult to sensibly decimate notes, they dont related to the same ‘event’ unless, timbre/pressure/pb)

7

I know you develop for the eigenD so I’m not questioning that, rather the opposite as you have insight to what buffers and rates are in place. :slight_smile:

But in my test I was using USB as well both from the linnstrument and to the hydra.

And when having Bitwig in the middle, the data rate was limited, resulting in the slow slides. Reaper did not limit the data and just worked.

So, when you mentioned that you recorded the mpe data in Ableton. I just wonder if Ableton, as well as Bitwig have some sort of own data rate limit built in when sending out the data?

As using the exact same setup with Reaper with USB midi in/out I had no data limiting at all.

So, Osmose might very well have a problem with high data rate. But from my tests so does some DAWs.

1 Like
8

indeed, I would not rely on daws (on any ‘middle man’) without cross checking…
thats why I also not only checked with Osmose, but also the Eagen Matrix Module.

Im surprised that bitwig is throttling though, as a good chunk (majority?) of midi these days is usb, and bitwig were one of the first to have native mpe support. so Id expect them to recognise that many mpe controllers send a lot of data.

there’s another interesting side of midi though… so haken very much optimised the serial midi (din) protocol for the continuum, in particular around running states, and prioritising certain phase of a note (notable onset) .
they had to focus on this as they had their multi channel midi long before mpe and usb midi. and still they could ‘cope’.

unfortunately, modern daws dont care about this
partly because…
usb midi cannot do that, as all midi messages are sent as fixed 4 bytes packets - but ofc, with the massive bandwidth it had (even 1.0) this was not an issue.

but yeah, Id have thought modern daws were pretty agnostic about transport, and not make limiting assumptions based a slow/dated serial protocol (or at least made it optional)

1 Like
9

Hello
Sorry I’m late to the discussion. I did a try to drive the Osmose from a Slim Continuum (with a dedicated max/msp patch to do the MIDI Through), and didn’t notice any buffering when going via USB Port 2. Furthermore, this port is also used for the EaganMatrix firmware update that runs at MIDI full rate, so buffering issues would ruin the updates.
Are you facing this on USB Port 2 ?

10

Hi! For me only “Osmose Port 2” was reacting to midi messages. (On channel 1 in legacy mode that seems to use velocity for the start of the envelope and on other channels with per-channel CC and/or poly aftertouch). I tested mostly the channel 1 legacy approach (which showed the queueing effect) but can retest with the other channels (e.g. with Eigenharp).
Edit: Also did the test with Alpha and EigenD 3 in MPE mode on Osmose Port 2 with a Macbook, I have the same queueing effect there.
Could it be that the Continuum is already sufficiently decimating the events when it is not in MPE+ mode? With an EigenD decimation setting of “20” (of 100) or higher I also don’t get queueing anymore with the Alpha/EigenD.

11

It is decimating, but I was in MPE+ and with high polyphony… so the MIDI port was quite busy

12

Can send you a recording of an undecimated Alpha midi stream today afternoon. If you cannot reproduce it with this then perhaps my USB-B->USB-C adapter or the Macbook USB port is slower?

13

Here two files, played with Eigenharp through EigenD 3, one in MPE mode and one in channel 1 mode.
This was recorded with Geert’s receive midi tool (receivemidi dev “Eigenlabs 1” ts > outputfile.sendmidi)
It can be played back with sendmidi (sendmidi dev “Osmose Anschluss 2” outputfile.sendmidi)

The delay is obvious when playing it live on the Alpha (the last notes finish almost a second after the notes were played). But it can be tricky to hear this when just sending the sequence to the Osmose. One trick: Send it to the Osmose and a synth (e.g. Pianoteq) at the same time, then the delay becomes obvious again:

  • Enable “IAC-Treiber Bus 1” in the Audio-MIDI Setup (for Mac, for Windows install loopMIDI or another virtual MIDI cable solution).
  • set up the virtual midi cable as midi input in Pianoteq
  • configure a passthrough from the virtual midi cable to Osmose (e.g.: receivemidi dev “IAC-Treiber Bus 1” pass “Osmose Anschluss 2”)
  • send the midi sequence to the virtual midi cable (e.g. sendmidi dev “IAB-Treiber Bus 1” AlphaNoDecimationChannel1.sendmidi), then it should arrive at both devices. Now the delay becomes clearly audible
  • verify that the delay is Osmose related (and not e.g. the passthrough) by using another external synth instead of the Osmose.

Here the two sendmidi files:
Channel 1 (Legacy)
MPE

Best use a percussive Osmose preset with not too many effects.
Don’t use headphones particularly for the MPE file. Some Osmose presets get “a little” out of control, getting extremely loud.

Edit: The effect is much more pronounced when using the MPE recording (for these two files at least).

14

Thanks
SendMidi is not happy on my M3 mac for some reason …
I’ll retry later (busy evening and away tomorrow)

15

Also using it on an M3 Mac here :slight_smile: No hurry, have a nice evening!

Edit: sendmidi seems to react to typos in the input file name with silence instead of “file not found” or something :slight_smile:

16

Port 2

I don’t think osmose even excepts midi (except clock?) on usb port 1 !?

not really, we are not losing data…
it would just run a bit slower than is ‘possible’, from a user perspective I doubt you’d even notice it.

the key here is:
I ran exactly the same data stream, same setup into the EMM, and it did not exhibit the same behaviour… which is why I attribute it to the Osmose.

as for continuum vs eigenharp - they are different beasts…

John Lambert felt midi was holding back the industry, so Eigenharp uses a proprietary (isosynchronous) usb protocol, which basically is processed on (closed to ;)) real time priority threads on your desktop, its all full rate - because a lot of the time the data is staying within in process or via a virtual midi buses, or these days at audio rate via cv. none of this requires decimation.
add to that, that physically the keys are low travel.
the eigenharp can be a veritable fire hose of data.
SO, if you use external midi the user is expected to ‘manage’ this by decimating data (within EigenD) , as required.

IF the EMM had the same issue, Id have not even raised this…
this was more, hmm, why can the Osmose, using the same engine (actually 2x), not do the same?
almost a ‘technical query’ rather than a practical / musical problem :wink:
(as we can decimate data)

continuum, on the other hand, as you know better than I, was always midi focused… and in the early days Lippold did a huge amount of work shaping the midi - to over come its limitations.
it had to, as it was standalone, did not require / rely on a computer.

(that said, I expect you used 14 bit midi data, whereas, I used 7bit… 14 bit would like make it even worst?!)

different design, different choices.

17

you are right, when in the Osmose, the Egan Matrix does not receive directly the MIDI data flow: everything goes through the Osmose IO Board, and only what needs to go the the EaganMatrix goes to it (that’s why you have this Osmose MIDI configuration where you can decide what is sent to the EaganMatrix, and that will prevent the Haken Editor to run if it is configured to filter out the necessary data). Therefore the MIDI behaviour of the Osmose and Haken Audio products can be slightly different.

1 Like
18

yup, it has to do this for the preset storage etc, as its different.
however, I’d have hoped on the voice channels it would be basically a straight thru pipe (tiny buffer for timing only) . so, I was a little surprised there is this apparent discrepancy between what the Eagan Matrix board can receive (shown by EMM), and the IO board is able to send. which is why id assume its ‘falling behind’ slightly at high rates.

ofc, I know nothing about the SoC used for the IO board and its utilisation for other tasks, so it could just be a timing issue or some other ‘detail’ getting in the way.

also , I recognise that using the Osmose as a ‘sound board’ for other controllers is not a common use-case. I’m sure the Osmose mpe output, recorded in a daw, and replayed is well within the limits it has.
as I said, more a technical query / surprise than a issue/bug.

1 Like
19

From experience developing CHEM I found it’s easy to overwhelm an Osmose with MIDI input. It’s far more fragile than EM devices.

It does not tolerate MIDI input while a preset change is underway at all. Either the preset doesn’t change (best case) or the Osmose goes insane and requires a reboot. An EM device in the same scenario has no trouble, so it’s definitely on the Osmose side.

I tell my users to use only CHEM to change presets, because it knows to stop all MIDI until a change is complete. CHEM also has configuration to throttle the MIDI rate if necessary - so you have a tradeoff on how many parameters you drive, versus the rate. If slowed, you start to hear stepping.

2 Likes