Is it just me or is the web UI very slow over bluetooth? The slowest bit is the downloading of images, e.g. images for each effects pedal, and preview images of pedalboards in the view which shows all pedalboards.
I’ve tried this from both Linux and Android (and possibly MacOS X but I can’t remember), and they had the same issue. I suppose it could be an issue with the cheap Avantree Bluetooth USB dongle I bought, but it is supposed to be Bluetooth 4.0 …
Bluetooth is inherently slow, not much we can do about it.
If you have v1.2 you can load up this page via USB http://modduo.local/icon-all.html which will load all the plugin graphics. (do not attempt to load that under bluetooth!!)
After you loaded it once, the browser should have the images in cache the next time you load modduo.local, even if it’s using bluetooth.
Bluetooth 5 will double the transmission capacity – that should alleviate the problem a bit. First devices were said to arrive “end of 2016 to early 2017”.
I looked at Chrome’s web inspector while using the Mod UI over bluetooth and it looks like the browser does a If-None-Match request for all images even if it is cached. The Mod responds with 304 (not modified) as expected, which does obviate the need to send the whole image again, but this still means an HTTP round trip for every image resource. Given the large number of individual resources, it would probably help performance quite a bit if the browser was able to use the cached response without checking for modification first.
This behavior is strange because the Mod UI responds to image requests with Cache-Control: max-age=315360000, which should let browsers use the cached resource without checking (for ten years!). My guess is that this is because the responses have a bogus Date header: Date: Thu, 01 Jan 1970 02:25:26 GMT which breaks the max-age cache logic.
Would it be possible to have the Mod set its clock from the UI client? Short of that, I think the correct behavior according to RFC 7231 section 7.1.1.2 is for the web server (Mod UI) to omit the Date header completely:
An origin server MUST NOT send a Date header field if it does not
have a clock capable of providing a reasonable approximation of the
current instance in Coordinated Universal Time.
This should work correctly because a client receiving a response without a Date is required to use the receive time as the Date.
My two cents: having the mod duo web server enforcing the HTTP 2 protocol might also help improve performance as it allows persistent and multiplexed connections (effectively limiting the tcp round-trips while loading resources.
Great idea to support HTTP 2 but wouldn’t it be better to prefer rather than enforce it? Otherwise the UI would stop working with browsers which don’t support it.
This was last discussed 3 years ago … While from memory things did improve thanks to work from @falkTX and maybe others, unfortunately I still find this to be painfully slow. Given that the main use case is for minor “emergency” tweaking at gigs, the speed is kind of problematic.
As mentioned in Save preset edits when not attached to GUI?, I’ve hunted high and low for a dongle faster than Bluetooth 4.0 but not had any luck finding one yet. Does anyone else have suggestions for improving the speed of the web UI over Bluetooth?
Or perhaps there is another way, such as using a wifi dongle which would allow communication via an access point or via Wi-Fi Direct mode?
We have been optimizing the cache strategies the last few releases, so I imagine that will help a lot in here.
But you do have to ensure to use http://modduo.local/ (or http://modduox.local/ if Duo X) so that the same resources are used for both USB-Ethernet and Bluetooth.
Ahhh thanks, that might explain it, because for some reason my phone’s mDNS doesn’t recognise modduo.local when I connect it over Bluetooth. Any idea why this might not work on a not-ancient Android 9 phone?
just getting the full IP to work, in my tests, required me to disable wifi and mobile data.
the old idea of using http://192.168.50.1/icon-all.html to let the browser download and cache all installed plugin resources still applies.
But on a phone… that might kill the browser
a) this is not really for use during performances, at least from my PoV I would want to use it to make small tweaks during rehearsals or sound checks (and anyway it’s 2020, should we really still be settling for the fact that cordless operation is unreliable?!)
b) it’s yet another cable to have to worry about forgetting or tripping over
Also, I’m not very familiar with OTG but why wouldn’t a normal USB cable suffice? Would the MOD act as the host device or the peripheral?
I have a Duo and a Duo X at the studio and for me it seems like terrible not be able to connect both of them via USB, f the IP is the problem they should get different IP automatically or at least be able to modify one of their IPs and be able to access both of them nicely…
I’ve tried an USB BT4.0 stick and it seems pretty slow. I’m looking for a 5.0BT stick, I’ll check if the performance gets a little better…
We dont have a nice way to handle multiple units connected together at the same time with dynamic IPs, it is quite the nightmare networking issue to solve (internal DNS resolvers that need to know and talk to each other…)
WiFi likely going to be the solution to go for, and seems the best for the studio.
The dynamic MAC address of the units will be problematic, but we have been making some tests on this as needed for the “composite” usb support.
This is something we have to see once the first RC of 1.10 is here.
Current plan is to have it by the time the Dwarf beta units go out, which is only a few days away now.