"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

and new photo of old power board for archives :)

I created a shared spreadsheet:
https://docs.google.com/spreadsheets/d/17FiaQxwKBTbP1t0Iua9Xyq5i45lsOYK3BC7DHyIfpPo/edit#gid=0

another candidate: https://www.indiegogo.com/projects/renegade-elite-the-revolutionary-mini-computer-computers-pc

I created a wiki page for the Coding Guidelines, https://wiki.apertus.org/index.php/OpenCine.Coding_Guidelines

The git commit hash and the date of the last update of the software (beta-sofware repo) is already displayd at login through /etc/motd. This can be different from the creation commit / date of the firmware, but these can be easily added as well. The standard disclaimer can also be added in the same place.

Possible framework, as replacement for ImageMagick: http://www.graphicsmagick.org

more points for the checklist:

Note the comments by one of the authors of the new automatic build system today:
http://irc.apertus.org/index.php?day=04&month=07&year=2018#160

task up for grabs again.

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

• Curly braces should be always placed, even for single lines in if()

done: https://www.apertus.org/en/opencine

Well done!

Page 1 - Fixed
Page 1 - Fixed.
Page 4 - Fixed.
Page 6 - Too much effort to do this (Although what you described was what I did on the previous version) / New image in pipeline.