UFX+: Cannot change Control Room Main Out

[wohali]

Hi there - great work! Really impressive progress. Can't wait to try the Qt version, too.

With my UFX+ I'm able to see audio being played back (via Analog 1/2) and the volume controls appear to work. However I can't alter routing via the Control Room Main Out dropdown on the right-hand side. (I am able to route Playback Analog 1/2 directly to Analog 3 in the dropdown, but the interface lags badly when I do this).

Is this unimplemented? It's kind-of the only thing I really need out of casual TotalMixFX use right now.

Linux, Debian Trixie 13.4,

FYI: I'm only able to get this working right now via web and local midi port, not websocket with seqio/rawio running. GTK won't connect to either alsaseqio or alsarawio, and your nightly Qt build is broken (no assets for download, only the GTK version).

[huddx01]

Hi, thanks for trying out.

I am fiddeling with the Qt ui CI workflow atm (implemented UFX today).. Give me a few minutes and the Qt ui will be available again in nightly releases.

With my UFX+ I'm able to see audio being played back (via Analog 1/2) and the volume controls appear to work. However I can't alter routing via the Control Room Main Out dropdown on the right-hand side. (I am able to route Playback Analog 1/2 directly to Analog 3 in the dropdown, but the interface lags badly when I do this).

Is this unimplemented? It's kind-of the only thing I really need out of casual TotalMixFX use right now.

Hmm, I dont own a UFX+ for testing, so your report is very useful. So, you did experience this issues via the WebUI, correct?
The Main Out Dropdown just selects the Main Outs (you can verify this via the LCD Menu on unit)
Would help if you could describe the issue more detailed - I'll look into this asap, too.

For websocket, you need to build wsdgram yourself atm (I didnt serve it in the releases yet, as you're the first person asking for this - but I personally use it frequently as we are independent on which machine the unit is plugged in and the browser can run on any host inside the network - you probly knew this). For now, best is to checkout the dev branch first (it contains most recent updates) and then via make wsdgram. Basics for this are described in https://github.com/huddx01/oscmix#web-ui at the bottom of the chapter (you'll need a server for this too)...

Well, let me do the qt ui stuff first as mentioned. Will be back in a few minutes...

[huddx01]

@wohali

Can't wait to try the Qt version, too.
and your nightly Qt build is broken (no assets for download, only the GTK version).

