Why this project exists
Umfeld is an environment for audio- and graphics-based applications.
To state the obvious, technology’s scorching speed of progression can, in one way or another, play an intrinsic role in how creative works are produced and distributed, and of this means the workers of art are obliged to pivot towards computational literacy now more than ever.
“Computer programming, once an esoteric skill in engineering and business, has now acquired broad applicability in fine arts, design, architecture, music, humanities, journalism, activism, poetry and many other creative fields.” (Brain and Levin, 2021:2)
Now, to answer the titular question, “why this project exists?” we should point our valves of attention towards a multitude of reasons:
- In today’s climate, the invasive role of big tech companies and their detrimental impact on different societal, economic, political, etc. aspects of our lives. Umfeld is proposing a move away from its evil twin, “Processing,” which is built on top of a verbose and heavyweight programming language called Java, owned by a major Silicon Valley company called Oracle. Apart from the major software engineering setbacks that Java imposes on the developer’s/artist’s experience, especially when it comes to running code on embedded systems, Java is following a software principle called Object-Oriented Programming (OOP).
“Software and Ideology fit each other perfectly, because both try to map the tangible effects of the intangible and to posit the intangible cause through visible cues. Both, in other words, promise a vision of the whole elephant. Through this process, the invisible whole emerges as a thing, as something in its own right, and users emerge as mapping subjects.”
Umfeld is a C++ variant of Processing.org. Umfeld aims to supply a framework that allows writing applications that more or less look and feel like Processing.org sketches (or in developer terms, Umfeld provides a Processing.org-style API for C++). Umfeld might partly replicate but not fully emulate the original Processing.org environment. Features will be added as they are needed.
Umfeld may also function as an opinionated statement on what is good, valuable and worth preserving about the Processing.org idiom while at the same time disconnecting from one specific group, application, device or project … maybe a bit like markdown in that sense. Not in an angry but in a diverse, caring, and resilient manner.
Why Umfeld?
Umfeld is yet another programming environment for designers, makers, and artists. So why
does it exist? And why not use Processing.org, OpenFrameworks, Cinder or any of the other
frameworks out there? Well, the main reason why we even created Umfeld was basically to
have a C++ derivative of Processing.org that stays very close to the original idiom. While
Cinder and OpenFrameworks, for example, are fantastic projects, they differ quite a lot
from the Processing.org idiom (i.e. a setup()–draw() structure, stroke()+fill()
and shape-based drawing, etcetera). Umfeld, however, literally imitates core Processing
classes and functions.
Why not use the original Java-based Processing.org then? There are a few key aspects that just cannot and probably will never be resolved due to limitations imposed by Java. While Java is a very well-designed language and does many things better than C/C++, it has some drawbacks.
The most important benefit of moving to C/C++ is the availability of many extremely powerful and widespread libraries and APIs (e.g. OpenGL, OpenCV, FFmpeg, PortAudio) that can be natively used and integrated into applications and sketches without the need for a native binding library. While many of these libraries have been fully or partly made accessible in Processing through native bindings, oftentimes these libraries or their bindings introduce significant overhead (technically, administratively, etcetera), are not at the current version, are incompatible with newer versions of OSes, or do not expose all functionality (e.g. unstable webcam support on macOS). While this also happens with C/C++ libraries and APIs, the problems are greatly reduced. Also, there is still a significant number of libraries and APIs not available for Java-based Processing or that are impossible to port because of limitations posed by Java VM implementations (e.g. multi-channel audio).
In addition to this, due to the nature of C/C++ and the way Umfeld is implemented, applications and sketches developed with Umfeld can be built and deployed with a very(!) small memory and CPU footprint. This means that applications and sketches can potentially run on smaller or older hardware like, e.g. Raspberry Pi. Some modules can even be excluded from builds to reduce the footprint even more. Umfeld is very flexible and therefore can run truly headless (i.e. it does not require any virtual offscreen graphics driver if no window is required).
Furthermore, Umfeld uses CMake as a build system. CMake is very well-designed and rather easy to learn and extend. This also means that Umfeld applications and sketches can be developed in any text editor or in more or less any IDE (e.g. Visual Studio Code, Zed, CLion, Vim). It does not require proprietary build systems.
And finally, although C and especially C++ is known for its horrific errors, confusing error messages, and volatile behavior at times, with the advent of LLM-based programming assistants, the entry threshold can be greatly reduced. Trust the process.
Umfeld was initiated and is developed and maintained by Dennis P Paul (Benevolent Dictator for Life). Please get in contact if you are interested to join.
g, width/height...
PVector, PShape...
line(), ellipse()...
Movie, MIDI, OSC...
math, time, IO...
hooks: init • update • draw...
polled in core
GL 3.3 / GLES
UShapeRenderer, VertexBuffer, PShader...
cd umfeld-examples/Basics/minimal
cmake -B build
cmake --build build
./build/minimal