Linnstrument + Axoloti first tests

#18

If you use code from git, use both the GUI and firmware. The error you are seeing is the result of a change in the interface between gui and firmware.

But it may generate an IRQ storm.
I do recall needing to modify the ST USB host code long time ago, because it was causing an IRQ storm out of the box, resulting in choppy audio performance.
But this is just a wild guess.

Polling time may be relevant. But I'd hope Linnstrument to accumulate multiple midi commands into one transaction if it isn't polled as frequently as it requested.

Logging USB with a USB analyzer between Linnstrument and axoloti would reveal a lot, but I have no Linnstrument...

#19

Here's the result of the output with more debugging. This is at Linnstrument's default setting of 0 microseconds between each message. I tapped a pad quickly 3 times:
http://pastie.org/10557257

No sound was audible from Axoloti.

Here's the same test at 512 microseconds with 3 taps on the same pad:

http://pastie.org/10557259

This time sound can be heard from axoloti.

I also tried changing 

#define MIDI_MIN_POLL 3

to

#define MIDI_MIN_POLL 0

But I can't seem to see any difference.

Let me know if this can help, otherwise I'll be glad to run more complicated tests...

#20

Has there been any progress on this issue? I have a LinnStrument and a couple of Axoloti boards, and I would love to be able to use them together.

#21

No updates. You can still use Axoloti with Linnstrument just fine, you'll just need to increase the delay between midi messages on the Linnstrument to 512.

#22

sorry, didnt notice your reply...

ok, the note-on/off are missing, and also CC messages....
there is also nothing in the log messages, indicating an error, though I'm not sure what debug messages you have enabled... as mentioned in my email you could start enabling some of the Dbg messages to see if it becomes clearer what is going on , in particular the code that shows STALL states etc.

i dont really know what else to look at.... without being able to see put some test code in, and see what is going on its pretty much impossible to isolate the cause.

(as a further/unrelated issue, Ive just trade my push 1 in for a push 2... so I now dont really have a suitable usb device to test with axoloti until i get that working... currently there is an issue with axoloti not even detecting the push2 midi interface, and also it complains its not USB 2.0)

#23

@natcl & @alexk and any other linnstrument owners out there...

I had an idea on how to test this 'issue' with two much data over the axoloti USB host input....

In the user library, you will see Ive created a midithru object, which can move midi message from a designated input to output.

so I did the following was a test...

  • Soundplane sending MPE (at 500hz) on my Mac, sending midi to Axoloti 1.
  • Axoloti 1 connected to the Mac, running the midithru object, from USB device port to USB host port 1 (Axoloti 2)
  • Axoloti 2 connected to Axoloti 1, running mpe/simple synth (and a midled object, so i can see midi activity)

and, you've probably already guessed the result....

it works absolutely fine, I cannot perceive any latency... I dont get any missing notes, and cannot here any discontinuity in sound.

so now I'm confused why the linnstrument is having issues... as its appears Axoloti (#2 in the this case) can handle the midi mpe data at 500hZ.

obviously the important thing here, is how axoloti 1, may or may not be interfering with the test.
(I dont think it does, I think the test is valid)

some notes on axoloti, particularly relevant to my midi thru here :

  • does not throttle data
  • the device and host port are handled on different threads.
  • the midi out is sent through a ring buffer, if it overflows (so would lose messages) it reports ring buffer overflow, no such error is occurring
  • midi input is handled immediately, not on the make k-rate... though even if it did, it would still be a 3000hz, so much faster than controller data.

@johannes , can you think of anything that might invalidate this test?

Its a puzzle... I was actually hoping the test would fail, as this would give me some way of testing the usb host code at high data rates, and so a way to resolve the issue.

( I guess, I'll test with the Eigenharp as the sensors run at 2kHZ, over double the Soundplane and Linnstrument, and I believe EigenD will send out at that rate, unless its told to decimate the data)

USB Midi Controllers
#24

@thetechnobear thanks for the tests. I'll test this myself tonight, I also have 2 axolotis. Also there was a recent firmware update (1.2.4) for the linnstrument, will see if it helps in any way and report back !

#25

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 :frowning:
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 :zap: :boom: :tada: :beers:

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 :wink:)

what does this prove?

Axoloti is awesome, and 2 Axolotis are better still... truely the swiss army knife of midi :cow2:

Usb host midi output ringbuffer overflow?
#26

I hadn't had the chance to test my Linnstrument yet.
That's worrying though because It seems like the issue could come from the Linnstrument. If so I'll have to try to poke Geert about it but he's a pretty busy man... From what I understand also the specific USB MIDI part of the firmware is not Open and is controlled by someone else which might complicate things...

