Okey thanks i will check that when i have more time.

Have added simple eslint config with settings i'Ve already mentioned before. Don't have any other special preference at the moment.

the riot.js compiler is not required can be replaced with riot.min.js (~12KB less) i will do that when i have done the new widgets.

Is the riot compiler JS still required? As currently pre-compilation is done by gulp.

Dev VM is planned for UI development in first place, then i hope to move daemon to another repo and also place it there, for comm tests.

When there is a code style guide that you prefer or has been defined it's no problem to adapt it. I'm new in terms of code development and it's my first real code project i'm happy to get inputs to reach a better result.

Nothing to be sorry about, just normal development cycle. Preparing the VM currently, which will hold the web UI dev environment. It consists of Manjaro (XFCE) and Atom.io mainly. Will try to add some plugins, like eslint, after that we have to do a short discussion about code style, e.g. semicolon yes/no, single ' or double " quotation marks for strings and so on. Have my own preferences, but wanted to talk to majority about it.

@BAndiT1983 strage bug the precompile for the .tag files didn't see the end correctly i removed emty space's and it works againe. sorry for that.

Please check the code, getting unexpected token "<" in browser.

made the upload, i will also delete my repo in some days.

https://github.com/apertus-open-source-cinema/web-remote created

Then a new repo please, with commit rights for us all. You could upload latest version, so Francis can commit his changes over it, then we can inspect the differences. I've adjusted his code a bit, as showcase for Browsersync stuff, but not very much.

Whatever you prefer.

Should we start separate repo for it, and add as submodule to beta-software one later? This would allow to do things in parallel, like independent CI builds.

Great to see things flowing so steadily here!
Shall I give you commit access to github so you can more easily commit/collaborate on code?

i made a update my stuff is still under development but the other part hasn't been changed so gulp should work.
made also all component tag's to a single js file so it looks slowly better in the index.html file and less stuff to load.

Here is the version with browsersync support. Lost my websocket adjustments, but there were only few, which is not that tragic.

Nah, not gulp serve, but browsersync. It reloads HTML page on the fly, when it detects changes to HTML or JS files. Also you can stream CSS changes, without reloading the page, which saves time. Also you can adjust it to compile and then reload on changes to Tag files, as an example. Really nice stuff, using it when i can for web development, latest one was development of a Drupal theme, done with this live preview. See pcb-aoi apertus repo on Github for an example.

Sound's good and take it easy 😉...
For the UI my view was to have for each data type a own widget and the module maker defines the widget for his module.

Adjusted UI code a bit, so it would send correct message on reload, to get available params. Also adjusted websocket server processing, so the response will come back with real data from daemon. Will try to do final tests today, before uploading it.

We can for sure embed it in a JSON file on the camera and send it together with other stuff back. Will resume to inspect your code in a moment, as i want to get exactly this part of comms done, before proceeding with adding parameters.

My target is to use indexedDB from the browser to store the data. There shouldn't be a big task to go over daemon (it takes maybe 20-40 LOC to make it happen) .

No problem, adjust it to your liking, just assisting with some infrastructure. Websocket has connected, after my adjustments, see the code, but haven't got much further, as it expects the JSON database. Will try to adjust it, so it actually tries to retrieve it from websocket server, as i'm not sure, if we should maintain separate JSON config file or not. Current plan is to provide it dynamically by daemon, on request.

@BAndiT1983 thank you! i didn't invest a lot in gulp yet but it looks very simple. thanks

Improved a bit and fixed small problems, also added build.sh.

please commit/upload!

My proposal for GULP adjustments, started to implement, as i wasn't sure how to debug riot.js without precompiling:

I agree that its important to familiarize yourself with the technology but still we cannot punish users who didn't.

@sebastian the others don't know that is important to test and understand the equipment. (could tell storys about that! a good hint this was a reason why i support apertus! we lost nearly customer data because we haven't test the memory cards before shooting)

i'm sure most user will test first there setup at a location that has internet.

@sebastian it only needs internet connection when you load the site after that it can work offline. i'm sure most user will test first there setup at a location that has internet.
PWA requirement is a http server (can be a very simple one) and a modern Web Browser the decision if it's in the firmware / internet or where ever is at the moment not relevant and can be solved on a later stage when the server is working.

We don't know if camera users will have internet connectivity where they are shooting so serving from apertus.org is not a good idea.
Whats the problem with having a http server on the camera? Its already prepackaged and available. Updates to the WebRemote can be done with the camera firmware.

@BAndiT1983 for to make a PWA it looks like it requires a http server the reason is the PWA / Service Worker checks if there is a update or not from the server.

@Francis: Do you need some assistance for the setup? I'm usually using gulp, but grunt also shouldn't be a problem.

Have hoped to do it without a server, as it should be self-contained later. The plan, which was created by another user (Task T937), is to send the whole app package to the client (e.g. smartphone) on first call. This would allow to avoid the need for a web server on the camera and spare resources.

@BAndiT1983 yes there some stuff that i didn't optimzed yet like the icons, for that i need to make a setup.

@Francis: Tried to execute your app, but the problem is, that it relies on some stuff, which throws cross-domain errors and refuses to work. Also the font shouldn't be loaded from internet, but from a sub-folder.

Thanks, will check it, but also try to connect your app to the real websocket server from the daemon project.

@BAndiT1983 there is a simple setup where you can sent some strings to the websocket server on https://github.com/Mandrake0/Apertus_Demo_Server for the testing.

@Francis: Have committed adjusted daemon version, haven't tested websocket server yet, but will try to do so using your code. At least to see, if responses are coming back to it.
@sebastian: Will try to add some parameters from your list, as example.

