#17

I am on the newest firmware (1.30A), but I already tested the setup with firmware 1.21 because I was also expecting something to go on with the firmware. but I was able to recreate the same effect with both versions.

#18

so you would recommend using a powered hub between norns and the launchpad X? I already run the launchpad in its darkest LED mode, but will try the hub scenario.

The strange thing is that on the launchpad side everything is working fine. all interactions are received correctly by norns. even if the digitone is unresponsive, the launchpad button presses are received.

in another project I am using the launchpad as a grid and was able to transfer for example mlr to work with it. here again no problem at all. not lost interactions, no lost led updates …

#19

Oh this is super interesting as I have been having issues with launchpad mini and midigrid. I had been suspecting my code but had started to suspect something in the midi stack… sounds like this could be a hardware issue?

#20

what makes me wonder is that I couldn’t reproduce the problem with kboard and digitone and on the other hand launchpad with norns work fine together as well.

seems to me that each device on its own is working fine but not in combination, which quite frankly is somehow odd to me …

since I own a digitakt, I will try to reproduce the same bug with a launchpad digitakt setup

#21

I stress tested my Axis-49 + norns + Digitone combo and could not get it to fail. I’m inclined to think the most likely explanation at this point is power demands from the Lauchpad browning out the raspberry pi USB bus. Experimenting with a powered hub for the launch pad and/or a bigger power adaptor for the raspberry pi (if the current one in under spec’d) might be worthwhile.

I wouldn’t expect the Digitone to be drawing much if any power from the USB bus given its external power adapter.

#22

I don’t have access to a powered usb hub yet, but I already tested the described setup with a digitakt and a microfreak replacing the digitone.

the strange thing is that in both cases everything went smooth, no drop outs. as soon as I switched back to the digitone, it happened again.

for all three devices I used the same usb cable and for digitakt and digitone even the same power supply.

I think the same, but how to explain the functioning digitakt and microfreak then?

#23

slightly off topic, but i’ve been searching the board for troubleshooting on elektron midi over usb directly connected to norns shield. I can see in dmesg where it picks up my digitone:

[  165.292530] usb 1-1.1.3: USB disconnect, device number 12
[  165.292632] usb 1-1.1.3: urb status -32
[  165.292795] usb 1-1.1.3: urb status -32
[  165.292885] usb 1-1.1.3: urb status -32
[  165.293008] usb 1-1.1.3: urb status -32
[  165.293130] usb 1-1.1.3: urb status -32
[  165.293263] usb 1-1.1.3: urb status -32
[  165.293384] usb 1-1.1.3: urb status -32
[  370.969497] usb 1-1.2: USB disconnect, device number 11
[  376.383832] usb 1-1.2: new high-speed USB device number 13 using dwc_otg
[  376.524121] usb 1-1.2: New USB device found, idVendor=1935, idProduct=0014
[  376.524129] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  376.524133] usb 1-1.2: Product: Elektron Digitone
[  376.524136] usb 1-1.2: Manufacturer: Elektron Music Machines
[  376.524140] usb 1-1.2: SerialNumber: 000000000001

but it doesn’t show up as a midi device on the norns. I have the digitone set to output midi+usb but no matter what settings i mess with in the digitone, the norns won’t pick it up. Any tips? running DT firmware 1.21.

other midi controllers (mpk mini2, beatstep pro) work fine and are picked up instantly.

#24

Now I am convinced that there has to be something going on … I changed the setup so that launchpad X is connected to norns via USB, digitakt is connected to norns via USB, and digitone is connected to digitakt via MIDI din. the digitakt is just bypassing the same notes as before to the digitone. no lost notes anymore …

I somehow can life with this workaround, although I initially hoped to build a small setup, I can take this additional device, but I am really curious what potentially could cause this bug?

I think power consumption is now from the table?

#25

have you selected “USB MIDI” in the digitone’s system options? I assume if “OVERBRIDGE” is selected, norns could have trouble to detect the digitone.

#26

