DEV Community: w4ffl35

Clip Studio Paint EX 1.13.2 on Linux with Wine

w4ffl35 — Tue, 06 Oct 2026 16:49:07 +0000

Clip Studio Paint EX 1.13.2 on Linux with Wine

I bought Clip Studio Paint EX 1.13.2 a few years ago and wanted to keep using it on Linux.

It opens on my Debian 13 desktop through Wine, and I was able to sign in. I wrote down the setup I used, including the XP-Pen Deco LW (IT1060B) notes, in linux-clipstudio-installer.

Wine is unofficial, so I don't know how it will behave on every system. The installer doesn't include Clip Studio Paint or bypass license activation.

What I split into public Capsize packages

w4ffl35 — Wed, 30 Sep 2026 15:15:01 +0000

I didn't set out to make a pile of tiny repos. I kept finding code that already had one clear job and could be useful outside the app where it started. This week I gave those pieces their own public homes.

The companion and social pieces are the largest group:

capsize-auth provides password, token and OAuth2 primitives.
capsize-bluesky is the AT Protocol client used by the social tools.
capsize-social handles Bluesky and Discord account connections.
capsize-voice measures a writing style and uses that profile during generation.
capsize-persona combines persona, voice and long-term conversation facts in a reply service.
capsize-memory provides SQLAlchemy models and functions for rooms, participants and conversation turns.

That was the test: does this piece have one job, and can another app use it on its own? A bot can use the Bluesky client without loading the persona service. A local chat app can keep conversation memory without knowing anything about Discord. An app can also hand capsize-memory its own database session. The package doesn't need to own the connection.

The supporting repositories cover a different layer:

capsize-commons contains selectively installable Python, TypeScript and C++ building blocks.
capsize-ci contains versioned reusable GitHub Actions workflows.
capsize-fastmail reads Fastmail through JMAP, including mailbox listing, pagination and delta sync.
capsize-github-traffic saves repository traffic history before GitHub's 14-day window drops it.

AIRunner had the same problem. I split out airunner-common, airunner-eval, airunner-native and airunner-tts-vendor. Shared code, agent tests, the native launcher and the MeloTTS/OpenVoice layer no longer need to move as one block.

A practical way to use the split

Start small. If an app only needs Bluesky, use capsize-bluesky. If it needs account storage and posting across services, add capsize-social. Bring in memory, voice or a persona only when the app needs it.

The same rule applies to AIRunner. Its launcher shouldn't own the eval harness, and the eval harness shouldn't drag in the desktop app. The split makes that obvious. It also lets each piece ship when it's ready.

I want these repos to stay small enough to read. If one starts collecting unrelated work, that is a sign that the boundary has gone bad. The point is not the repo count. The point is being able to use one part without hauling the rest of the system behind it.

The full list, including commit and release counts, is in the four-week Capsize report.

Sharing Django plumbing with capsize-commons

w4ffl35 — Tue, 29 Sep 2026 15:15:01 +0000

I published capsize-commons, then used it in sites that already existed. A shared package does not help much if every live site keeps its own copy of the same settings and health checks. Shipping it was only the start.

The Python package now carries shared settings construction, logging, health/readiness routes and small HTTP helpers. The TypeScript side is published as @capsizellc/commons. The first adopters included Capsize Online, joecurlee.com, the WXRQ admin surface and other Django sites. Each site kept its own application. They stopped maintaining separate versions of the same foundation.

The stack is deliberately boring: Python packaging, Django, a small TypeScript package, CI and trusted publishing. The technical angle is the adoption seam. A shared helper has to preserve the old site's behavior while making the next site easier to start. That means compatibility checks, a versioned health contract and a migration that can be reviewed one site at a time.

I can now fix a shared retry or settings bug once, publish a version, and update each site when I am ready.

The source is capsize-commons on GitHub. The public sites that use the pattern include capsize.online and joecurlee.com. The release context is in the Capsize four-week overview.

A practical adoption order

Start with one shared behavior that is easy to observe. Health and readiness routes are a good candidate because a smoke check can compare the old and new responses. Publish a small version. Adopt it in one site. Run the same check. Only then move the next site.