fresh baken Qt AppImage builds are available now in the nightly assets.
Qt should run much smother generally.
Thanks for trying out (don't expect everything to work yet - Qt ui is in heavy WIP state atm)

Maybe one question regarding the lags:

(I am able to route Playback Analog 1/2 directly to Analog 3 in the dropdown, but the interface lags badly when I do this).

Do you mean the gtk variant?

• If so, yeah, its the same here on my UFX III (94 ch I/O) too. Thats one reason why I am focusing at the Qt (time is finite...)

Or the webUI version?

• Well, my ufx iii is at least quite ok regarding performance. sure it takes a few seconds after first connect until the full dump is finished. But then its usable (although a browser always adds some lags). Level meters, etc run quite smoothly here.
  However, on the button of right panel there are some debug options, which might worth to enable some options and see in the inspector/dev tools panel if something is throwing errors, etc...

[wohali]

Hi @huddx01 , happy to help. I'd like to contribute some improved install/setup documentation once I've got this all worked out, too. (Not today! too busy.)

I am fiddeling with the Qt ui CI workflow atm (implemented UFX today).. Give me a few minutes and the Qt ui will be available again in nightly releases.

Qt interface came up once and showed live data, but crashed and subsequent runs stopped working with an uninitialised display. Also can't resize the window, window vanishes and I get:

qt.qpa.xcb: xcb_shm_create_segment() can't be called for size 17179344900, maximumallowed size is 4294967295

and the process consumes 100% CPU. Happy to move this to a new ticket to help you with this if you like.

Hmm, I dont own a UFX+ for testing, so your report is very useful. So, you did experience this issues via the WebUI, correct?

Yes, I can't get the GTK version to work at all, only the "demo" instance and nothing updates ever. Gave up on it once the Web version started working as it looks a lot better! 😆

The Main Out Dropdown just selects the Main Outs (you can verify this via the LCD Menu on unit) Would help if you could describe the issue more detailed - I'll look into this asap, too.

OK, that's working then as well, please disregard. I thought in TotalMix this also selected the default routing for channels, but perhaps not. Turning the knob on my ARC or the front panel does indeed track what is in the dropdown.

For websocket, you need to build wsdgram yourself atm (I didnt serve it in the releases yet, as you're the first person asking for this - but I personally use it frequently as we are independent on which machine the unit is plugged in and the browser can run on any host inside the network - you probly knew this). For now, best is to checkout the dev branch first (it contains most recent updates) and then via make wsdgram. Basics for this are described in https://github.com/huddx01/oscmix#web-ui at the bottom of the chapter (you'll need a server for this too)...

Awesome, I'll give it a go at some point.

Maybe one question regarding the lags:

(I am able to route Playback Analog 1/2 directly to Analog 3 in the dropdown, but the interface lags badly when I do this).

Do you mean the gtk variant?

No, the web.

Or the webUI version?

* Well, my ufx iii is at least quite ok regarding performance. sure it takes a few seconds after first connect until the full dump is finished. But then its usable (although a browser always adds some lags). Level meters, etc run quite smoothly here.

Yes, that's all fine. The lag happens right after changing the output of a given playback/input channel to a different submix. The entire UI freezes for about 5 seconds, then comes back and everything is fine.

HOWEVER: it does seem to change the value in EVERY Inputs/Playbacks dropdown to the newly selected output, which is obviously wrong (and unwanted).

  However, on the button of right panel there are some debug options, which might worth to enable some options and see in the inspector/dev tools panel if something is throwing errors, etc...

I didn't dig into Developer Tools (Firefox) to see why. Console doesn't show any errors. Something in Debug doesn't seem right, because unless I turn on Levels or ARC I see nothing in the console log at all when changing the dropdown per-playback/input.

I also have a physical ARC and the buttons don't seem to be responding on that at all, guessing you've not implemented that yet. Opening the web ARC USB window does let me toggle device LEDs by pushing Talkback/Speaker B/Dim, but no button does anything. ARC volume knob does work though. Again, happy to move ARC stuff to another ticket if you'd like my help debugging something with hardware in front of me.

[huddx01]

I'd like to contribute some improved install/setup documentation once I've got this all worked out, too. (Not today! too busy.)

I'd love that! Probably you can imagine. Although I try my best, the documentation is always behind the current state. This would be very helpful

Qt interface came up once and showed live data, but crashed and subsequent runs stopped working with an uninitialised display. Also can't resize the window, window vanishes and I get:

qt.qpa.xcb: xcb_shm_create_segment() can't be called for size 17179344900, maximumallowed size is 4294967295

Thats an important and useful hint! I have an idea where this could rely on... Possible you use HiDPI graphics/monitor? (I test it in my vm here with a low res/hdmi monitor, thats a possible reason I never got this issue).

Just to compare: Could you tell the results of:
xrdb -query | grep dpi and xdpyinfo | grep resolution

Here, in my vm:
Xft.dpi: 94
resolution: 96x96 dots per inch

Youll probably have higher values - and its my fault, as I look into my code now, this could lead to overranged shm segment sizes, which might be the root cause... Well, just a possible guess for now (as i cannot reproduce it here on VM)

and the process consumes 100% CPU. Happy to move this to a new ticket to help you with this if you like.

Thats probably a follow by issue due my fault... When the app crashes (or is force-killed), the oscmix backend processes were left running as orphans, blocking the MIDI device on the next launch. Fixed on two levels: if the qt ui crashed, orphan oscmix process still existed, which are still bound to the unit.. I tried the following:

• At startup, cleanupOrphans() reads a temp file of known process group IDs from the previous run and kills any that are still alive
• Child processes now run in their own process group via setsid(), so stop() can kill the entire tree (coremidiio/alsarawio + oscmix) with a single killpg() call. On Linux, prctl(PR_SET_PDEATHSIG, SIGTERM) additionally ensures the child dies automatically if the parent is killed. Just to explain, its implemented in the qt ui code... Hope it helps...

Maybe to explain how it works: the ui apps basically just call the embedded oscmix bin via alsarawio/alsasqio (or coremidiio on macs). The advantage is, I can keep the underlaying codebase sperated. That means code chhanges do need to be done on one point. And this affects all UIs

however, I'll try to fix that and update the qt release in a few minutes...

Yes, I can't get the GTK version to work at all, only the "demo" instance and nothing updates ever. Gave up on it once the Web version started working as it looks a lot better! 😆

I am sure, youre rigtht. The gtk has a bunch of problems... Sorry for wasting your time. However, Ill look at that as I have some time to focus on gtk... For now, the qt (and webUI) make more sense sense from my point...

Regarding the ARC:
Yes - again, lack of time ;) The ARC functionality is basically implemented. That means, on my ufx3 i can set the LEDs on arc and i can see in the debug log messages if buttons are pressed. So, basically it needs a layer between to map the incoming pushes to whatever controls on UI and send LED states back if a control is active, etc... I mentioned this her already: #17 (comment)

