Paul Gydos

<!doctype html>

Gydos.org | Small Tools. Deep Practice.
Public workbench

Plain text, local tools, versioned learning, and creative systems that can be understood.

Gydos.org is a growing public workspace for text-first computing, small reproducible environments, local-first document tools, and scriptable sound-and-reading systems for study, focus, prayer, recovery, and creative work.

Current public projects

Some work is already public. Some work is still being cleaned up before it deserves a repository. The common thread is reducing friction between thought, text, command, memory, and publication — while keeping the tools small enough to understand, repair, and teach.

Android-on-Android Development Toolchain

A reproducible Termux-based Android app development workflow that builds real APKs directly on an Android phone, using OpenJDK, Gradle, Android SDK command-line tools, Kotlin/Java, and aapt2.

Demonstrated targets include Falling Blocks, Pong Invaders, KJVOnTap experiments, and the planned Android port of Meditation Soundbox.

  • Current status: successfully building toward local APK generation from Android itself.
  • Best use cases: education, prototyping, phone-native development, and reproducible public documentation.
  • Production note: Google Play production readiness requires API 35+ targeting.
  • Known blocker: the available Termux aapt2 package links API 34 but appears to fail against Android 35/36 platform jars, so Play-compliant builds require further aapt2 / toolchain work.
Termux Android SDK Gradle OpenJDK Kotlin / Java aapt2 APK builds
Document the toolchain →

Siftlog Cathedral

A local-first C# application for gathering scattered writing and documents into a uniform, reverse-chronological HTML reading surface. This repository is public, but still being cleaned up: the next pass is about a proper .gitignore, clearer boundaries, and a more deliberate push history.

C# .NET local web Markdown personal knowledge
Open repository →

Meditation Soundbox

A Windows-first, local-first console instrument for generated meditative/electronic soundscapes, live frequency changes, rhythm and synthesis variation, Piper text-to-speech, pasted readings, and KJV / Meta-V scripture loading.

C# audio Piper TTS KJV / Meta-V scriptable sessions
Open repository →

The practice

This work is not only about apps. It is about building an understandable way to work: readable text, repeatable commands, visible history, and tools that can be explained line by line.

Edit Use plain text as the common surface for notes, code, data, documentation, and reflection.
Execute Prefer small shell scripts and transparent command-line flows over hidden machinery.
Remember Let git preserve the work as history: drafts, changes, experiments, and decisions.
Publish Use public repositories and simple pages to turn learning into shared artifacts.

Near-term direction

The immediate goal is to make the public work easier to enter without pretending every project is finished. The Android-on-Android toolchain deserves a reproducible guide and repository, with KJVOnTap, Falling Blocks, Pong Invaders, and the Meditation Soundbox Android 16 port documented as concrete proof of the workflow. Smellinux should become a first-class public project when it is ready; Siftlog Cathedral needs cleanup; Meditation Soundbox needs clearer release notes, install paths, and roadmap language.

$ next

1. Give github.gydos.org a true landing page.


2. Document the Android-on-Android development toolchain as a reproducible public project.


3. Add review pages for KJVOnTap, Falling Blocks, Pong Invaders, and the Meditation Soundbox Android 16 port.


4. Keep Smellinux central, but do not publish it carelessly.


5. Prepare Smellinux / vishgit as a first-class repository with scripts, lessons, and logs.


6. Clean up Siftlog Cathedral: .gitignore, generated files, README, and push history.


7. Grow Meditation Soundbox toward mixer buses, logs, scripts, voice selection, and smoother sessions.


8. Split each project page into: purpose, status, install, roadmap, and development log.


9. Keep everything small enough to read, run, explain, and version.

Contact and links

The best public entry point is the GitHub profile and the project repositories. For project-related contact, use the public Gydos.org email listed with the repositories.