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

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