Strange behavior indeed. I’m honestly at a bit of a loss at this point. It seems clear that the combination of those two devices on the USB bus is causing problems. Without the ability to recreate the behavior locally it is hard to get to the bottom of what might be going on.

Looking at the Digitone documentation it isn’t immediately clear if there is any difference between the USB device handling in the MIDI mode vs the MIDI+AUDIO mode. The later is noted as being USB class compliant but my impression was that the MIDI only mode (present in firmware before 1.30) was as well. I may do some more experimentation with the USB config on the Digitone…

If you are looking for a less expensive device to play “buffer” to the Digitone I can recommend the Roland UM-ONE MkII single in/out USB MIDI interface. I have multiple of them, actively use them with norns (and other stuff), and have never had a problem.

#27

o my god, this was it haha. I was looking in the MIDI config settings, and i had “output to” set to USB+MIDI so i thought that was enough. thank you much!

#28

@beat
only thing i can think is that we could roll a build that does some low-level logging of the datastream coming directly from the USB device…

i’ve been following along and trying to see a way that we could be losing TX events due excessive RX density… but i coudn’t. and if “forwarding” the same events works, then yeah, no idea.

#29

For now I found a workaround, a teensy 3.6 which acts as a usb MIDI to DIN converter.

For the long run, I think it could be beneficial for norns if we keep investigating. Unfortunately

your proposed solution sounds a little bit to low-level for my personal skill set, but I am happy if I can help and run such a version to document the issue.

#30

@beat - The latest norns update contains both a new kernel (which could result in improved USB support) as well as new low level code handling MIDI for scripts (which should be transparent). I’d be curious to know if this fixes or at least changes your launchpad + digitone problems.

#31

I immediately thought the same, when I saw that a new OS update is out! I will test it as soon as I can and will report the results.

Is there an easy way to save all maiden projects before I upgrade?

#32

Just use the SYSTEM > UPDATE menu item on the device. That will leave existing projects in place. No need to reflash.

One to the triggers for this update was in fact me realizing that I was running a newer kernel than you were while trying to debug your problem.

#33

This is strange … the issue is still there. Right after hitting 10 notes or so the same behavior occurred.

The teensy fix is still working …

#34

so interestingly I seem to be having a similar problem for a bit now. at first I thought it was a power starving issue but now I’m powering my USB device separately. I’m using a ROLI Lightpad and after using it for a short bit it just disconnects. sadly the device doesn’t reconnect until I unplug and replug it again or wait for around 30 seconds.

dmesg spits out a whole lotta these:
usb 1-1.1: urb status -32

anyone know why that might be happening?

(using norns with latest updates)

update: actually now I realize that there is power running from the lightpad into the norns from the external power which can’t be good so have removed that. gonna hunt for a way to isolate that but still getting these urb statuses… not sure where I can find the definition of these error codes but still debuggin. :confused:

#35

The ROLI problem is (I believe) likely different than the Launchpad X problem.

My experience with ROLI “block” hardware has been universally bad. The firmware on ROLI hardware does not appear to deal gracefully when a USB host is not initiating transfers as rapidly as it wants. The result is that the ROLI device will disconnect itself in a manner that trashes the USB stack. Sometimes waiting seconds/minutes is okay but I usually have to reboot.

I’ve spent countless hours searching and reading source code to find a solution (lots of kernel tweaking and alternate USB stacks). None of my attempts so far have resulted in 100% reliability of ROLI devices without breaking something else. The most recent attempt involved switching to the dwc2 driver in the linux kernel, that did provide more robust behavior but in the end it broke isochronous USB transfers needed by something else I’m working on.

Short of improvements to the ROLI firmware eventually allowing this to work I’ve given up on ROLI.

1 Like
#36

arggh… dangit ROLI. thanks for the info. I’m still holding out hope that there is some solution maybe via some middle managing hardware or something since it all works stable on my linux laptop. perhaps I can have some middle-proxy or something that is more stable (very tempting to just try a widi bud or something here).

trying to keep my norns generally as stock as possible regarding the OS but maybe I’ll try out the dwc2 driver though if you think it provides better results.