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:

Yes, but currently no time to fix it. Will try in the next days, if some spare time is there.

I can't reproduce the problem anymore so I guess its fixed, ready to close task?

@BAndiT1983 can you reproduce this problem?

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.

and more candidates:

@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.

Mobile internet allows cameras to become live broadcast studios anywhere there is coverage so while not a primary cinematography application definitely a TV camera application :)

"... the cool thing about the mushroom is that it can multiplex.

Could it be spam? As i don't see any purpose for 3G/4G in a camera.

"Make room for a 3G/4G multiplexer from Mushroom Networks in that extended beta version and it will be awesome!" - From G+

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,

added links to recent gsoc article and beta modularity for two slides.

Adjusted behaviour on the test node, please check IRC logs, so i don't have to post link here for now.

verfied working! Thanks!

Fixed.

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,

Do you have foto-documentation of the build process online? And/or footage?
I would love to see your 3d prints and early assembly's :)

whereever it makes sense

This won't always be possible. Or making sure that they do in some instances would require a lot of work, ie. specific pages being created. The slides aren't even final yet, so, noted, but put it on the back burner.

Note that the AXIOM Remote and the web based control GUI (for smartphones, etc.) are two completely independent projects.

This was forwarded in IRC:

In my opinion, I think an ND filter for the AXIOM is necessary. The option of the electronic ND filter integrated into the body of the camera is the best option :)

look at this A7sii Mod: http://www.centralds.net/cam/?p=7911

i like your approach a lot!
the super8 idea ist great, especially for artists and hobbyists who want to get in touch with AXIOM.
Also this has the opportunity to get people on board because it is a low threshold first contact to the project.

Some updates on this front:
Last ccc @vup @leftshift and me decided to build a cheap development version of the Beta.
We wanted to have a cheap camera to be able to develop soft- and hardware for the Beta without the need to invest a lot of money.
Research was done, the cheapest Zynq FPGA development board was found, the cheapest suitable CMOS with okayish documentation was picked and we designed a first Interface PCB to connect the sensor to the FPGA dev board. We build FPGA designs and wrote some software and in the end we had the first still images. The first prototype of the AXIOM micro was built.
However, the initial PCB was quite rough and had major problems (we were doing serious PCB design for the first time in our lives).
This led us to the creation of a second revision, which now is able to shoot moving images, has a proper lens mount and some case.

Obsolete

Obsolete

We found this.

Added storing of last directory, when file was opened. Cannot reproduce other problems (Manjaro, XFCE).

Davidak reported that the newsletter display is missing all text, he is using OpenExchange at mailbox.org.

A proof of concept that MLV can work for us can be found at: https://github.com/supragya/AXIOM_RawStreamHandler