Axolot disconnected when connecting midi usb device

#1

Hey, Yesterday i use my midi controller (launch control XL) , it work fines. But now, when i plug it, the axolot statut is "looping" in the statut Connect/disconnect/connect/disconnet etc..
The error message is :

:slight_smile:
java.lang.InterruptedException
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1315)
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1296)
at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1348)
at axoloti.USBBulkConnection.DistributeToDisplays(USBBulkConnection.java:1079)
at axoloti.USBBulkConnection.processByte(USBBulkConnection.java:1258)
at axoloti.USBBulkConnection$Receiver.run(USBBulkConnection.java:868)
at java.lang.Thread.run(Thread.java:748)

is there an answer about this ? thanks a lot !

#2

Welcome to the world of Axolotis midi implementation.

I have like 4 midi controllers from Launch series. Ans I have problems with ALL of them when I use them with Axoloti. I also use them with Pure Data and have absolutely no issue there, so I know it's not the controllers.

Sometimes they work a little bit and they next day they disconnect all the time, giving midi ringbuffer overflows, disconnects and what have we.

I think Axolotis midi code needs an update, it's not "safe" enough.

#3

Hey Jaffa ! I found a solution that resolve mine ! The fact is when i plus axolot through usb hub (unpowered) to my computer the issue comes BUT if i plug directly to an usb port of my computer, it's working. I think axolot didn't have any power to juice Himself AND launch series. maybe Try to use the stand alone pwer of the axolot if you use more devices ?

#4

I have a USB hub with power and Axoloti doesn't show that it's low on power, so I don't believe that is the issue, not here atleast. It also happens when I connect the midi controller to a computer and route the midi via usb device port.

#5

I'm using a launchpad mini, launch control xl and launchpad pro. I haven't had the problem described but thought I'd share what I have come across...

I've had no issues with the mini that I recall.

The launch control xl has caused crashes before, but it's been when I've been fiddling with code... The patch I use it with at the moment never crashes. Just using it for knob/fader input and send some messages for lights back. It doesn't seem to like too much data being sent to it. I'm forwarding midi through the din. A few people on the forum have had problems though.

Launchpad pro has been fine, but just lately I've had a few crashes with a new patch (not with patcher running) where the patch is still running but the pro's leds go dark and it stops sending midi until I restart the launchpad (patch is still running). But I've been coding objects for it and I'm no coder, so it might be that.

I'm not sure what causes the problems, apart from data being sent too fast to the controller.

#6

I want to add that I am not the only one who had issues with controllers form the Launch Series.

@Blindsmyth also seemed to have had a lot of issues.

For the mini I had tons of mdi ringbuffer overflows. Not sure what that actually is, but it happens all the time if you send data to update the LEDs in any of the buttons, for example. An this does not happen in Pure Data. In PD I can send thousands and thousand of messages a minute, without a single hick up from the midi controller or PD. As soon as it's connected to Axoloti, the endless problems starts.

#7

Yeah, others have had issues too. But some haven't, so it's strange, but something is happening. I'm curious as to what. I wasn't trying to say issues don't exist, just sharing what I've experienced.

And yeah, it doesn't like data too fast, but I can still send it fast enough that it looks as though every led lights instantly, so not really a problem for me. For example, rbrt's launchpad object can light the mini's grid with no issues, instantly. I wonder if its simply the speed causing the issues and it depends on how the objects being used were coded. Or maybe a power thing?

Fwiw, I have my axo's powered by the dc barrel sockets, connected to an unpowered usb hub to Windows for patching (no usb device midi going on). Could it be something to do with usb device midi? Just throwing out ideas in case they help.

Something I had forgotten about - at one point I was forwarding launch control xl midi through the din and if i moved more than one fader really quickly it would crash. I used a thinning object to forward the midi and the problem went away.

Do you have crashes on every patch or is it only on some, or totally random? Does it crash on an empty patch?

#8

And yeah it's that inconsistency that's really hard to figure out and work with.

One day I can have it connected and it works okay for a few hours. Next days I get error and disconnects en masse. And I have tried several different Macbooks, with same result, trying to rule out other variables. I tested the controllers with other devices and works fine. But with axo, it just drives me nuts, cause it's so inconsistant.

So it's very frustrating.

#9

How do you update your leds? I can really recomend usign the objects by @rbrt table send note / table send cc. I don't have this ringbuffer thing.

As the author of the thread indicates here also using a usb hub can cause problems!

#10

don't know if this helps,but:
axo's midi-implementation doesn't thin data that is being sent.
if you send a note/velocity - pair every k-rate cycle,you will flood the midi output buffer.
that's why the factory-objects have a 'trigger' - inlet to call 'midisend'.

my objects look for changes of the data inside a table, and then
call 'midisend'.so, they don't flood the buffer (but they need an internal array to keep
track of what's changed)
I just published a really simple implementation of that concept
at 'rbrt/poly/holdmap send', here's a screenshot because there's no help patch yet:

the attribute 'holdmap' could be any other table,
I think it has to have minimum 128 elements though.

#11

The way I update the LED's id actually by suggestion from you @Blindsmyth.

I use an lfo to trigger the midi out send to my midi controller. Then I use a counter triggered by the same lfo to run through the table that holds the values for the steps.

It's fairly simple and not updated a lot, update speed is set by the lfo and I do not set the lfo too fast, but also not too low, just in the middle so it doesn't lag.

#12

Ah yes I did it like that quite a while ago. But I would recomend now to use the method suggested by @rbrt.
Alltough I use these objects:

Bildschirmfoto 2020-05-25 um 16.23.50.jpg1550x750 80.3 KB

So one writes from the midi controller to the table. In this case it turns all the buttons into toggles.
And the other is sending from the table to the midi controller.

Its far more efficient as you only send the values that change. Like this you will have far less midi traffic and thus no buffer overrun and these kinds of problems.

p.s. this works best when you put your buttons in a chromatic order. I did that on the user mode of the launch controllers. Otherwise you will have to hack into the code and remap the values.

#13

...these objects are rather old, I'd recommend all the stuff in rbrt/poly
for midi