Consequences of picking up moddevices/mod-ui

So I (rather accidentally) ended up installing ModDevice’s version of mod-host. And everything runs fine. So far. I picked up the Moddevices’ mod-host without appreciating how different the MODEP and MOddefvices distributions are!

There’s a feature I particularly want that’s present in ModDevice’s mod-ui (specifically, the ability to return vectors of values from the lv2 plugin to the web UI…

However, current version of mod-ui used by Blockas MODEP is “268 commits ahead, 405 commits behind” the moddevices:master of mod-ui from which it was forked!

What exactly am I going to get if I compile and install the MoDevices version of mod-ui. I can easily imagine 268 reasons why things might not go well.

I’m trying to decide whether to try to pull and merge from the Blockas github, or switch to Moddevices’ mod-gui.

The application: svg-based frequency response graphs for complex sets of filter controls in a very sweet guitar amp sim.that I’d particularly like to run under MODEP.

This is the UI I’m trying to replicate: https://www.native-instruments.com/en/reaktor-community/reaktor-user-library/entry/show/14009/ That’s my amp sim. The graphs have a hugely positive effect on usability, so I’m willing to go a long way to get the graphs replicated.

The challenge: Blockas’ current mod-gui does NOT support atom:vector notifications on atomSequence output ports. (via the patch property_set extension). ModDevices’ version of mod-gui does. Disappointingly, neither version does the right thing and fully interprets arbitrary atom streams, although I don’t actually need that.

What exactly am I going to get if I substitute the moddevices version of mod-ui? An unholy mess? Would I be better off pulling and trying to get Blockas to merge the relevant code?

Total changes: about 50 lines of javascript in mod-gui. Maybe a couple of hundred lines in mod-host (I haven’t checked). Maybe 400 lines of javascript to do the right thing and make mod-gui fully parse mod-host’s version of atoms streams. Or Json-ize both (probably THE right thing to do).

The current state of my implementation: Receive a change notification on an output control; SET a frequency response request on an input control. Wait for frequency response and requestOut on an output control. Repeat for 64 frequencies. All of which takes about 10 seconds, for 64 values. All of which could be resolved completely if only I could convince mod-gui to pass me an atom:vector of data.

Mod-host will current send vector data as parth of the patch extension. The Blokas Mod-UI receives the notification from Mod-host, and then promply and discourteously throws it away, rather than forwarding it to the modgui javascript code. The Mod

Total changes: about 40 lines of javascript code in mod-gui. I’m not sure what Blockas’s mod-host looks like – maybe a couple of hundred lines in mod-host.

Opinions? Theories? Advice?

Hey, we occasionally update our forks of MOD repositories to some stable version, and apply our own changes, which are mostly to hide/disable functions that just wouldn’t work without having the actual MOD hardware, so they’re not there to confuse.

The changes themselves that we applied are not that many - GitHub compares with the master branch, it should compare with hotfix-1.8 branch instead. Anyway, looking at the history you could see it’s just a dozen or so commits that we made: https://github.com/BlokasLabs/mod-ui/commits/modep-1.8. The first commit by falkTX marks the end of our changes.

Feel free to use their latest stuff, I’d just keep both mod-host and mod-ui of the same version as possible. There might be some additional dependencies and repositories you’d have to build to get some features to work.

Let us know how it goes. :slight_smile:

Ok. I may have to rethink my strategy on this. Let me go see what the diffs look like.

If I limit my changes to selective merging of moddevices source, would you be interested in accepting the changes?

The actual changes I’m chasing: support for patch:get/set for transmitting internal status from the plugin to the web UI. I need to push atom:vector notifications from my plugin to my web UI. Moddevices has partial support, for notifications (intrinsics and vector only, which happens to be exactly what I need.

The actual changes are almost entirely in effects.cpp, which doesn’t seem to contain anything harmful.

And very limited additions to mod-ui to route returned parameter data returned by the websocket onto existing javascript callbacks. (maybe 30 or 40 lines).

Regards,

Robin Davies.

Ok. I looked at the diffs. Is there an equivalent merge point for mod-host? Master sources for mod-host effects.c in both respositories seem quite divergent.

The goal of the exercise: to merge support for patch:Set/patch:Get messages being sent from the plugin back to the web UI, which is present in current Moddevices sources, but not present in MODEP sources. All of the mod-host changes are in effects.cpp, and are fairly substantial – about 150 lines all told, including some fixes to provide backward compatibility between your code and current Moddevices code.

For what it’s worth, your message got lost in my spam folder; so I proceeded without your advice, merging and adapting Moddevices effects.c code into yours. If there’s a recent merge point, I may have to redo this work more carefully to facilitate future merges.

fwiw, I also have most of the implemention of round-trip atom:Object notifications (serialization and deserialization of atom:Objects to and from JSON) that I was going to try to get merged into both sets of sources. But I don’t actually need it. So I’m happy to discard that work if I can get a clean merge of only the moddevices code into your sources.

Regards.

The MOD host used in MODEP was built from the commit id as shown by ‘src’ submodule on https://github.com/BlokasLabs/modep-debs/tree/master/modep-mod-host. I see the MOD repo has 1.9 and 1.10 hotfix branches, but not 1.8, in the future, we’d move to 1.10 hotfix branch when updating MODEP.

We follow the source code of MOD, and adapt our changes to it every time an update to the newer version is being made. So ideally, if your changes are accepted into MOD repositories, it would trickle down to MODEP too.

To get them into MOD, I’d guess they’d want you to do it on a quite recent version of their code, and it’d eventually get publicly released.

Btw, if your changes are mostly in effects.cpp on mod-host side, it should be easy for us to maintain, I don’t think we modified mod-host at all.