SOLVED: Web GUI not updating with state of plugins... (MOD DUO original)

Using MOD devices
1

Hi There!

I am controlling my MOD DUO with a Line 6 FBV Shortboard via USB midi and it works wonderfully… but when I have the GUI open in the browser, the screen only updates sometimes - it won’t show which plugins have been enabled or any changes on screen. For example, stepping on the pedal on the Line 6 will light up to show a plug in enabled (say Shiroverb), but the light on the Shiroverb in the GUI will not show as enabled. The plug in turns on though, I can hear the effect.

I know the other direction will never work (the Line 6 LEDs won’t reflect changes made in the browser) but I seem to recall it the GUI updating in real time in the past. Are there any tips to have it react in real time to changes via midi?

Hoping I just missed something obvious… :slight_smile:

2

Is this a fast switching on and back off or even waiting long will not show it?
What is the OS version that you are using on the Duo?
And last, but not least, is possible that it is a browser cache thing. Are you using an incognito session?

3

Hi Jon,

Thanks so much for your reply. I am using incognito on Chrome and Safari on a Mac, and the DUO is running the latest - 1.12.1.2976.

Interestingly, mapped controls from the device do update the screen in real time, but any midi messages don’t update the GUI elements. They do activate and control the mapped settings in real time (no lag with volume pedal with stereo xfade plugin for instance) but the screen does not reflect the changed values both in the edit view and the pedal board view. This happens with different midi devices, plugged in to either USB or old school 5 pin DIN. I have tried both aggregated and separated mode.

I appreciate any insight on this as the screen is not reflecting the actual state of the pedals.

4

Ok one more weird thing! I mapped the hardware bypass plugin to a midi pedal on my FBV and even thought the led doesn’t update on the GUI, the bypass kicks in and the two indicators on the bottom of the screen light up in real time! So the system is recognizing the midi controls, the plug in guis are not updating.

Screen Shot 2023-01-13 at 4.55.50 PM
Screen Shot 2023-01-13 at 4.55.50 PM273×217 66.6 KB

5

I’ve been having this issue for the past year. I posted here about the issue:

6

I’m using Brave (w/shields down) on http://modduo.local/ and also tried with Firefox. I am noting that it is just happening with my MOD footswitch and that the indicator lights on the actual main MOD DUO are reflecting the state.

I’m using the latest update, which I just upgraded to a few minutes ago: OS Version: 1.12.2.3007.

I did have an odd time upgrading the foot switch many moons ago. I will try to upgrade the footswitch again, which is currently at 0.4.1, I just don’t have that type of USB cable with me right now.

7

Hi.
I have the same issue with google. For me it was worse because the CV function doesn’t work with google.
When I use Firefox I have no issue.
You should try a different browser

8

OMG Julien thank you - it’s working with Firefox!

I had tried Safari and Chrome but FF works perfectly so far - even the knobs twist in real time with the controller.

THANK YOU!

9

I’m happy for you.
I noticed big issue with chrome webbrowser too.
As I said CV functions doesn’t work at all when I use chrome.
That’s weird.

10

That is indeed weird. I use Chromium all the time for MOD (since FF is my main browser and I prefer to use a dedicated browser for MOD) and can use CV just fine.
I can’t think of any specific reason why CV would act weird in certain browsers …

11

Requesting to re-open the ticket as I had exactly the same problem with my M-Vave Chocolate controller (Plug-ins on the MOD DUO respond, but UI does not update).

Did some trouble shooting as to what is really causing it:

Observed from the browser by listening on the page’s websocket (window.ws):

  1. For 40 s after a page reload, with the MIDI controller toggled several times, the page received no param_set, output_set or data_ready at all, only ping, stats and sys_stats. Duo footswitch changes still arrived, because mod-ui sends those to the websocket itself.
  2. The page then sent data_ready N for N = 0…5000. The backlog was released at once: the queued param_set … :bypass 1, then data_ready 3, then normal live traffic, with MIDI changes appearing within milliseconds.
  3. So mod-ui was waiting for data_ready 2, which no client ever sent. The data_ready 3 that followed shows the expected counter was 2.

Full ticket:

12

Which MOD OS are you using?

In an ideal case, this would be tested in 1.14-RC and reported in the dedicated topic, so it gets included in the fixes for RC5

13

Using 1.13.5 but I could install RC4 and see if that changes anything. :+1:t3:

14

As a temporary fix for OS 1.13.5 and 1.14 (if anyone needs this before it get’s fixed proper). Add a new bookmark to your browser with the following in the url field

javascript:(()=>{let a=Date.now(),f=Date.now(),k=0;ws.addEventListener(‘message’,e=>{a=Date.now();const d=String(e.data);if(/^(data_ready|output_set|param_set)/.test(d))f=a;const m=/^data_ready (\d+)/.exec(d);if(m)k=+m[1]});setInterval(()=>{const n=Date.now();if(n-a>5000)location.reload();else if(n-f>5000){for(let i=0;i<=k+20;i++)if(i<20||i>=k-2)ws.send('data_ready '+i);f=n}},2000);alert(‘MOD watchdog on’)})()

I named the bookmark “MOD DUO Watchdog”

If you load that bookmark while on the modduo.local page it resets the midi and everything goes back to normal. :slight_smile: