Here :
The v1.11.5.2860 is the reset version
The v1.11.6.2909 is the stable one
The v1.12.0.2934-RC3 is the last release
Here :
The v1.11.5.2860 is the reset version
The v1.11.6.2909 is the stable one
The v1.12.0.2934-RC3 is the last release
Is there same (1.12rc3 and latest release 1.11.6 for rollback) for MDX? Thank you in advance.
I had not updated to 1.12rc3, as I was waiting for the release version, but seems like it does not make sense anymore, and I need HMI update for looperlative hmi led feedback…
There Sharing firmware releases now that the server is down we can archive all versions.
There is already the 1.11.6 MDX.
Hi,
I’ve the same problem (still on RC3) with a wifi dongle that I’ve just bought (Linksys AE6000, works out of the box with kubuntu)
I’ve uploaded the firmware of the dongle (mt7610u.bin) from the last linux kernel firmware with no success.
Although, still no Bluetooth
With me always breaks after a short time the Web Gui and builds no longer when I reconnect the USB cable. Sometimes a reboot of the duox helps. The successful connection is then rather random, but often it does not work at all.
This happens with version 1.12.0-RC1-3 as well as with 1.12.0.
successful connection is then rather random, but often it does not work at all.
Hmm, I feel like after update to 1.12 my MDX fails to connect by USB cable in most cases now as well, I reboot five or more times until I make it to webUI. (“not recognized usb device” or something like that)
Bought a couple of usb cables to try, tried removing all peripherals, powering from usb powerbank to make sure that there is no ground loop - but chances for succesful connection are still quite low.
Before, at 1.11 seems like I had about 25% chance for connection failure. Now it feels to be closer to 85%. Percentage is an approximate perception.
Also I tried it on different computers with the same result. And I had also restarted the computers which did not help either. An update to another version via USB from the duox is still possible.
is the experimental usb audio/midi gadget thing enabled? I have seen that causing issues on certain boots for the duox.
is the experimental usb audio/midi gadget thing enabled?
Yep, I am using it extensively, it is useful for me for recording sound with video to OBS and playing backing tracks or songs I am trying to learn from laptop through MDX to the only speaker I have.
I understand that it is experimental feature, however it seems like it was more reliable on 1.11
Will try testing connection with disabled gadget and let you know.
is the experimental usb audio/midi gadget thing enabled?
Yes.
ok that confirms my suspicions. I think there is a race condition somewhere on the boot/startup details that makes the usb not activate properly.
After I ran “ssh root@192.168.51.1 “rm /data/enable-usb-multi-gadget && reboot”” the duox disconnected again after a short time to the web gui. (Also once no “Pedalbords Libery” and “Banks” was callable).
According to instructions from:
Duo X as USB Audio input and MIDI device | EXPERIMENTAL
Then I executed “ssh root@192.168.51.1 “rm /data/enable-usb-audio-gadget && reboot”” and I was able to connect to the modx Web Gui again successfully. I’ll let you know if it’s permanent, but it’s been running very stable for a few minutes now - without any interruptions.
Just checked again: The Web Gui is disconnected again after both functions turned off.
According to instructions from:
Audio Through USB - MOD Wiki
Are both necessary commands or only the usb-multi-gadget necessary? On the wiki both are listed, in the forum only the usb-multi-gadget.
What I noticed is that the individual pages (“Pedalbords Libery”/“Banks/…” load much faster when it is switched off. With usb-multi-gadget/usb-audio-gadget it took ~very long.
During the test, my router suddenly rebooted, very strange.
This has happened to me only once in the past at a jam with jacktrip because we had set very low latencies.
wiki is more up to date. the extra -audio file switch is to be able to enable the composite device for MIDI which we know to work well. audio is the tricky part due to needing to be actively running without any interruptions
Just as a supplementary information: I am currently using the 1.12.0 version and have SPDIF enabled as separate outputs (Yeah!!! \o/).
SPDIF enabled as separate outputs (Yeah!!! \o/).
so jealous! can’t do that on my LE DuoX…
seriously looking forward to the next DuoX production run… go MOD Audio!!
that confirms my suspicions. I think there is a race condition somewhere on the boot/startup details that makes the usb not activate properly.
Got the same feeling. I’ve disabled usb audio gadget thingie, and got quite reliable connection.
I’ve just noticed that hardware UI in 1.12 has System → Device Settings → USB-B Mode setting. Saved me from factory reset right now, as I’ve forgot to touch “enable-usb-windows-compat” file during experiments, and lost ability to connect to device completely. Luckily hardware menu allowed me to enable windows compatibility mode.
Hope this feature’s reliability will be improved one day, as at this point I rely on it in the way that I will prefer rebooting device multiple times, but keep the audio gadget enabled.
More discussion about the experimental audio/MIDI over USB can be found here:
Duplicating from 1.12 firmware discussion, as this is probably more suitable place for this piece of knowledge. Usb audio gadget mode on MDX seems to cause USB connection fails, it was doing the same on 1.11, but at lower rate. Now in 1.12 probability of failed usb connect seem to raise up compared to 1.11, and it might take series of reboots to connect. Try disabling audio gadget before blaming hardware, buying stacks of new USB cables, etc. Forgetting to create file that is responsibl…
Even if I turn off the experimental audio/MIDI over USB, my duox often loses the connection to the Web Gui. Less often but still regularly in short intervals. By reconnecting the USB cable I can access the Web Gui again, but it is annoying and hinders the flow when creating a (new) pedalboard.
that will be something unrelated then.
since you know how to ssh and do a few things, do you mind getting a few logs out of the system? (after some reconnect issue happens, of course, not for a regular boot)
then send them to me over private message. dmesg
and journalctl | cat
are a good start.
thanks!