ok, so I tested with my Eigenharp... and no issues, even when I started sending all data as 14 bit , no decimation.
(thats a lot of data, in fact, I had to send 6 parameters per note, without decimation, to start seeing ring buffer overflows )
BUT.... I realised my test was flawed ...
the issue, in the above test, is Im not receiving data on the usb host port
on both axoloti 1 & 2, I was receiving the data on the device port, and only writing to the host port. (ok, it succeeded well at that)
i.e.
Soundplane/Eigenharp -> Mac -> A1 (midithru dev to host) -> A2 (synth (dev!) ,midiled (dev))
but with the linnstrument, you are receiving data from the linnstrument on the host port, and thats where we believe the problem lies. (ok the code is kind of related, but still, not a good enough test!)
so here was my new test..
(and here, you have to congratulate @johannes at how good this board is, I have to say I'm amazed this worked!)
- Mac connected to Axoloti 1 (device port)
- Axoloti 1 has a midithru, from device port to host port 1
- Axoloti 2 (device port) connected to Axoloti 1 (host port) , runs a midithru, from device to host port
- Axoloti 1, has the mpe synth patch running (as well!) which is only responding on the HOST PORT, and a midiled on host port (i.e. showing received data from Axoloti 2)
i.e.
Soundplane/Eigenharp -> Mac -> A1 (midithru dev to host) -> A2 (midithru with led (dev to host) ) -> A1 (synth (host) ,midiled (host))
and... it works
again, works with both eigenharp and soundplane, at no decimation levels, no perceivable latency.
Im impressed... axoloti 1 is having to receive all that midi data twice, send it once, and also run the mpe synth, with 8 voices, and its still only registering 51% CPU
(btw, yes, I changed settings (e.g. removing routings...) to ensure the axoloti 1 patch wasn't cheating me by taking the data directly )
what does this prove?
Axoloti is awesome, and 2 Axolotis are better still... truely the swiss army knife of midi