I cloned the FAQ page and converted it to the new design: https://www.apertus.org/node/552
Tue, Nov 13
Thanks. While we're at it can we make the same allowances on the Wiki please?
Mon, Nov 12
just checked for slide control and seen some solutions but i need to investigate more into it. what i have done is a have autoupdate so you don't need to close the modal window and it should be possible to use the arrow keys for change the values (up/down).
Should be fixed now, please check.
Sun, Nov 11
Sat, Nov 10
i changed on the end from the IRC Meeting the data.json for your requirements.
Did just few adjustments to web-remote, it communicated almost right away with the WSServer and daemon. Noticed 2 things which should be adjusted:
Fri, Nov 9
Agreed on the internal ND filter. Whether it's an electronic, variable, or rotary disk style, it's incredibly handy to have. Especially on cranes and gimbals. It could also breed greater functionality and cause for use of the remote control in those situations. Lack of behind the lens ND has made some RED rigs much larger than what would be preferable in some tighter scenarios as well.
Wed, Nov 7
Yeah the landing page is an issue. Unfortunately the key people who're in the process of its reformatting are currently engaged with the camera's UI and it's pretty important that they're not disturbed.
The reason it is hard to join the Apertus community in a way that is meaningful to being beneficial in any way is not the lack of a CoC.
Drawing attention and doing meaningful things with it fails because there is no landing page explaining why the project is different.
For what little impact I have had, I really want to avoid contributing anything to a CoC-project. Also making that landing page and
trying to reorganize the wiki turned out to be unwanted effort, so maybe I am wrong and this CoC is the sign of a project that really
knows what it is doing, and there is a real community behind it.
"people express interest in joining our community and wanting to contribute but it does not work out in the end, they disappear again - often soon after making first contact. We never know the reasons and don't have the resources to follow up with all of them." - SP.
Tue, Nov 6
CHANGES TO TASK DESCRIPTION
Mon, Nov 5
So I am answering in a context where this CoC already applies?
I don't really care to read it extremely carefully, for the same reason I think it fails already in general at this point of entry.
Why is this needed, and what does it do?
Sun, Nov 4
First version done: https://www.apertus.org/code-of-conduct
Thu, Nov 1
Maybe this one is better -> https://github.com/ygoe/msgpack.js also consider gzipped versions, where your 50kb file is only 14kb big.
Mon, Oct 29
It's lovely all around. Note how they deal with a large sitemap on mobile.
Thu, Oct 25
Just as a reference for the future: Usually our JSON packets will be very small, but if we consider to sent larger packs in the future, like restoring some user profiles (no point to sent individual settings, if there are a lot of cahnges) or when receiving the response with all available stuff in the camera (which i expect to be rather big), then we could consider to use MessagePack, to reduce the size -> https://msgpack.org
Wed, Oct 24
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.
Tue, Oct 23
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.
Mon, Oct 22
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 relaoding 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. 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.
Sun, Oct 21
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) .
Sat, Oct 20
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
Fri, Oct 19
Improved a bit and fixed small problems, also added build.sh.
My proposal for GULP adjustments, started to implement, as i wasn't sure how to debug riot.js without precompiling:
Thu, Oct 18
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?
Tue, Oct 16
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.
Oct 15 2018
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.
Oct 14 2018
@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.
Oct 13 2018
@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.
Oct 10 2018
Thanks, will check it, but also try to connect your app to the real websocket server from the daemon project.
Oct 7 2018
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.
Oct 3 2018
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 :)
Oct 2 2018
"... 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+
Oct 1 2018
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".
Sep 30 2018
I started a google doc so we can collect actual/abstracted potential parameters and possible values/ranges:
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: