Just got my Axoloti board (Yeah !!)
I just tried it with the Linnstrument and I'm getting a lot of clicks and issues with it. I guess the Linnstrument's data rate via Axolotl's host port is too high....
Using the latest firmware of the Linnstrument I can decrease the data rate which seems to help but it's still not 100% reliable. Any other things I could change to help out ? (I tried both MPE examples)
Thanks !
51%
I'm using the mpe/simple.axp example.
If I set the Linnstrument to it's default data rate, nothing seems to be sent/processed.
At 512ms (the highest settings) it seems to work decently.
At 51% dsp load there should be plenty cpu time left to process incoming midi.
The setting you adjusted, is that this one?
Hold MIDI I/O to view the delay time (in microseconds) that is added
between sent MIDI bytes. Swipe left or right to change the value.
Default is 0 (no delay). As a point of reference, a value of 300 slows
it down to the speed of the MIDI jacks, and a value of 600 slows it down
to half the speed of the MIDI jacks.This is confusing me, usb-midi does not transmit individual bytes like din midi does.
It is difficult to understand what is going on, I do not have a linnstrument available. Could you maybe share a video or sound recording of the clicks you're getting?
Yup, that's the setting I'm changing.
Here are 2 videos, the first one is with the Strings patch and the second one is with MPE simple. Problem seems to be either no notes, stuck notes or chords playing.
Thanks for the video. It looks like the linnstrument is overflowing the usb-host-midi input buffer. I haven't seen midi input overflows, but I do not have access to any polyphonic expression controller.
It would be interesting to eliminate inefficience of the midi handling through the Axoloti USB host port: Could you record some MIDI with your computer from your linnstrument (without axoloti involved), and then play it back from your computer to Axoloti through the Axoloti USB MIDI device?
@johannes
I did some tests, I recorded the Linnstrument's MIDI in reaper and played it back on the Axolotl and it works fine. I also tried piping the midi from the linnstrument to the axolotl in Max/MSP (using a midiin --> midiout) and it also works without adding latency. So it seems like the problem is specifically with the host port.
Let me know if I can help with more tests !
Sorry, Im taking a break from forums etc to focus more on music making 
yes, the issue will be the 'usb host firmware' , and there are a few potential places it could be failing.
the first step would be to use the latest version of the firmware, either by it being released by Johannes, or by compiling it from source from github. Ive made quite a few changes in it, and since its been a long time since the last release, Im a little unsure what is it 1.0.3 and what is not.
(EDIT: seems 1.04 is released, so you can try that first)
one thing it will do is give a little more info about the usb interface which possibly will hint at the issue. but you could also get this if you connected your linnstrument to linux and used 'lsusb'. In particular id need to see the interfaces it presents, and the size of the buffers.
my suspicion is, its down to the frequency of the data... as with the soundplane/eigenharp I came in though the usb device via the mac.
most likely (randomly without seeing any info) is
the input buffer size of the linnstrument exceeds the max we allow, this is a simple define to change, but causes an issue if its too big since its statically allocated, and so reduces memory for everyone. (default 64 bytes)
polling, there is a minimum polling time, can't remember default off top of my head (possibly 1ms?), this may not be fast enough.
(this is where the interface description will help diagnose the issue)
as such I don't think there is anything wrong with the usb host code, just its not configured for this much and frequent data. its pretty easy to change its in usbh_midi_core.c/h
(the other possible issue, but I doubt is threading between the host port and the control thread, unlikely and a more tricky thing to solve especially without introducing latency and more memory overhead)
unfortunately, I can't connect my eigenharp or soundplane directly (and even if I could they use iso transfers and not midi... a smart move!) so can't generate the amount of data required to test the above with, so think you will have to 'give it a go'
hope this gives you something to go on.
Thanks, I'll try connecting it to Linux to see the buffer sizes.
I'll also have a look at the Linnstrument's code (since it's open source) to see if the buffers are defined there.
@thetechnobear
here's the output of lsusb, let me know if I can provide more info...
http://pastie.org/10549756
Thanks !
@thetechnobear
Hi Mark,
Just tried tonight with 1.04 and it actually seems worse than with 1.03. With the Linnstruments at 512 microseconds I seem to get strange notes triggering, seemed better with 1.03.
Let me know what kind of debug I can do !
Thanks !
Edit: It seems that if I set the linnstrument to 512 then press the live button it doesn't glitch, but within the same session if I change de linnstrument's delay then it'll start glitching until I toggle the live button again.
Here's the output of the Axolotl window:
USB device found
connected
Authentic Axoloti Core
Axoloti says: USB Device Attached
Axoloti says: PID: 69h
Axoloti says: VID: F055h
Axoloti says: Address (#1) assigned.
Axoloti says: Manufacturer : Roger Linn Design
Axoloti says: Product : LinnStrument MIDI
Axoloti says: Serial Number : N/A
Axoloti says: Enumeration done.
Axoloti says: This device has only 1 configuration.
Axoloti says: Default configuration set.
Axoloti says: Switching to Interface (#1)
Axoloti says: Class : 1h
Axoloti says: SubClass : 3h
Axoloti says: Protocol : 0h
Axoloti says: fakemalloc: already taken...
Axoloti says: USB Host Output size requests : 40
Axoloti says: USB Host Input size requests : 40
Axoloti says: USB Host Output connected to 1 : 1
Axoloti says: USB Host Input connected to 1 : 82
Axoloti says: MID class started.
Firmware version: 1.0.0.1, crc=0xA4AA9FE1, entrypoint=0x20011000
Generate code complete
Start compiling patch
Compiling patch... with /Applications/Axoloti.app/Contents/Java/firmware
BDIR = /Users/Nat/Documents/axoloti/build
FIRMWARE = .
RM
rm -f /Users/Nat/Documents/axoloti/build/xpatch.o /Users/Nat/Documents/axoloti/build/xpatch.elf /Users/Nat/Documents/axoloti/build/xpatch.bin /Users/Nat/Documents/axoloti/build/xpatch.d /Users/Nat/Documents/axoloti/build/xpatch.map /Users/Nat/Documents/axoloti/build/xpatch.lst
APP
arm-none-eabi-g++ -nostdlib -fno-exceptions -fno-rtti -mcpu=cortex-m4 -O3 -fomit-frame-pointer -falign-functions=16 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -Wunused-parameter -DCORTEX_USE_FPU=TRUE -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -mthumb -DTHUMB -std=c++11 -DARM_MATH_CM4 -D__FPU_PRESENT -H -I/Applications/Axoloti.app/Contents/Java/CMSIS/Include -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/common/ARMCMx/CMSIS/include -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/common/ARMCMx -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/GCC/ARMCMx -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/GCC/ARMCMx/STM32F4xx -I/Applications/Axoloti.app/Contents/Java/chibios/os/kernel/include -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/include -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32F4xx -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/GPIOv2 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/I2Cv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/OTGv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/RTCv2 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/SPIv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/TIMv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/USARTv1 -I/Applications/Axoloti.app/Contents/Java/chibios/boards/ST_STM32F4_DISCOVERY -I/Applications/Axoloti.app/Contents/Java/chibios/ext/fatfs/src -I. -Winvalid-pch -MD -MP --include /Users/Nat/Documents/axoloti/build/xpatch.h -c /Users/Nat/Documents/axoloti/build/xpatch.cpp -o /Users/Nat/Documents/axoloti/build/xpatch.o
! /Users/Nat/Documents/axoloti/build/xpatch.h.gch
LINK
arm-none-eabi-gcc -nostartfiles -Tramlink.ld -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mthumb -mno-thumb-interwork /Users/Nat/Documents/axoloti/build/xpatch.o -Wl,-Map=/Users/Nat/Documents/axoloti/build/xpatch.map,--cref,--just-symbols=./build/axoloti.elf -o /Users/Nat/Documents/axoloti/build/xpatch.elf
BIN
arm-none-eabi-objcopy -O binary /Users/Nat/Documents/axoloti/build/xpatch.elf /Users/Nat/Documents/axoloti/build/xpatch.bin
Done compiling patch
Start uploading patch
bin path: /Users/Nat/Documents/axoloti/build/xpatch.bin
block uploaded @ 0x20011000 length 12044
Done uploading patch
Start starting patch
Done starting patch
Start locking
Done lockinghmm, 1.03 to 1.04.. I quickly looked over changes, nothing really stood out that should make it worst, as it appears my changes were related to midi output.. not too surprising as I was stabilising the work I was doing on the Push 1 display which was causing me issues...
console, nothing unexpected there... correctly picked up sizes,
one slight oddity, is that it uses endpoints 1 and 82 , usually you would expect 1 and 81... but this is consistent with your lsusb output, so just a bit strange, and the axoloti firmware doesn't care.
another oddity, is you should be getting a line with host interval e.g.
USB Host Input interval : 0
the only reason this 'concerns' me, is i wonder if this means your not getting other logging.
anyways no matter....
the way to proceed is to build a new firmware....
you can either do this by using a github build
OR
by copying the firmware source (you will find it inside the axoloti app) to a new (writeable) directory
then changing the preferences to point to this directory
you will then find new menu options for flashing 'user firmware'
compile it, and check it works first...
then in usbh_conf.h you will find USBH_DEBUG_LEVEL, change this to 3 (from 2)
this will log more info.
In particular I think we are interested in seeing if the usb goes into a 'unusual state' that perhaps its not recovering from.
(it should be relatively obvious from the console when you get errors)
try running this, but send as little data as possible, as too much logging WILL break the connection.
basically the watchdog will terminate as it takes too much time to do the login. this is NOT an error condition...
you can comment out a few of the USBH_DbgLog lines in usbh_midi_core.c, if this proves difficult/excessive, but i think for input its ok.
the other thing to try
in usbh_midi_core.c. change MIDI_MIN_READ_POLL to 0, this will mean it will process messages every time chibios wakes it up.... Im not sure what this will do to overall performance, so initially test with a simple patch, and again initially try to not send too much data...
have a go with this, and see if this gives us some more info
@thetechnobear
I pulled the sources from Github and pointed to the firmware folder in Axoloti's preferences. I compiled and uploaded a new firmware.
Whenever I try to press the live button I get this error:
Generate code complete
Start compiling patch
Compiling patch... with /Users/Nat/Source/axoloti/firmware
BDIR = /Users/Nat/Documents/axoloti/build
FIRMWARE = .
RM
rm -f /Users/Nat/Documents/axoloti/build/xpatch.o /Users/Nat/Documents/axoloti/build/xpatch.elf /Users/Nat/Documents/axoloti/build/xpatch.bin /Users/Nat/Documents/axoloti/build/xpatch.d /Users/Nat/Documents/axoloti/build/xpatch.map /Users/Nat/Documents/axoloti/build/xpatch.lst
APP
arm-none-eabi-g++ -nostdlib -fno-exceptions -fno-rtti -mcpu=cortex-m4 -O3 -fomit-frame-pointer -falign-functions=16 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -Wunused-parameter -DCORTEX_USE_FPU=TRUE -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -mthumb -DTHUMB -std=c++11 -DARM_MATH_CM4 -D__FPU_PRESENT -H -I/Applications/Axoloti.app/Contents/Java/CMSIS/Include -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/common/ARMCMx/CMSIS/include -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/common/ARMCMx -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/GCC/ARMCMx -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/GCC/ARMCMx/STM32F4xx -I/Applications/Axoloti.app/Contents/Java/chibios/os/kernel/include -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/include -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32F4xx -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/GPIOv2 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/I2Cv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/OTGv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/RTCv2 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/SPIv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/TIMv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/USARTv1 -I/Applications/Axoloti.app/Contents/Java/chibios/boards/ST_STM32F4_DISCOVERY -I/Applications/Axoloti.app/Contents/Java/chibios/ext/fatfs/src -I. -I/Applications/Axoloti.app/Contents/Java/chibios -Winvalid-pch -MD -MP --include /Users/Nat/Documents/axoloti/build/xpatch.h -c /Users/Nat/Documents/axoloti/build/xpatch.cpp -o /Users/Nat/Documents/axoloti/build/xpatch.o
! /Users/Nat/Documents/axoloti/build/xpatch.h.gch
/Users/Nat/Documents/axoloti/build/xpatch.cpp: In member function 'void rootc::instancesimple__v__1::Init(rootc*)':
/Users/Nat/Documents/axoloti/build/xpatch.cpp:862:32: error: 'struct PExModulationTarget_t' has no member named 'PEx'
PExModulationSources[i][j].PEx = 0;
^
/Users/Nat/Documents/axoloti/build/xpatch.cpp: In member function 'void rootc::Init()':
/Users/Nat/Documents/axoloti/build/xpatch.cpp:1392:32: error: 'struct PExModulationTarget_t' has no member named 'PEx'
PExModulationSources[i][j].PEx = 0;
^
make: *** [/Users/Nat/Documents/axoloti/build/xpatch.bin] Error 1
shell task failed, exit value: 2
Compiling patch failed ( /Applications/Axoloti.app/Contents/Java/patches/demos/synth/mpe/simple.axp )Any ideas ?
(In the meantime I tried the same thing by copying the firmware from the 1.04 release and it doesn't do the error, I assume the error comes from the fact some files are newer on github...)
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...
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:
This time sound can be heard from axoloti.
I also tried changing
#define MIDI_MIN_POLL 3to
#define MIDI_MIN_POLL 0But 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...
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.