That sequence keeps a shared library from becoming a second monolith. The library owns the common contract. The application owns the reason it exists.

The first adopters are deliberately different. A project portal, a personal site and a radio admin do not have the same job, but they do need the same answer for health, settings and a few boring operational details. A shared package earns its place when that common answer gets easier to maintain without flattening the applications around it.

The package is small on purpose. It should remove repeated setup, not become the place where every application-specific choice goes to hide.

That restraint is what makes the next adoption reviewable.

How I built Capsize Online as a static Django site

w4ffl35 — Mon, 28 Sep 2026 15:15:02 +0000

I built Capsize Online to collect my public software, games and release notes in one place. I wanted Django for editing, but I did not need a live application server for pages that only change when I publish them. The site compiles the Django content into static files for production.

The site went live during the week with the shared Capsize shader identity and a tag-driven deploy path. The authoring database stays local. The production server receives the compiled output, not a running Django application. That keeps the public surface simple while leaving the content workflow pleasant to edit.

The output can live on any plain web server. Each tagged build also leaves a clear release and rollback point.

The site links AIRunner, SpikeForge, the Capsize Audio Visualizer, Capsize Games, WXRQ and my personal site. Its devlog can connect a project update directly to the repositories and releases behind it.

The live portal is capsize.online. The four-week release story is in Four weeks of building in public, with the technical project notes collected on DEV. The report links each public repository directly.

A small Django site pattern

Keep the content model small. A title, a slug, a summary, a body, a date and a publication status are enough for a useful devlog. Render the body to a static route during the build. Put the public images in the static tree and let the compiler carry them with the page.

This pattern works well for a project portal because the authoring experience and the deployment target have different needs. Django is a good editor. Static HTML is a good thing to serve.

The first version of the site was a list of links. The current version is closer to a small index of finished things: a project has a page, a release has a place to land, and a reader can move from a chart to the thing that produced it.

That is a modest job for a website, but it is a useful one. The portal does not need to explain every implementation detail. It needs to make the next click obvious and keep the project names, release pages and public work in one place.

Porting Cowboy Casino to VileEngine

w4ffl35 — Sun, 27 Sep 2026 15:15:01 +0000

I am moving Cowboy Casino into VileEngine, the C++ engine I use for retro games. Cowboy Casino is a small role-playing game about walking into a wild-west casino, learning the tables and trying to leave with more chips than you brought in.

The work is bigger than replacing one renderer. The casino is an overworld with rooms, doors, table scenes, dealers, save slots, character movement, dialogue and an ending. The native port now has the campaign map, collision and visibility layers, the table sessions, versioned persistence, converted art and new audio loops for the casino floor and boss table. The release build is the next milestone.

VileEngine supplies the C++23 runtime, SFML presentation, miniaudio, the CRT treatment and the editor tools around them. Cowboy Casino supplies the content and the rules. Keeping those responsibilities separate makes the port easier to test: the engine can improve its scene and audio work while the game keeps its own campaign state and table logic.

The original game is available on itch.io, and the public project map is on capsize.online. I will add the remake download there when the release build is ready.

What makes a port feel like the same game

The first pass is not the final screen. It is the return path. Walk from the casino to a table, finish a round, return to the same room, save, quit and load it again. If those transitions keep the wallet, position and campaign state intact, the port has a foundation. The visual polish can then move forward without hiding a missing game rule.

The next public milestone is the remake release. Until then, the itch page remains the right place for the original download and the repository is the right place for the engine work.

The port also gives VileEngine a real game to push against. A scene stack, an editor, audio and a CRT pass are easy to discuss in isolation. They become useful when a player can walk through a casino, sit down at a table, finish a round and return to the room they left.

That is the standard for the release candidate. The screen can change later. The game has to remember what the player did and bring them back to a place that still makes sense.

Building the Capsize Audio Visualizer with C++ and Qt

w4ffl35 — Sat, 26 Sep 2026 15:15:01 +0000

I keep coming back to the Capsize Audio Visualizer because it is small enough to finish. It is a C++ and Qt desktop application that turns live audio into shader-driven scenes, with controls for changing how the signal affects the picture.

This week it picked up CRT presentation work, floating mode, cross-shader audio mappings and three releases. The project is written in C++ and Qt with a native audio path and a collection of shader-driven scenes. The visual identity is not a web-only skin. The same shader language and palette now appear across the desktop app, the public site and the other Capsize properties.

Floating mode is a small feature with a large effect on how the application is used. The visualizer can sit beside another application instead of taking over the whole screen. Cross-shader mappings make the audio signal feel like one input to a set of related scenes rather than a separate toggle in every effect.

Try the public build at av.capsizegames.com or see the desktop edition on itch.io. The full four-week overview is on capsize.online.

A useful way to extend it

Pick one audio feature and map it to one visual parameter. Keep the mapping visible in the shader or effect configuration. Then add a second effect that responds to the same signal in a different way. The result is easier to tune when the signal path is shared and the visual differences live at the edge.

That is the balance I want from the project: a small program people can use tonight, with enough structure that the next visual idea has somewhere to go.

The public build makes the idea easy to test. Start a track, put the window beside another application, change the mapping and watch the same signal move through a different scene. If the effect needs a paragraph before it makes sense, the effect probably needs another pass.

The release work also keeps the boring edges in view: a local queued build, a repeatable package and a public page that explains what the download is. A visual tool gets better when the distance between changing a shader and trying the result stays short.

WXRQ turned a production kit into a radio station

w4ffl35 — Fri, 25 Sep 2026 15:15:02 +0000

I started WXRQ as a new repository for an automated radio and television station. Within a few days it had a public player, a schedule and a production path from written script to an HLS stream.

The production kit writes and checks a script, renders several voice takes, chooses a take for each line, adds a music bed, schedules the result, encodes it and sends it through HLS. The television channel has its own transport. The public site shows the player and schedule. The admin lets the production work be browsed and edited. The lecture pipeline turns CC BY textbooks into narrated courseware, so the station is not limited to one kind of show.

The stack is a mixture of Python, Django, Chatterbox, LMMS, NVENC and a small web player. Each tool has a job. The script gate catches problems before a voice is rendered. The voice path can compare several takes instead of accepting the first file that came back. HLS gives the public channel a normal streaming surface rather than a private development endpoint.

The station reached 0.6.13 during the week. You can listen, see what is on air and check the schedule at radio.capsize.online. The wider release story is on capsize.online.

Build a small show

Start with one short segment. Give it a beginning, a change and an ending. Run the script checks before you touch the voice pipeline. Render more than one take only when the line needs it, then keep the chosen take next to the script and the reason for choosing it. Add a bed that supports the scene instead of competing with it.

That small loop is enough to learn the system. After that, add the schedule and the public player. A station becomes a product when someone outside the repository can find the show, hear it and know what comes next.

The station is still small, which is exactly why the pieces are easy to see. A script is an input. A chosen take is an artefact. A schedule is a promise about what a listener will hear. The public player is where all of those decisions meet.

AIRunner is becoming a set of tools instead of one giant tree

w4ffl35 — Thu, 24 Sep 2026 15:15:01 +0000

I had let AIRunner, my open-source desktop AI application, do too much in one repository. The split is now visible in four public packages: airunner-eval, airunner-tts-vendor, airunner-native and airunner-common.

The names describe the boundaries. The evaluation package can process models without dragging the application into the run. The TTS vendor fork can be tested and published without importing the host application's database. Native tools can stay close to their sidecar binaries. Shared request and response payloads can be versioned once and consumed by the desktop and service layers.

The web engine moved in the same direction. It stopped naming the products it hosts, moved the world and economy layer into uwuchat-worldsystems, and renamed the service package to airunner_engine. The remaining boundary is visible in the code instead of being a convention in a README. That matters when a new application is added because the engine has fewer reasons to know it exists.

The stack is still familiar: Python, PySide6, HTTP and WebSocket services, package publishing and CI checks. The work was less about picking a new framework and more about making the existing contracts explicit. Import boundaries run in CI. The desktop/daemon contract has a version. Shared LLMRequest and LLMResponse payloads live in airunner-common instead of being copied between packages.

The user-facing site is airunner.art. The four-week release overview covers the other projects that moved alongside it.

The payoff is visible when a new change arrives. A model-evaluation change can stay in the evaluator. A native sidecar change can stay with the sidecar. The desktop app can consume a versioned payload instead of reaching into a folder that happened to be next door. Those are small boundaries, but they remove a lot of guesswork from the next release.

Why extract a package?

Extraction is worth doing when the package has its own reason to change, its own tests and a public consumer that should not install the rest of the application. If those things are not true, a new repository is just another place to forget to update.

The next AIRunner step is to keep the service boundary just as clear as the first four extractions. The goal is a smaller set of packages that can be installed and released independently while the desktop application still feels like one thing.

Build a small event-driven classifier with SpikeForge

w4ffl35 — Wed, 23 Sep 2026 15:15:02 +0000

I like to learn SpikeForge by giving it a small job and keeping the moving pieces visible. This walkthrough uses the public toolkit, a short experiment and the event path that gained a real train/test split in the latest release cycle.

Start with the SpikeForge repository and install the package in a fresh environment. Pick one of the example datasets already supported by the project. Keep the first run short. A small experiment that you can rerun is more useful than a large run that leaves you guessing about which setting changed the result.

The shape of the experiment is straightforward:

Load the dataset and turn the samples into the event representation.
Split the samples before training, so the test set stays out of the update loop.
Choose a compact network and a short number of epochs.
Save the configuration beside the result.
Compare the test output with the training output rather than reporting one number alone.

The train/test split is the important detail. It keeps an event-driven experiment honest when the model is changing quickly. The same configuration can then move through a target adapter or into the SpikeForge model hub with a name, version and small amount of provenance.

SpikeForge is built around Python, PyTorch and snnTorch, but the useful interface is the experiment boundary. You can change the model without changing the dataset loader. You can add a target without rewriting the training loop. That is why the project was split into packages rather than kept as a single directory with a longer README.

What to record

Record the dataset, event conversion, seed, model name, number of epochs and the exact package versions. Put those beside the output rather than in a notebook cell that will disappear. If you publish the result, include the short configuration and a link to the source. Small habits like this make the next experiment faster because you can see what actually changed.

The SpikeForge project page has the current package and dashboard links. I also wrote a four-week Capsize overview with the release context and the other projects that moved at the same time.

SpikeForge Dashboard gives the experiment a desktop home

w4ffl35 — Tue, 22 Sep 2026 15:15:09 +0000

SpikeForge Dashboard is the desktop interface for experiments made with the SpikeForge spiking-neural-network toolkit. Its desktop builds moved through 0.2.5 and 0.2.6 after a run of smaller releases that established the packaging path.

The dashboard exists for the part of the work that is awkward in a terminal: looking at an experiment, checking what was loaded, and keeping the result close to the configuration that produced it. It is a React and TypeScript dashboard packaged as a desktop application and backed by the SpikeForge packages. The app is not a replacement for Python. It is a visual surface for the same experiment.

The release work focused on the boundary between source code and the thing a user downloads. The build now has a package path, a desktop bundle, smoke checks and a small release checklist. The source tree can be green while the archive has the wrong files, the wrong path or a missing licence. The packaged archive is part of the test target.

The source is public in the SpikeForge Dashboard repository. The project site is spikeforge.net, and the desktop build is available through Capsize Games on itch.io.

I wanted the app to feel like a place for the experiment rather than a launcher with a screenshot attached. That means the current run, the loaded data and the path back to the source should stay near each other. It also means the release archive gets opened and checked as an archive, not only built as a side effect of the CI job.

A good first use

Install the desktop build and open one of the small examples from the core toolkit. Keep the experiment short, then compare the training and test views. If the result is worth keeping, move the configuration into the repository or the model hub instead of leaving it inside a screenshot.

This is the pattern I want from the desktop projects: a finished surface, a public download and a clear route back to the code. The next release can improve the surface without hiding how the experiment works.

The broader four-week release story covers the other software, games and sites that moved at the same time.

SpikeForge grew into a toolkit, a model hub and a dashboard

w4ffl35 — Mon, 21 Sep 2026 21:21:52 +0000

SpikeForge is my Python toolkit for building and testing spiking neural networks. It stopped behaving like one big project during this release cycle: the core toolkit, target adapters, model hub and SpikeForge Dashboard all moved forward as separate packages and applications.

The core project released 0.4.0 and 0.5.0, then kept publishing the smaller package releases that make the ecosystem usable. The event path got a real train/test split. Quantization work moved into the drift checks. Shared logging came from capsize-commons, and the CI path gained a fast leaf lane for the parts that do not need the whole workspace.

The package layout is now a practical map of the work:

spikeforge holds the training and experiment workflow.
spikeforge-targets holds target-specific conversions.
spikeforge-hub owns the offline-first model catalogue.
spikeforge-dashboard contains the web dashboard and desktop application.

That separation is useful, not just a tidy repository list. Someone experimenting in Python does not need to install the desktop app. Someone browsing models does not need the server. Each piece can ship when it is ready, with compatibility recorded instead of implied.

The stack is Python, PyTorch and snnTorch around the core, with a web dashboard and desktop application around it. The model hub is deliberately cache-friendly, so a catalogue can be inspected and used without turning every experiment into a network operation. SpikeForge Dashboard gives the same work a visual entry point and provides a place to inspect the experiment rather than only its final number.

The project page has the current package links and release notes: spikeforge.net. The desktop releases are collected on itch.io, and the source is on GitHub.

A small experiment to try

Install the core package, choose one of the examples, and keep the first run small. Start with one dataset and a short training window. Then move the same experiment through the target adapter and save the result in the hub catalogue. The point of the exercise is not a leaderboard number. It is seeing the path from an experiment to a named, repeatable artefact.

A follow-up article walks through a small event-driven classifier. The four-week overview covers the rest of the Capsize work from the same period.

The Consciousness Gradient: Qualia, Integration, and the Emergence of Intelligence v2.1.0

w4ffl35 — Sun, 06 Sep 2026 19:26:52 +0000

The Consciousness Gradient: Qualia, Integration, and the Emergence of Intelligence

The Consciousness Gradient: Qualia, Integration, and the Emergence of Intelligence | Zenodo

This paper proposes an exploratory framework in which consciousness and qualia are treated as the same phenomenon at different degrees of integration. On this view, minimal qualia are minimal consciousness, while macro-awareness is a more highly integrated and reportable form of the same underlying process. The paper further advances the hypothesis that intelligence, understood as flexible adaptation to structurally novel situations, emerges only once qualitative integration reaches sufficient depth. The framework is developed through a dual-aspect interpretation of physically instantiated processing and introduces the idea of autonomous experiential synthesis: a history-bearing, environmentally coupled process in which past experience shapes present processing in an open-ended way. The paper contrasts this with current AI systems built on fixed architectures and frozen learned parameters, and proposes that such systems may fail at a specific class of structurally out-of-distribution tasks unless they possess genuine experiential autonomy. The paper offers four axioms, five testable predictions, and a benchmark proposal, the Relational Reversal Task, as a way to make the framework vulnerable to empirical failure. It is presented not as established theory, but as a speculative and falsifiable proposal about the relationship among consciousness, qualitative integration, and intelligence. Note: This paper was developed through an iterative process involving the author and AI language models. The foundational thesis, core arguments, axioms, and theoretical commitments originated with the author. AI tools assisted with literature review, drafting, organization, and adversarial critique. The author takes full responsibility for the final claims.

zenodo.org

v2.1.0 updated with references to A.N. Whitehead

The framework is developed through a dual-aspect interpretation of physically instantiated processing and introduces the idea of autonomous experiential synthesis: a history-bearing, environmentally coupled process in which past experience shapes present processing in an open-ended way. The paper contrasts this with current AI systems built on fixed architectures and frozen learned parameters, and proposes that such systems may fail at a specific class of structurally out-of-distribution tasks unless they possess genuine experiential autonomy.

The paper offers four axioms, five testable predictions, and a benchmark proposal, the Relational Reversal Task, as a way to make the framework vulnerable to empirical failure. It is presented not as established theory, but as a speculative and falsifiable proposal about the relationship among consciousness, qualitative integration, and intelligence.