maweb current faderpage

[GralfR]

Hi!

I've tried the midimonster 0.5 on windows with a MA2 onPC. This is great! Midimonster seams to be the only app getting full-fader-feedback. That's cool.

But how do I only the fader-positions of the current page on MA2? It's nice to have all executors on all pages, but who would translate this to an external motorfader? Motorfaders are much more attractive, when they move on switching pages. So I tried to map page0.fader{1..15}, but that does not work. I do know, that a webremote user might be different from the console-user and the webremote in the browser does not switch pages, even if the same user as on the console is logged in.

So, I wonder, if there is any way to get only the current page of the current user on the console mapped to e.g. external controlchange. This would reduce the amount of traffic and mapping needed, reduce the amount of presets needed on the external device and would increase the usefullness of the mapping. The current page of the current logged in user on the console is held inside a macro-variable $faderpage inside MA2.

Well, I wonder, if some kind of page0 might be created to be used as mapping, if this variable would be pulled, too. All you have to do for a current-faderpage-mapping is just login with the same user on console and midimonster and use page0.fader for mapping. This would be great!

Thanks

PS: sorry, if this is more a request than an issue and should be placed somewhere else. I'm new to github.

[cbdevnet]

Hey, and welcome to github :) For this project, this tracker is currently the right place for all bugs/issues/feedback and also requests, so you're welcome to post here! We might move it to our new home page once that is finished, but even then we will respond to things posted here. Thank you for bringing in valuable feedback, without that I would only implement what I need or think would be useful, so having external opinions and ideas is very helpful :)

I know what you mean, and I agree that it would be very useful to have "automatic" page switching. You're right that the currently selected fader page on the main session is a bit of a mystery to the MIDIMonster, since it connects via the web remote interface. I think there may be a way of getting that info via the telnet interface, but this would be a new protocol in an already rather huge backend, so I'd prefer to investigate easier ways first before taking that plunge...

The idea of a "variable" fader page 0 is interesting, but I'd think its a bit confusing to read from a documentation standpoint, so I'd probably just introduce syntax like ma.current.fader1, so it's easier to understand what the mappings do without having the entire documentation in mind.

I'll mark this issue as a feature request so we'll not lose track of it, but it might be some time until its fully implemented. The main focus is currently on getting the whole thing polished up for a v1.0 :)

[cbdevnet]

Marked as help wanted:

If anyone knows how to get the main console session's active button page via the Web API, I'd appreciate some pointers. I'd either need the value directly, or some way of tying the page selection of the console and web sessions together in some way.

[cbdevnet]

Something that may approximate this would be to implement thecurrent mapping channel, but only for the webremote. So you would be able to switch between pages (via an additional control), but it wouldn't affect the console session at all. That should probably be doable.

[GralfR]

Thanks for the fast response and the kind welcome. Concerning the ma.current.fader this sounds great - better than my page0. To get the current fader page out of the MA I wonder, if a tiny LUA plugin might help on the MA. This plugin might read the $faderpage-variable and if this variable changes its value, the plugin might react on this. I know, this is another location and not comfortable to keep thinks together, but for a quick solution, this plugin might shift traffic from midimonster into console.

This plugin might react in different ways:

• send a midi-note or programchange via console (not the preferred way, 'caus it uses commandline on MA)
• send the current faderpage via UDP to midimonster. LUA is able to send UDP-packages from MA in the background. I already use this for a Wake-On-LAN from MA consoles.

So, there is no need for a new protocol. The only question is, how does the MA plugin know the IP of midimonster? Maybe midimonster could run this plugin with a parameter or set a user-variable via commandline including the midimonster-IP?

Not the clean way, but that's what I thought might already work now with a smart mapping. I wondered, if the value of some kind of midi-note/programchange might be used to reconfigure the current mapping to reduce the amount of traffic; like: midi.ch0.cc{1..15} < ma.page(midi.ch0.note0).fader{1..15}

Now, I know, the config is loaded on startup and can not be changed during runtime. But maybe this kind of dynamic mapping could be an option and be helpful concerning a GUI as well. Just to be discussed...

[cbdevnet]

Interesting idea, the problem I see with that is that it requires changes to the show file and the console, while currently the backend only needs a user/password for login and is "universal" from there, so all mappings work for all showfiles (barring pages that may not be created in the console yet).

It's something I'll keep in mind, maybe as a way to optionally provide "extended" features via an on-console plugin.

[GralfR]

Marked as help wanted:

If anyone knows how to get the main console session's active button page via the Web API, I'd appreciate some pointers. I'd either need the value directly, or some way of tying the page selection of the console and web sessions together in some way.

Well, I do not know the API, but what I just tried is an onPC with two userprofiles and two users. onPC is user1 with profile1 and logged in. This user has selected current page 3. The other user2 with profile2 is logged in via webremote (Internet Explorer) and has current page 1. A listvar on both the console and the webremote show different values for $faderpage. Don't know, if this could be used by API. Important is, the current page seams to be connected to the profile, not the user. So different user might use the same profile and thus have the same current page. I'd preferre having the same current page mapped in midimonster like on console if console and midimonster use the same user/profile.

[GralfR]

all mappings work for all showfiles

Yeah, that's the point. I have showfiles where sometimes I start with page 1 and another user in the same showfile/session starts at page 10 or 20 or even 100. How can this be mapped? The only way seams to be mapping all pages with all faders. But this increases traffic a lot and mapping 90 faders and 110 virtual faders on 10000 pages is a mess. And mapping to what? There are not enough MIDI-controllchanges and channels or even DMX-channels on Artnet-Universes to map all the MA2 faders. And even if there was a way: how to handle this easiely? I do not want to switch presets on my external device each time I change pages on MA2. Motorfaders are great but they have to be mapped to the current page. If not, a manual fader without feedback on any lightcommander mapped to DMX-remote current faderpage would be much more comfortable even if I have to capture current value first. Don't get me wrong: you have done a great job so far. The last thing after getting the fader-feedback is just to map this in a comfortable way....

[cbdevnet]

Sure, I understand why that would be useful. It's probably never come up until now because most of my shows get along with two pages at most (mostly single-operator stuff).

It'll just have to wait a bit until I'm free to add new features again, as I'm currently a bit busy with my day job (hence why my commits mostly center around the weekend currently) and polishing up things.

[greube]

Hey Mate, BRILLIANT program you have made here. Is there any update on this possibly being added?

Thanks

[GralfR]

Hey greube! There is a workaround based on a lua plugin running on MA2 together with a lua script in midimonster and a very(!) huge config inside midimonster. An example for the first 40 pages can be found here. This is just a proove of concept and not beeing tested in a live show. I prefer real MA2 hardware for live-shows.

[greube]

I have been testing out this workaround. It's very nice. Is there any way I could engineer a way of updating each fader position when moving pages. When moving a fader around in MA2 it sends back fader positions on BCF1. Is there a way every time you change a page it updates all faders via BCF1 or something?

[GralfR]

Hey greube! If I remember my script right, it should update the BCF when changing the page on MA2. There are some conditions to be checked:

• Did You add the lua-plugin to Your MA2 show? This monitors the current page on MA2 and "communicates" changing pages to midimonster.
• This plugin inside the MA2 show must be running.
• This plugin needs a sequence on executor 190 on page 1. This sequence needs the fader to be Master. Don't care about the content of that sequence. One empty cue will be fine.
• Midimonster connects to the webremote of MA2. Make sure the user logged in to the webinterface (user BCF in my monster.cfg on line 26) is the same user or at least the same user-profile as the user logged in to the onPC. That way the executor-pages get synchronized.

With that conditions respected the midimonster config should recognize a page change (the value of the fader of executor 1.190) and update the motorfaders on the BCF.

I admit the documentation (if You like to call those few comments a 'documentation') needs to be more clear, but it was just a proof of concept for me. All those conditions, plugins etc. should be implemented into the maweb-backend to make it more adjustable and compact. The need for the executor 1.190 is mentioned in the monster.cfg in the comment in line 41.

Sorry for this inconvenience. If You need an easy, simple soluton, go buy a MA Faderwing. :-)

[greube]

EDIT - I fixed it and now each time I change pages It tries to set BCF channels, but because I'm not using a BCF it cant find the channels and errors. (Btw I'm not using a BCF I'm using a custom fader setup. ) Once I have my faders finished I redo the BCF variable and it will work! Thank you for this wonderful bit of code!

Thank you for the quick reply. I don't have my BCF here I'm simply watching the midimonster terminal. I have done all you have suggested and still when a page is changed no BCF changes come through the midimonster terminal? Is the BCF changes hidden in the terminal and everything is working?

I wish I could afford real MA hardware :(

*picture shows no terminal bcf change*

Thanks so much for your time so far

[GralfR]

Glad You got it running! Right, changing a page does not print fader updates in the terminal. It's not implemented inside the lua-code. I didn't need that on my test setup, because I can see the faders moving on the hardware.

As stated, this workaround is not fool-proofed and poorly documented. After having the faders working I tried to implement the buttons, too. But at this state midimonster comes to it's limits. I've reported that already and left some comments inside the config-file. So using the buttons on the BCF/midi-controller is implemented by skipping midimonsters maweb backend. Buttons pressed on the midi-controller are sent to a virtual midi loop interface which routes the events directly to the onPC. That's why there have to be setup some midi remotes at the onPC, too. There is a screenshot inside the zip for that (sorry, no XML for import by macro, which might speed up importing remotes in a new show).

Having achieved that state of workround I stopped coding and documenting, because first there was no actual show I needed this for (still suffering covid-lockdown) and second I do own a command wing, which is enough for operating small, preprogrammed shows but has no motorfaders. That's where BCF and midimonster come up.

I'm still hoping the maweb backend will fix this page-change-problem anytime. Until then we got this workaround.