Current plan is, to get things up and running sooner, to use manual string conversion (docs will follow), as we use JSON and flatbuffers. Later it can be extended. Another point is, where i'm not sure about, but will follow for now: to set and get things, the parameters should be prepend with "set_" or "get_", e.g. "set_gain" and daemon selects correct handler method. Other approach to this, would be a path of REST, where the command is set explicitly, e.g. for JSON: command: "set", parameter: "gain".

I started a google doc so we can collect actual/abstracted potential parameters and possible values/ranges:
https://docs.google.com/document/d/1avhqneK2whvau_XBEGza_ujum8SB4EgMCl6i5aC9e18/edit?usp=sharing

sounds perfect :-)
take your time....

No problem, trying to help when i can, so we get simpler camera control soon, as many people are afraid of terminal usage, which can be confusing sometimes.

thank you for the information.

hi, daemon is being adjusted currently, so it responses correctly to the frontend. Following list should cover your questions:

hey all,

made a small update: https://vimeo.com/289786668

at the moment the ID is just a unique value (example: "_id": "id_08" ) it could be made with a hash value it doesn't matter for the interface.

Which IDs are involved? Can we generate them as hashes, automatically?

@BAndiT1983 it should be possible to do that just the ID must be unique over all files.

Hi Francis

Just out of curiosity: Won't this file be too cluttered after defining multiple pages and related controls? Could we use multiple files, like one per dialog/menu, in that case?

hey everybody,

We haved chosen the 2.8" capacitive TFT from adafruit: https://www.adafruit.com/product/1947 for now.

perhaps we should change the title of this thread - or move it to "websockets" REST doesn't seem to make sense anymore...

So I have "implemented something" - the frontend for the WebRemote and worked with the team today to design a spec. But I would still like @jatha to show some evidence that suggests that "the camera has plenty of resources". I find this hard to believe (its only a relatively low-powered dual arm!!!) and only benchmarks running during a camera state where it is filming and executing scripts could change my opinion. (Or alternatively, a video of htop screen.)

Working spec document

We unified the Control software, its now called "AXIOM WebRemote" (also moved it to the correct folder on github):
https://github.com/apertus-open-source-cinema/beta-software/tree/master/software/http/AXIOM%20WebRemote
https://wiki.apertus.org/index.php/AXIOM_WebRemote

For the Controller/WebGUI/ControlGUI its currently me and @BAndiT1983 working on it. The current state is https://github.com/apertus-open-source-cinema/beta-software/tree/master/software/control_daemon/ControlGUI
Concepts are here: https://wiki.apertus.org/index.php/Wifi_Remote

So, I know that there is no Loomio decision making process here (our 150 person non-profit in Hamburg - the Gängeviertel - tried it too, with results similar to your experience...) but I still need some guidance from the core-team on how I should move forward and contribute. I can build everything I wrote about in the CONTROLLER, INTERFACE and DAEMON sections, but it is a considerable amount of work and will take some careful planning and integration...

@sebastian sorry about the Terminology. (You did although just call it WebGUI and then link to ControlGUI...)

When you say "Controller" do you mean the WebGUI ?
http://files.apertus.org/AXIOM-Beta/ControlGUI/
https://github.com/apertus-open-source-cinema/beta-software/tree/master/software/control_daemon/ControlGUI

I like some of the ideas over at snickerdoodle - especially their app-connectivity. Maybe there are some good ideas over there too...

The ball is on your side. Implement something which fits the requirements and we can test it on the Zynq, to see how it behaves.

I am seeing two different perspectives here, and just would like to have some clarification - or even better some benchmarking stats. For your information I have done work on arduino, raspberries, Olimex a20-SOM / LIME (including custom flashing of the NAND), Banana-pi and the O-Droid C-1 - so I am VERY aware of paying attention to system resources and the tough design decisions that come with that.

It went not well, while GSoC2017, without going too much into details. So i've resumed the work on the daemon, REST server and GUI. The goal is to get rid of scripts to get performance gains. Don't underestimate it, it's an embedded CPU, resources are sparse. There is a reason why C++ was used.

Ok - I've noted what you said @jatha - thanks for the info. Can you tell me where to find the spec for the openAPI and Plugin Modules?

If i remember correctly, then most of this things were discussed with Herbert for the daemon, which was a task for GSoC2017. If you can get it through bash script, fine, but i'm rather sceptical about the performance. Surprise me.

There are some things, that are good to consider, when we build something like this:

• The camera has plenty of resources. When designing something that only works on the parameters, and not on any image data it is almost impossible to design a system that is to imperformant to run on the cam. This means no performance optimisation is needed.
• The software has to work without requiring internet access at all. (in my opinion) I think it would be handy if everything is served from the camera.
• The software should manage the state of the hardware (is the fpga configured? what bitstream should be loaded? what bitstream is loaded? what plugin modules are plugged in?
• New Plugin Modules should be easy to integrate (new bitstrams and new parameter space)
• An open API should be exposed to allow other interfaces (maybe hardware) to be easily developed

It is planned, but wasn't done yet, as we have lack of people, who are involved in practical way.

I thought I read somewhere that there is a virtual machine image that I should use to spin up development... Maybe I imagined that.

Which VM image?

Challenge accepted. Can you point me to a resource for a current VM image?

Daemon was started, amongst other things, to remove the need for that folder at some point in time. Feel free to implement something, which could replace current approach.

Then maybe a single long running bash script with a high priority / nice-value running as a main control interface that listens for changes to the fifo and where necessary modifies the fifo / and non-volatile file-store for use on startup for init and conf...

The goal is to avoid to use bash which spawns a lot of threads and to have a central point which should do the configuration and initializations.

We can also think of using an EDP display (e-ink display, like in e-book readers), which consume very few energy. The refreshing rate isn't very fast, but for the remote, we don't need something very fast.