#27

no issue, test when you get an opportunity.

btw: can you confirm you are not bus powering the Linnstrument.
(its important, at this stage we eliminate power as an issue)

oh, I think its too early days to say that, something like 600+ Linnstruments are out there, talking to PC/Mac and other devices, so thats a good indications it acting 'as expected'. Frankly, we don't really anything to give Geert for him to look into.

Im sure its probably is load related, as I don't know of any other midi controller with issues with Axoloti, thats why Id hope this would have exposed it, but perhaps theres some other timing thing going on.

another interesting to test might be to try to do a test with something like iConnectMidi?
( I think iConnectMIDI can be both a device and host , no?)

@keyman have you tried your continuum with MPE with axoloti yet? (assuming the firmware was released)
perhaps trying it continuum din -> iconnnectmidi -> usb -> axoloti , might yield something interesting.

I'll ping Geert, see what he thinks, but I suspect the only way we will get more info beyond the above, is by debugging Axoloti with a Linnstrument attached.

#28

Sniffing the usb-midi data with a USB protocol analyzer between Axoloti and a Linnstrument could help providing more insights. I have a Beagle USB 12 analyzer, but no Linnstrument...

#29

Yes Continuum mpe firmware is out since after NAMM. Can't recall anything having issues Continuum>Axo.
I do recall issues with IConnectmidi being a device..I think...
There is also a new firmware out as of yesterday,

As always i'm following close by; havent use 1.0.9 that much yet :wink:

#30

I do have an iConnectAudio4 also, will add that in the test loop !

#31

Ive had a quick email exchange with Geert, he said he saw something similar with iOS, and hence the low power mode.

@natcl and @alexk did you try low power mode, or could you please try this and see if it helps.
preferably with it connected to a power supply, though I don't know if this is possible.
(apologies if you have already tried this, its hard to keep up sometimes :))

fyi: the low power mode spaces the individual bytes of the midi messages that are sent to the serial to USB MIDI chip within the Linnstrument.

#32

So I've made some tests this evening.

I can confirm that with firmware 1.2.4 on linnstrument and 1.0.9 on Axoloti, it works fine in Low power mode. If I attempt to use it in normal power mode I get the glitches. I tried the tests with the Linnstrument powered externally. In low power mode the Axoloti seems able to power the linnstrument just fine.
So for now this is totally acceptable for me, easier to go in low power mode than play with the USB micro delay manually...

#33

Geert pushed some fixes to the repo yesterday and was kind enough to send me a test build, good news, it fixed all the issues with Axoloti (and most probably other synths too).
From what I understand in some cases the Linnstrument would send incomplete midi messages.

Thanks Geert ! And thanks @thetechnobear for testing !

#34

oh thats excellent news... Geert is very responsive to these things, I wonder if it will also help the iOS platform too... he is a huge asset for the Linnstrument!

btw: you should try axoloti 1.0.10 too, @johannes has switch the axoloti over to using dma for the usb host, which could also improve performance.

anyway, sounds like you can start to have some real fun with axoloti now :slight_smile:

#35

Yes the tests I did yesterday were with 1.0.10

#36

for setting up the linnstrument use latest os for both axoloti and linnstrument.

use a the normal mpe mode:
1. channel per note
2. #74 cc y axis
3. channel pressure z axis

and:
1. x axis at linnstrument setting of 48.
2. at this moment run linnstrument in low power mode with usb delay setting of 0 or high power mode with usb delay setting of 300 on linnstrument (results may vary)
3. arpeggiator is unstable for use with axoloti at time of this posting. it works but notes are dropped.

the included library has an object from mark harris (technobear) that makes it easy to setup patches for linnstrument in the above mentioned way. there is an option on the object that allows you to select number of voices and this will maximize cpu overhead on the axoloti.

i have a few instances where some objects glitch some of the settings; the pitch bend range will get knocked into different ranges. if this happens, save your work often while patching and revert to a state where the pitch bend range is at the normal setting with the technobear mpe object.

linnstrument with axoloti recorded direct:

#37

glad you have it working, and nice example :slight_smile:

is this regardless of delay setting?
does the arp mode work in mpe mode? and does it send all note of the arp on the same channel, or does it distribute them across channels? (sorry I don't know what how mode is implemented on the linnstrument)
the current axoloti mpe implementation assumes one note at a time on a channel, since it directly connects to a voice, putting multiple notes on one channel, would mean you'd (potentially) need multiple voices per channel.
it could be done, but not something ive needed so far.... I guess because i dont have a linnstrument, and dont tend to use arps much :slight_smile: