#apertus IRC Channel Logs

morning folks!

hey everyone, I was curious if I can contribute with the knowledge of C++ ?

aniketonroll: what is your area of interest?

off for now ... bbl

currently we have some active C++ development for the AXIOM Remote -> https://wiki.apertus.org/index.php/AXIOM_Remote

repo: https://github.com/apertus-open-source-cinema/AXIOM-Remote

if you want to try it, then please use the vis_adjust branch, as it's newer at the moment, but dev branch will be updated soon, we just had no time to merge other changes form forks etc. yet

so are you the mentor of this organisation?

hi xthenode

use the apertus hardware and os to build the code

vivado?

xthenode: what cpu / other spec of the board ?

xthenode: you can build kernel and userspace on the MicroZed, although it takes quite a while ...

i currently build on the pi which is arm

dont agree

for a dev/user separation, it makes no sense. But if you think of all users are devs / skilled tinkerers, i appreciate the Gentoo approach

(using the still very wip xilinx nextpnr support one could theoretically build some bitstreams on ARM, not sure how far one would get with our gateware though)

cross-compiling is outputting a binary for other arch, it IS NOT a performance hit in any sense

just a suggestion

arm

dont care

as long as a linux dev env that generates code that con be run on the camera..

i use make and qt creator on pi 4. plenty fast.

providing a cheap dev board would encourage dev for the camera

I don't see how providing a dev board would make thing easier than we already have here: https://github.com/apertus-open-source-cinema/axiom-firmware

its linux. rebuilding the os is not necessary for most system and application software

it would only be for development

(also the firmware is a lot more than just linux, it also compiles a lot of other software for the camera, like the control daemon, various tools used to control the camera, development tools, etc)

if set-up properly, modules can be used for drivers

i would suggest to xthenode to make a benchmark, and show the improvement factor

now if you are talking about a cheaper version of the camera that could be used for development, this is what the https://wiki.apertus.org/index.php/AXIOM_Micro is about

if it can be like a pc with desktop env. awsome.

Well software wise it runs arch, so you can do what ever you want, no gpu though, so if you mean a graphical desktop by "desktop env", it will be painful (also no native video output, but we got a linux framebuffer via HDMI working with a HDMI plugin module)

well i would say upping this product would be a great way to promote apertus

kinda like musk landing that rocket on its butt.

pi4 is good, but it's still a small-scale thing

although the 3d stuff on it was impressive, have used it a couple of months ago for another open source project

i could work on it.

i know slow

it's always relative, back then it was all fast

will ever need more than 640k...

xthenode: so if you want to work on the micro, what are your areas of expertise? The gateware is written is a python DSL named nmigen, software is currently python + rust mostly, hardware is done in kicad)

SolidWorks, Autodesk and Orcad

cpu design using bit-slices

i started just wanting to do CAD to design motorcycle parts which ended up being an odyssey

did you see my email?

xthenode: yes, email is there, am just working so can only react sometimes, have to finish some stuff before the year ends

qt company wants to slow down the releases for community, so looking for alternatives or maybe even a webapp, which uses the core

did you like the server name idea?

just kidding, vapoursynth is also a good product out there

in a whole theory of opposites way...

xthenode is a web-based ui used to generate code and project files

Then there is https://github.com/apertus-open-source-cinema/axiom-control-daemon, not sure what the plan is with that going forward

the actual daemon is less important than the apis and transports used to talk to it

if there is already one which is actively developed, have just put the old one into hibernation mode for now

We have been thinking about using flatbuffers for serialization over network, API wise its not too fleshed out, the current state of the flatbuffers API is documented here: https://wiki.apertus.org/index.php/Control_Daemon

The rust control daemon just provides a fuse filesystem, which the webui looks at using basic programs like `find` :)

protobuf

protobuf

have also create a fix/improvement for the Go version some years ago, when we were the first time joining gsoc, but heard nothing from the maintainers

node.js rocks though...

kicad does it for the C++ to Python, so one can use their api from python, works rather good, docs are meh, so mostly googling for examples or reading source code

so is json to slow for transport?

I would like a transport with a strong schema, which json doesn't really provide on its own.

also deserializing there is not that CPU-heavy

I guess if you do JSON + a schema I don't see why one would not do something like flatbuffers

json = xml kinda

JSON is much smaller, as it's doesn't repeat the tags, like XML does

and i just remember my current struggle with SOAP (XML), then i would prefer flatbuffers, then JSON and XML at last

xthenode: json and xml are very different, xml has builtin support for for schemas / validation, json does not have that

:)

i would say. focus on the api

similar to the rest api generator i did for verizon.

might want to consider a web-based one for apertus

what do you mean by "web-based one"?

good night