However, possible the regs for UFX+ regarding the ARC are incorrect (my fault - or due the fact i dont own a UFX+). Once, we got the qt ui solid running on your system we could use the OSC Debug Log to easily verify if the regs are recognized correctly by oscmix in general. See https://github.com/huddx01/oscmix/wiki/oscmixQt#osc-debug-log

Edit: the qt ui related modifications are available now in the nightly. Please try again. Looking forward for your feedback. Thanks again.

[huddx01]

HOWEVER: it does seem to change the value in EVERY Inputs/Playbacks dropdown to the newly selected output, which is obviously wrong (and unwanted).

Just read your issue again - sorry, I overlooked that before.
Did you try the "free routing" mode on right panel? Maybe that's what you need?

[wohali]

I'd like to contribute some improved install/setup documentation once I've got this all worked out, too. (Not today! too busy.)

I'd love that! Probably you can imagine. Although I try my best, the documentation is always behind the current state. This would be very helpful

Great! Once we get these issues sorted out I'll give it a look.

Qt interface came up once and showed live data, but crashed and subsequent runs stopped working with an uninitialised display. Also can't resize the window, window vanishes and I get:
qt.qpa.xcb: xcb_shm_create_segment() can't be called for size 17179344900, maximumallowed size is 4294967295

Thats an important and useful hint! I have an idea where this could rely on... Possible you use HiDPI graphics/monitor? (I test it in my vm here with a low res/hdmi monitor, thats a possible reason I never got this issue).

Just to compare: Could you tell the results of: xrdb -query | grep dpi and xdpyinfo | grep resolution

Here, in my vm: Xft.dpi: 94 resolution: 96x96 dots per inch

Youll probably have higher values - and its my fault, as I look into my code now, this could lead to overranged shm segment sizes, which might be the root cause... Well, just a possible guess for now (as i cannot reproduce it here on VM)

$ xrdb -query | grep dpi
Xft.dpi:        137
$ xdpyinfo | grep resolution
  resolution:    139x140 dots per inch

I usually invoke Qt programs with the env vars QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCALE_FACTOR=1 but they didn't seem to help this time.

and the process consumes 100% CPU. Happy to move this to a new ticket to help you with this if you like.

Thats probably a follow by issue due my fault... When the app crashes (or is force-killed), the oscmix backend processes were left running as orphans, blocking the MIDI device on the next launch. Fixed on two levels: if the qt ui crashed, orphan oscmix process still existed, which are still bound to the unit.. I tried the following:

* At startup, `cleanupOrphans()` reads a temp file of known process group IDs from the previous run and kills any that are still alive

* Child processes now run in their own process group via `setsid()`, so `stop()` can kill the entire tree (coremidiio/alsarawio + oscmix) with a single `killpg()` call. On Linux, `prctl(PR_SET_PDEATHSIG, SIGTERM)` additionally ensures the child dies automatically if the parent is killed. Just to explain, its implemented in the qt ui code... Hope it helps...

ps waux | grep alsa doesn't show either alsarawio or alsaseqio running, though. The UX comes up but stays mostly empty, despite recognising the device. screenshot:

You can see the new binary can see my UFX+ but it never fills in any more details and halts here. Settings window says "connected" but.... nothing in the UX.

Eventually going into the settings window I'm able to click Refresh and get the UX to populate, so that's cool! Not sure why it didn't do it the first time.

It didn't get the current value for Control Room Main Out but it was able to change it no problem. Dim, Dim Red, and Mono aren't working. DSP isn't working either.

Another CLI error related to DPI:

Painter path exceeds +/-32767 pixels.

I am sure, youre rigtht. The gtk has a bunch of problems... Sorry for wasting your time. However, Ill look at that as I have some time to focus on gtk... For now, the qt (and webUI) make more sense sense from my point...

No worries! Ignore the GTK version, I'm happy to use the web version until the Qt version is done.

Re: ARC: 👍🏼

However, possible the regs for UFX+ regarding the ARC are incorrect (my fault - or due the fact i dont own a UFX+). Once, we got the qt ui solid running on your system we could use the OSC Debug Log to easily verify if the regs are recognized correctly by oscmix in general. See https://github.com/huddx01/oscmix/wiki/oscmixQt#osc-debug-log

Sure, when we get the Qt version stable.

Edit: the qt ui related modifications are available now in the nightly. Please try again. Looking forward for your feedback. Thanks again.

I don't see a new nightly build yet, will check back tomorrow.

[wohali]

HOWEVER: it does seem to change the value in EVERY Inputs/Playbacks dropdown to the newly selected output, which is obviously wrong (and unwanted).

Just read your issue again - sorry, I overlooked that before. Did you try the "free routing" mode on right panel? Maybe that's what you need?

Yes, that lets me select different outputs per playback, yay! Perfect. It's been a while since I had to mess with that stuff in TotalMix so I've probably forgotten I did that years ago. Thanks for being patient with me 😆

Also of note is that changing to that mode makes the 5-second delay go away. That's probably because you're not sending changes for a huge number of submixes at once (in my case, Analog 1-12 + AES + ADAT 1-16 + MADI 1-64!!!) However it does seem to be doing that sync and hanging the UX, not async?

[huddx01]

Also of note is that changing to that mode makes the 5-second delay go away. That's probably because you're not sending changes for a huge number of submixes at once (in my case, Analog 1-12 + AES + ADAT 1-16 + MADI 1-64!!!) However it does seem to be doing that sync and hanging the UX, not async?

Well, regarding webui: I got the reason why you've seen only 30 channels...

• I changed the MIDI port names of my "Fireface UFX III (xyz)..." internally (on mac) to "Fireface UFX+ (xyz).." (to appear as yours, although sure, it would not behave correctly)
• I connected it via WebUI MIDI - and looked into the browsers console log: oscmix.js:1477 Active device: Fireface UFX
• That was the root cause: It was recognized as UFX instead of UFX+...
• So finding and fixing the bug was quite easy: https://github.com/huddx01/oscmix/blob/dev/web/pub/js/oscmix.js#L14C1-L24C3

Additionally, I re-checked the the ufx and ufx+ related gains, reflevels and autoset params and (hopefully) fixed them too. See: 279bfdb

What I also noticed: As you mentioned you use firefox:

• Here with my UFX III and tested in Firefox, I can reproduce the lags (around 1-3 secs) on switching the full submixes too...
• Don't know atm exactly why this happens, but tested on Brave and Chrome as a comparison: they run lot smoother.
• I also noticed that firefox uses ~70-90% of CPU

Beside this, I need to re check the code in oscminx.c, the gtk's main.c, and the qt ui's device detection logic, as the "device naming" order in structs/arrays there might lead to similar culprits.

So could you please re-test the webui (and maybe as comparison to firefox with a "real" chrome based browser)?
Looking forward for your report and feedback...

Thanks again - your insights helped really a lot...

[huddx01]

Regarding Qt UI: I am currently working to fix your issues. However, need to quit for today. So it will probably be available in nightly tomorrow...

PS: I went over your website today. Seems we have a similar passion regarding Electronic Music and old/legacy synthesizers/controllers/hardware and Electronics... Love this stuff, too😍

[huddx01]

I don't see a new nightly build yet, will check back tomorrow.

Sometimes you need to reload the releases... However, the Qt UI is build on another repo, so the CI from there does not update the overall nightly, it just adds its Qt assets to the current nightly (with, of course, another commit id).

If your UFX+ is not recognized on first startup, please go to settings in qt ui and hit rescan devices.

Todays state (don't know your arch):

https://github.com/huddx01/oscmix/releases/download/nightly/oscmixQt_v0.0.1-alpha.a8a3746_linux-aarch64-AppImage.AppImage

https://github.com/huddx01/oscmix/releases/download/nightly/oscmixQt_v0.0.1-alpha.a8a3746_linux-x86_64-AppImage.AppImage

[wohali]

hello, i'm a bit busy today but will get to this as soon as possible!

[huddx01]

No rush.
However, the links above are already outdated (sometimes I have more time to code and update things quite frequently)
Better to look in the nightly releases artifacts directly... (my direct links make no sense - sorry)

[wohali]

Daily use of the github website today for volume control and something changed with stereo playback? I'm only getting mono now out of the device even though it's showing audio on both channels. Disabling/enabling Stereo mode doesn't restore an Analog 2 slider, and I can't get any audio out of Analog 4 / right.

Here's a screenshot of the broken behaviour.