DEV Community: jj

Aphelion Editor - A free node-based video / VFX editor

jj — Mon, 21 Sep 2026 05:21:16 +0000

Introducing Aphelion Editor: An Open-Source Node-Based Video Editor

I’ve been working on Aphelion Editor, an open-source, node-based video editing application built around the idea that editing video should feel more programmable, visual, and flexible.

Instead of organizing everything around a traditional timeline, Aphelion lets you build your video processing pipeline using nodes.

You connect inputs, effects, transforms, tracking, audio, and output nodes together to describe how your final video should be produced.

GitHub: https://github.com/aphelion-engine/aphelion-editor

Why I Built It

Most video editors are incredibly capable, but their workflows are usually centered around timelines, tracks, layers, and panels.

I wanted to experiment with something different.

What if editing a video felt closer to building a shader graph, Blender node tree, or visual program?

That idea became Aphelion.

The goal is not just to make another basic video editor. I want Aphelion to eventually become a serious node-based environment for compositing, effects, motion graphics, tracking, audio processing, automation, and general video production.

How It Works

Aphelion represents a project as a graph.

A simple workflow might look something like:

Video Input
    |
    v
Transform
    |
    v
Color Correction
    |
    v
Sharpen
    |
    v
Video Output

More complex projects can branch, combine multiple sources, reuse processing chains, and expose parameters that can be animated over time.

This makes the structure of an effect much easier to see.

Instead of hunting through several menus to figure out what is happening to a clip, you can follow the graph.

Current Features

Aphelion already includes a growing set of editing and compositing functionality.

Some of the current features include:

Node-based project graphs
Video input and decoding
Audio decoding and playback support
Frame-by-frame evaluation
Image and video processing nodes
Animatable numeric and slider properties
Keyframing
Point tracking
Planar tracking work
Exposure controls
Horizontal and vertical flipping
Frame offsets
Playback speed controls
Source FPS handling
Video fitting modes
Media metadata probing
Plugin support
Project validation
A custom .aph project format
A growing built-in node library

The editor is written primarily in Python using PyQt6, with NumPy, OpenCV, FFmpeg-based media tooling, and other libraries handling the heavier media processing work.

Tracking

One area I’ve been spending a lot of time on is tracking.

Aphelion currently has point-tracking infrastructure that can follow features through a sequence of frames.

The longer-term goal is to make tracking data reusable throughout the graph.

For example:

Video Input
     |
     +------> Point Tracker
     |             |
     |             v
     |        Tracking Data
     |             |
     v             v
Transform <---------
     |
     v
Output

That opens the door to things like automatically attaching text to objects, stabilizing footage, following faces or objects, masking moving regions, and driving effect parameters from tracked motion.

Audio Is Part of the Graph Too

Video editing is not only about frames.

Aphelion's evaluation system can carry synchronized audio alongside video, allowing nodes and playback systems to work with both.

Internally, evaluated media can contain a video frame along with an audio sample slice associated with that frame.

That architecture should eventually allow dedicated audio nodes for things like:

Gain
EQ
Compression
Filtering
Mixing
Audio-reactive effects
Waveform visualization
Automation

I want audio to feel like a first-class part of the editor rather than something bolted onto the side.

Plugins

Another major goal is extensibility.

Aphelion includes a plugin system so that the node library does not have to be limited to whatever ships with the editor.

Eventually, I want developers to be able to create their own nodes for things like:

@node
class MyEffect:
    def process(self, frame, intensity):
        # custom processing
        return frame

That could include effects, generators, AI tools, codecs, analysis nodes, automation tools, custom UI controls, and more.

A video editor gets dramatically more interesting once users can extend it themselves.

Performance Is One of the Biggest Challenges

Building the UI was not the hardest part.

Making a node-based video editor actually play video smoothly is.

A graph may contain several expensive operations for every frame:

decode
 -> resize
 -> transform
 -> tracking
 -> blur
 -> color correction
 -> compositing
 -> preview

At 60 FPS, that entire pipeline has roughly 16 milliseconds to complete if you want real-time playback.

Python makes prototyping incredibly fast, but it also means I have to be careful about where processing happens.

I’ve been working on things like caching, prefetching, asynchronous media decoding, lower-resolution previews, reducing unnecessary graph evaluation, and moving expensive operations into optimized native libraries.

Long-term, I also want to explore GPU-backed processing.

There is a lot of optimization work left to do, but honestly, that is one of the parts of the project I find most interesting.

The Project Format

Aphelion projects use a dedicated .aph project format.

A project stores information such as:

Nodes
Connections
Node properties
Media references
Animation data
Project configuration

The graph is also validated when projects are opened to help catch invalid or broken connections before evaluation.

The format is still evolving as the editor grows.

Where I Want to Take Aphelion

There is still a huge amount I want to build.

Some of the areas I’m interested in include:

GPU-accelerated effects
Better real-time playback
Advanced compositing
Masks and rotoscoping
Motion tracking
Better planar tracking
Motion graphics
Text and typography tools
Audio processing nodes
Proxy media
Render queues
Background rendering
Custom node scripting
More plugin APIs
Color grading tools
LUT support
Hardware encoding and decoding
Improved caching
Optical flow
Time remapping
Expressions
More advanced animation tools

Ultimately, I want Aphelion to sit somewhere between a video editor, compositor, and visual programming environment.

Open Source

Aphelion is open source, and that is a major part of the project.

I want people to be able to dig into the code, experiment with the architecture, build nodes, improve performance, fix bugs, and shape where the editor goes.

There are a lot of interesting problems involved in building something like this: media decoding, caching, graph evaluation, synchronization, rendering, UI architecture, tracking, audio, plugins, and performance.

If any of those areas sound interesting, contributions are welcome.

GitHub:

https://github.com/aphelion-engine/aphelion-editor

Download from the Website:

https://aphelion-community.com

The project is still early, but it has reached the point where it is becoming something much bigger than the original experiment.

I’m excited to keep pushing it forward.

Introducing Sere: a compiled language with Python-like syntax and systems-level power

jj — Mon, 14 Sep 2026 02:07:22 +0000

Today I’m launching Sere, a compiled programming language built around a simple idea:

Python-like readability shouldn’t mean giving up native performance, static typing, or low-level control.

Sere is designed to feel familiar and lightweight while still giving you the kinds of capabilities you’d normally reach for C++, Rust, or Zig to get.

A basic Sere program looks like this:

def main() -> i32:
    print("hello from sere")
    return 0

You can define structs and methods without much ceremony:

struct Point:
    x: i32
    y: i32

    def length_sq(self) -> i32:
        return self.x * self.x + self.y * self.y

def main() -> i32:
    p = Point(3, 4)

    print(p.length_sq())
    return 0

Under the hood, Sere is a native compiled language built on LLVM.

That means you can go from readable high-level code to actual native binaries:

sere main.sere -o main.exe

You can also inspect LLVM IR or generated assembly:

sere --emit-llvm main.sere -o main.ll
sere --emit-asm main.sere -o main.s

Built for more than scripting

Sere isn’t meant to be “Python with a compiler.”

The goal is to support real systems-level work while keeping the syntax approachable.

That includes explicit memory control:

owned: Unique[i32] = unique[i32](42)

*owned = 100

value: i32 = load(owned)

Raw pointers are available when you actually need them:

ptr: Ptr[i32] = alloc[i32]()

store(ptr, 123)

print(*ptr)

free(ptr)

And the language includes modern features like enums and pattern matching:

enum Message:
    Quit
    Move(x: i32, y: i32)

def handle(msg: Message) -> void:
    match msg:
        case Message.Quit:
            print("bye")

        case Message.Move(x, y):
            print(f"moving to {x}, {y}")

Tooling matters too

I don’t want Sere to be one of those languages where the compiler exists but the developer experience feels like 2008.

Sere already has tooling for:

syntax highlighting
diagnostics
hover information
go to definition
rename
VS Code integration
project builds
library packaging

Libraries can be packaged into .slib files and imported into other Sere projects:

sere init-lib mathlib
sere pack

Then:

import mathlib

def main() -> i32:
    print(mathlib.add(2, 3))
    return 0

Native interoperability is also a major part of the project. Sere is being built with C and C++ interop in mind rather than pretending the existing native ecosystem doesn’t exist.

What Sere is trying to be

The goal is not to replace Python, C++, or Rust.

It’s to explore a different balance between them.

I want Sere to be a language where this feels normal:

items = [1, 2, 3]

for item in items:
    print(item)

while this is still possible:

buffer: Ptr[u8] = alloc[u8](1024)

High-level when you want it.

Low-level when you need it.

Without turning every program into a wall of syntax.

Sere is still early

Sere is actively being developed, and I’m not going to pretend otherwise.

There are still bugs, missing features, compiler edge cases, and parts of the ecosystem that need a lot more work.

But the language is at a point where people can actually download it, write code, compile native programs, build libraries, and experiment with the design.

That’s why I’m launching it publicly now.

I want feedback while the language is still flexible enough to change.

If something is confusing, awkward, broken, or just a terrible language-design decision, I want to hear about it.

Try Sere

Website:

https://sere-lang.com

GitHub:

https://github.com/Sere-Language/sere

Sere is open source, and contributors are welcome.

If you’re interested in compilers, LLVM, programming language design, systems programming, or just trying new languages, I’d love for you to give it a shot and tell me what you think.

Python-like syntax. Native compilation. Systems-level control.

That’s the direction I’m building Sere toward.