I’m building a midi controller and a 5" display for monitoring all the actions I make with the controller. For the moment I have a Raspberry pi 3 and a hdmi 5" display for it and my objective is to make a user interface for the display.
I’m here because after searching a lot of devices with graphics displays, different programming techniques and languages and asking in a lot of forums I ended here:
For me, the op1’s graphical interface is the most inspiring thing I’ve seen in a long time as a graphic designer and rookie programmer. So, I want to make something similar in my controller (a lot more simple of course), not to copy it but for being able to take my adobe illustrator vectors and animate them, do a graphical interface with the outline style of the op1 with smooth transitions, fading color effects etc…
Anyone knows what I need to program a display like this? (Languages, frameworks, etc…) I will learn anything I need to learn from the beginning but I need to know where to start…
The look of the display is all vector graphics. The images are saved in the OS – not generated on the fly (I don’t believe). I don’t think there is really anything particularly unique required to get the underlying nature of the graphics to work. You should probably just go with something that works nicely with what you are already doing, and then just build the graphics that work with that.
All of the graphics are SVG files made in Adobe Illustrator. * All parts of the image which should be dynamic are grouped and have IDs in the SVG * There are two ways to animate them:
Simple: Including all stages of the animation already in the SVG file, only switching them from “display=none” to “display=block” and vice-versa (best example is probably the SVG for the “Finger” sequencer which we exchanged with Deadmau5 and Animal)
Complicated: Actually calculating new vectors depending on what is happening in the device and writing them to screen (best example is maybe the “string” synth engine with the movement of the individual strings. Those are not all included in there but really animated)
@JackBlue: I would decide on a programming language and framework to work with on the RasPi and then find a good SVG manipulation library for that.
This way you can do it like TE and separate the “programming” from the graphics work a bit. (still have to coordinate usage of IDs and such, but you can change graphics without re-compiling all your code)
Thank you guys for your answers. Yes, I saw that deadmau5 modification, as a deadmau5 fan you deserve all my respect man!
About the svg files, I understand, but, how I tie together all the svg and program them? I mean, which language do you recommend me to work with svg files and create graphic interfaces for a device like a raspberry pi based device?
I’m very lost in this aspect because I’ve never programmed user interfaces, only back-end programs, so I don’t know what to use…
What language are you using for everything else? Like, to make the sequencer program work? Because that would narrow down your options if you want everything to work together more cleanly. For example, Python has its own libraries for creating GUIs that may not be the same as Java or others.
For the moment I’m not using one in particular, I’ve been using python with tkinter in the past months, but I think I need something more powerful for doing that kind of interfaces with smooth transitions and all kind of fadings and fx. I’ve seen that a lot of good interface programs use c++ in combination with svg objects.
depending on the svg library there are a great number of svg features from transforms (rotate, scale, etc), through symbols and text that help with building UI.
UI is hard on the whole, transitions are harder, especially if you’re doing the graphics codework on the metal directly. UI on any realtime machine needs to run on its own thread… definitely calls for a library of sorts.
I thought someone here mentioned the specific svg library TE use, sorry I can’t remember who? Vector software like e.g. Affinity Designer, Inkscape, or Adobe CC can export SVGs (human readable in most cases). Preprocess most with ‘svgo’ to decrease their size.
filesize shouldn’t be much concern on a RasPi. Choose readability and debuggability over small file size! * from the “strings” analysis of OP1_vdk.ldr, they use “…\src\gui\3rdp\rapidxml-1.13\rapidxml.hpp” so the rapidxml library to parse the SVGs I guess (“source”/“graphical user interface”/“third party”/) * The rest of the gui seems to be done by hand (in …\src\gui\lib, like Parser.cpp, Raster.cpp, Node.cpp, Shape.cpp… which is quite impressive * there is also “…\src\gui\lib\AGG\agg.cpp” which may or may not mean something like this: http://antigrain.com/download/index.html. But since they neatly organized their source as it seems, I would guess that it would be in \3rdp\ if it came from a thirs party and wasn’t coded by TE
Thank you very much guys, I’m starting to see things clearly! Your posts are helping me a lot!
So now I see… You design a svg and then export it to be programmable code. Then the op1 uses the code with graphical libraries for c++ (I guess it’s in c++ because of the .cpp format that you mention) and has a gui folder where the exported svg, libraries and c++ code for the gui are contained. And that’s all for the gui right? Maybe they use more complex libraries for the svg animations and other things like the tombola (2d physics libraries for example…)
@JackBlue yes and no. The SVG format ist already “programmable” because it is an XML format which can be parsed by computers. TE seems to use the rapidXML library for that. Then their whole magic is in /src/gui/lib/ where they “Parse.cpp” the SVGs (using the rapidXML lib), then they “Shape.cpp” and “Node.cpp” it (kind of) and finally when they need to display it on the pixel-based display, the “Raster.cpp” the SVG to show it in those tiny pixels.
For Tombola and the Chopper game, they use the open source “Box2D” physics engine.
@JackBlue yes and no. The SVG format ist already "programmable" because it is an XML format which can be parsed by computers. TE seems to use the rapidXML library for that. Then their whole magic is in /src/gui/lib/ where they "Parse.cpp" the SVGs (using the rapidXML lib), then they "Shape.cpp" and "Node.cpp" it (kind of) and finally when they need to display it on the pixel-based display, the "Raster.cpp" the SVG to show it in those tiny pixels.
For Tombola and the Chopper game, they use the open source "Box2D" physics engine.
Ah okey, the rapidxml lib makes the svg graphics usable in c++ and then it renders the vectors into pixels to finally show them in the screen?
So I guess the agg library it’s in the middle of this process, between the parsing and the rastering right? Seeing it’s documentation, I thought the agg library could handle all the work from the start to the end.
there is no indication that the /AGG/agg.cpp has anything to do with that agg lib. Only those three letters. It could also be their own implementation of an anti-grain algorithm while rasterizing the SVG to pixels. Given that they have a /3rdp/ directory with third-party libraries, I’m pretty sure that agg.cpp is not coming from an external entity.
So again:
SVG is just text. And it is formatted in the XML format
the Firmware needs a way to read all that text efficiently and find the relevant parts in it (i.e. paths/vectors, colors, etc)
To achieve this, the GUI library that TE created uses rapidxml library which takes away the pain of writing code that knows how XML looks (i.e. search for “<”, then check what “tag” that is, keep in mind what tag came before that and build a “tree” where in the XML document you are right now, check for closing “>” and so on)
I would guess that “Parse.cpp” uses the API of rapidxml to find in the SVG what the shapes and nodes are.
Shape.cpp and Node.cpp describe what those are and what functions they have (Classes in c++)
Raster.cpp uses agg.cpp (just a theory!) to make the SVG look good on the pixel screen
Also, what I haven’t mentioned in my previous post: All screens you see on the OP-1 also have code attached to them. Those reside in /src/gui/screens/ and contain the code that is needed to manipulate the SVG to achieve animation (also theory, but pretty sure about it)