Virtual desk operating mode - beta version request :)

[JakeS]

Hi there.

As weird as it sounds - I was working/thinking on the idea, which may or may not be accepted as sane, but I think this couldn't hurt anybody if it could actually be done at least for a small testing purposes...

 

So, as the title says: Virtual desk operating mode. I hope that majority of what I'm proposing here is understood already from that sentence;

Detailed description:

The desk could boot in so called "Virtual operating mode", (either with just this OS, or boot-selection, or even in-software option to be enabled/disabled... For testing purposes I'd prefer to get beta as clean OS with this function only).
This way, the initial settings would be 2 things: Network settings (IP, Gateway, Subnet....), DMX Output settings (Port A, B, C, D -> enable/disable, selection of which universe to be sent at which port, etc...), and a big "OK" button;

The next thing you see, is a small label, saying "Searching for main OS...", at which point the desk would be broadcasting! info requests over ethernet protocol; The user in this state is prompted to run a PhantomZeros application on his machine, set up (if not already) a network settings to match those on the console, and run the phantom console of the same type as he has the hardware console in front of him. Once he's done that, if console type matches (based on the info request message received in the PhantomZeros), the Phantom app asks the user if he wants to start synchronizing data between the Phantom and console. After user confirms this by clicking on a beautiful "Start" button, the console and/or Phantom screens show a nice progress bar, which is saying "Synchronizing data. xx% done";

 

After this is done, the console shows all of the data the Phantom has!

 

Meaning:

The submaster screen data are updated with the data of the phantom zeros, so are the palletes, macros, memories... basically everything. But, CAUTION: this is ONLY data shown on the screens of the console, including the VGA screen; Nothing is actually processed by the console, etc..

Note is, that since the consoles obviously have more than enough memory to store data of all submaster pages, memories, palletes etc, this is to be done in initial sync, to avoid using network bandwidth during usage for unnecessary transfers....

Still though, the desk is acting just as interface to the Phantom one; Therefore, every key press, every fader move is sent to the Phantom, which reacts/makes the change as if the desk would be operating normally. The Phantom at the same time processes everything as today the ZerOS on the console does, and sends the OUTPUT DATA (DMX values) in ArtNet or some self-coded if you prefer - format to the console, which is acting only as a DMX node for the Phantom;

All values are synced in real-time, so every change on the phantom is reflected to the desk, and vice versa (except for the faders of course, which are non-motorized, but noone cares).



This way, all of the resources on the desk are available for 3 things: Processing interface input data (buttons, faders, jog wheels), processing interface output data (LCDs, LED diodes, VGA display) and processing DMX data. The 400MHz AMD inside is more than happy to handle this and keep it of-crashes and delayed.


I don't want to go against any programmer or team of Zero88, but am, just out of curiosity, asking to comment with your vote for such option on our ZerOS consoles;


The description above is providing all functionality; Right now, just for proof of concept, I ask/please/dare you, to create simple demo version, providing one dmx output to act as node for phantom, and submaster faders and lcd's to be reflected from phantom, and that would be enough just to see what's gonna happen.

I know it's making the desk dependable on the external processor, but if we'd at least have a choice, it would be more than amazing. I, for myself, see no troubles having PC next to me, if this is gonna make my console work as it should as now, to be honest, is useless in all aspects, since the LCD refresh is a major issue, the stability is also still a roulette at least for my console, so... I don't know. I'd really like to give it a shot!

 

 

What do you guys (users) think on this one, and what do you, Jon and other developers think about it? I'm really looking forward for your opinions on this idea.

[Jon Hole]

Hi Jake,

 

I think you're running a Solution, is that correct?

 

I understand your idea, but I would prefer to spend our software team's time on speeding up the redrawing of the LCDs in the first place!

 

The main processor in the Solution doesn't cause us a problem. The Co-Processor (2nd processor) is what we're working on to speed up the LCD redrawing, and it's that same processor that does everything you listed above - the Inputs / Outputs (including DMX) and everything on the front panel (buttons, faders, LCDs etc), so unfortunately your solution probably wouldn't help.

 

We prioritise DMX and front panel input (Faders, GO button etc), which is why the buttons are instantly responsive.

 

We made an update to the DMX output to make our consoles more compatible with a wider range of none-compliant equipment (fixtures that don't perform to the DMX specification themselves by not reading the full range of DMX speeds). By doing this, the internal LCD drawing have shown a delay in some situations - so that's what we're working on at the moment.

 

 

I hope this explains things a little,

 

Regards

 

Jon