The 2024 Wheel Reinvention Jam just concluded. See the results.

REGISTER HERE: Jam projects / teams!

With the Wheel Reinvention Jam kicking off in less than two weeks, it's time to get everybody ready and registered!

If you are planning to participate in the jam, we'd love if you shared a teaser of your project idea here. There's a couple reasons for this:

  • First, we'd like to avoid duplicate work - if two people are interested in tackling the same idea, we'd love if you at least chatted with each other about it. Maybe you each have different directions you want to take it - or maybe you should team up!

  • Second, we would love to get a feel for what people are interested in and use that info when promoting the jam. We want to make sure that everybody is on the same page!

In addition, if you are looking for a team, please post here! If you have a big idea that you need help to tackle, or you want to participate but don't know how, please consider teaming up with someone!

(If you want to keep your project idea secret, that's fine too, but we'd really encourage you to share something!)

Also! If you are on the community Discord server, don't forget to link your Discord account from your user profile settings! Doing so will allow any content you share on Discord during the jam to show up on the website so more people can see what you're working on.


Edited by Ben Visness on

I'll kick things off: my project will be a visual SQL query builder, taking inspiration from Blender's compositing workflow (and shader editors and similar things).

Basically, I find complex SQL queries frustrating to write and error-prone. It's always hard to me to verify that I haven't made a subtle mistake halfway through. And pretty damningly, I can't see the data or the schema at all while I'm writing the query - I have to look it up on the side.

And in general SQL doesn't match the workflow I want when making queries. I want the process to be more "playful"; I want to see the data, formulate some questions, and then bash the data together to answer them.

While I think it's kind of ambitious to do in a week, I have my trusty friend Ejektaflex jamming with me. Hopefully I'll be streaming a lot of it on my Twitch channel. We'll see what we can do!

As for what it's reinventing - there have been many visual database query tools made in the past. Incredibly, literally all of them seem to be clones of the Microsoft Access query builder, which has some design choices I disagree with. Our ideas are gonna go in a different direction, and hopefully a more effective one.


Edited by Ben Visness on

So excited for the jam to get started! Here's what I'll be working on (and streaming). It requires a little bit of background.


Over at Dion Systems we developed a tool called Metadesk. It's both a data description language and a library for working with that language. In my experience, Metadesk "breathes life" into text - it is an easy-to-write, easy-to-read, and flexible format that translates into a very simple structured representation. It was originally intended as a metaprogramming tool (a replacement for an older tool called "Data Desk").

Metadesk accidentally grew out of just being a metaprogramming tool, though, and started acting like an experiment, giving us insight into how a more structured, but still general-purpose, base format might feel to work with.

A more structured base format is, conveniently, one of the "pillars" of the Dion project. This format should be usable for code, but other data too: to-do lists, note-taking, image libraries, financial records, more structured logging (terminal output, program logs, etc.) and more.

Because a format would be more easily used in its structural form by an editor or viewer than text would be, it'd be much easier to start fitting more ambitious ideas into those programs. It'd be a much more tractable problem to, for instance, visualize image data when an image on disk is referenced, build "slices" (see last year's demo), layout interactive graphs that pull from values stored in the format, make hierarchies in the format collapsible, or many other options.

Metadesk is not the Dion Format, but it does give us one way to experiment with something like the Dion Format.


So, all that being said, I'll be working on a general-purpose Metadesk viewer that attempts some of these more ambitious features. I am hoping it will provide insight into how working with a new structured format will be, what options are open, which aren't, and so on.

Which wheel is this reinventing? In short, it's one step in the reinvention of the wheel of the text file, and the tools we use to work with text files.

Depending on how productive my week is, I may get a new way to manage lots of my day-to-day data that I'd otherwise put in a spreadsheet or a plain text file. Then, it will be straightforward to use that data in this Metadesk viewer, visualizing whatever I need from it.

For Handmade Seattle 2020 I showed an early demo of Terminal Click: a next-generation emulator. I encourage you to watch the 20 minutes or scrub through the parts where you see a terminal in action 😉

It's not far away from an alpha release -- I just need to sit on my butt and work on it. I hope to use this jam to get back into a rhythm.


Assuming you've seen the demo, here are possible ideas for the jam:

  1. Expand Command History - The emulator remembers the output of my command (say clang) and the date when you ran it. You get to scrub through that enriched history. Jam ideas to expand on that:

    a. More Command Meta-Data: for example why aren't we storing how long my command took to run?

    b. Visual Graph: Visualize my clang commands from say the past 3 days. What should the graph show?

    c. Drag-n-Drop: I should be able to share my enriched history with a friend. They drop it on their terminal and see all of it.

  2. Level Up File Explorer - The built-in file explorer is very exciting. It shows the emulator is not just a vessel for dead ASCII text. However there are things to improve:

    a. Detect File Types: For example if it's a PDF then show a PDF icon instead of a generic file icon.

    b. Inline Previews: Right now we open up files using an external program, but the terminal should be able to preview certain files inside.

  3. Expose Customization API: Similar to 4coder, there is a core engine powering the cool features you see on the demo. Ideally the user should have access to this engine through a user-friendly API.

  4. Try Essence's Terminal Ideas: The creator of Essence OS shows cool terminal ideas on Discord. I want to steal one or two to see how they fare in practice (I got permission to steal.)

But honestly if all I end up doing is just tightening screws to make Terminal Click more shippable then it's a jam well-spent :)


Edited by Abner Coimbre on Reason: Typo.

Around October of last year I started work on a mobile application that would render and organize ChordPro files, geared towards musicians who like to use lead sheets to perform. There are many applications out on both the Apple App Store and the Google Play Store, but none of them really hit the mark for me as they are all missing a lot of key features, such as being able to quickly and easily categorize the sheet music in the app in a sensible way, or keeping multiple "music notebooks" for different occasions (e.g. one notebook for jam music with friends and another for church hymns, for example).

I was hoping the jam would give me a motivation to continue work on this project. I'll be streaming my progress over on Twitch whenever I work on it, and possibly also uploading the VODs to my YouTube channel (although I can't promise a consistent schedule since I am also currently starting my last year of university :P).

I'll be working on an audio live-coding tool.

There is a number of existing wheels in that domain:

  • Graphical dataflow environments like Max/MSP and PureData are used to prototype and build DSP effects and synthesizers by connecting processing 'boxes' together.

I don't really like the mouse-heavy node graph UX where you have to constantly move boxes around (even if the layout of boxes is irrelevant to the computation!) and draw lots of cables between them. Furthermore, it imposes a dataflow paradigm that, although relatively convenient for expressing many DSP algorithms, is not well suited for writing more imperative control, or expressing temporality.

In both Max/MSP and it is also possible to write boxes in C, but there is a big abstraction gap between the environement and the way boxes are written, and a lot of friction due to the need of developping boxes using a separate toolchain, and compile and reload them each time a change is made.

  • SuperCollider, which is a sound synthesis server, controlled either by a client that uses a dedicated scripting language, or directly via OSC messages. I see it as kind of a 'headless' Max, which avoids the unnecessary box shuffling and cable drawing, but still relies on building a node graph with pre-compiled black boxes.

  • Another intersting DSP environment is FAUST: it is a programming language that allows expressing DSP graphs, and has a number of interesting features like inline GUI widgets, an automatic documentation and dataflow diagram generator, integrated spectrograms/meters, etc. But it still leans heaviliy towards a declarative, dataflow paradigm, and can sometimes be a bit too cryptic to my taste.

By contrast, I would like to have a bare-minimum live-coding environment in which I can quickly prototype DSP ideas in C. Think shadertoy but specifically for audio! Now some features that this program should have:

  • The base interface should allow the user to choose the audio devices and tweak their parameters, and could provide a few useful controls like a master volume slider and mute button, in/out level meters, etc.

  • The environment should provide input and output sample buffers and call a user provided function that does the desired processing on input samples and writes output samples. User code should be automatically recompiled/hot-reloaded on changes. We could provide a utility/helper API for common DSP operations.

  • The environment could also expose a simple API to create GUI widgets to control the DSP parameters, like sliders/buttons/checkboxes/curves etc, and add them to the runtime interface.

It's my first Jam ever (!), so I don't know exactly how much of that I can achieve in a week, but I'm really excited to find out!

I will be working on a world processor / typesetting format.

So I will develop a non text format similar in some ways to LaTeX, with a intuitive and easy to editor.

On the jam I will focus only on general document typesetting, so there will be no math typesetting, that can be added later.


Edited by Samuel Deboni Fraga on

Hey Guys,

Was struggling to think of a good idea with a doable scope for a week, but have eventually settled on a user preferences translator program for code editors. One thing that really annoys me when I have to use different editors/IDE's for work or personal stuff is getting everything setup the way I like it in terms of color schemes, hotkeys etc. Things like different editors using different names for highlighting different parts of the syntax, using different color representations etc. One last thing I would like to tackle with this project is the process of creating color schemes, instead of editing text, saving the theme and reloading it to visualize your changes, having real time feedback with color wheels and a real time preview of how this would affect syntax highlighting would be pretty nice. To keep the amount of work at a manageable level my goal is to have some simple internal format (might use Metadesk's format), and 2 set's of converters for two popular code editors, most likely 4coder and VSCode or maybe lite, and a simple UI (probably using microui) with tools to build and visualize basic color schemes.

There is this very simple 2d-statical analysis tool that I use/used throughout my civil engineering studies (RuckZuck). It is very simple and easy to use, I can't complain too much about it. The problem is I only have a DEMO version that won't let you save and a full version costs 2100€.

So that is what I will try to re-build during this jam.

I know the basics of how to analyse a static model programmatically, but I never done it before and it will be fun (for me at least) to learn more about it.

I don't think I will have much time this week for programming though, so that's why I won't bother with an UI at first. Input/Output will be done via text-files.

I want to stream all of this and I will try to make it educational because there is only very little information on how to do something like that on the internet.

I've spent my free time the last few months working on Darke Files, a version control / file synchronization system.

The basic idea behind the system was the realization that version control systems (that programmers use; like Git or Subversion) and file synchronization tools (that everyone else uses; like Dropbox or Google Drive) have a huge amount of overlap in features. Darke Files will be the union of those two categories.

Darke can scale between those two extremes within one repository:

  • A game programmer might want a Git-like version control system, work with branches and want to inspect and act on a rich version history.
  • An artist might not care about how to commit their work or switch branches but rather want a simple app running in the background automatically uploading changes every few minutes.

Right now I'm concentrating on a command-line interface and corresponding server-side application. In the future I will also create programs for the non-programmers.

I've shared the first public screenshot in the #project-showcase a few days ago. Since that post I've added a few more features and I'm getting really close to be able to release an actually usable but still very early alpha version.


For the jam I'd like to build a feature to import a full Git repository. You should be able to run

$ git fast-export | darke files import-git

Apart from the fact that this will allow me to move my Git repositories over to being Darke repositories, this feature will also provide a big amount of new test data by utilizing especially big or otherwise interesting or naughty Git repositories available on the Internet.

On Git's side the fast-(im|ex)port format seems well documented. Depending on what parts my Git client can actually produce I might be able to leave out some chunks of that format. Those features where Git and Darke differ will be especially interesting with two candidates I'm aware of right now: Git's branches and tags vs. Darke's refs and the way both tools approach identity handling. Explicit non-features are an export in the other direction and the ability to run this multiple times (i.e. no delta imports).

Hi,

My plan for the jam is to work on a file manager for windows.

Windows explorer is obviously pretty terrible, yet there seems to be very few alternatives.

I have been trying out Far, and while I certainly prefer it to Windows Explorer, it feels very clunky. When I ran Linux, I used to use Ranger, and found it fairly pleasant so I will likely take some inspiration from it, however my file manager will not be terminal based and should not rely on learning keybindings, typing commands or editing config files: ideally it should be usable by anyone who can use Windows Explorer, only without a right click menu that takes multiple seconds to appear. I also would ideally like it to feature an Everything style instant full-filesystem search.

In addition, I have some slightly wacky ideas about creating different "views" of the file system, but only time will tell if they actually make any sense or are actually useful in practice.

I'm not sure how much I will get done in the week, but I definitely would like to continue working on it after the jam as well.

My project will be a specialized time management program, designed to handle prioritization of very large quantities of tasks, each with different requirements, purposes, and deadlines.

Most strategies for time-management don't really handle everything adequately. Task-based todo lists and Kanban boards require too much manual upkeep to make sure that you're prioritizing things correctly. Time-based strategies such as calendars are too rigid to apply to every task you want to do, and planning out your day ahead of time is a lot of work.

I plan to reinvent the wheel by combining the two approaches into something more user-friendly, and automating most prioritization. In a perfect world, you should only have to interact with the program for more than ten seconds when entering a new task, or when you decide you've changed your priorities, and that's including both the time to open the program, and the time to get back to what you were doing. This is meant to save time, not waste it.

I'm going to use this Wheel Reinvention Jam as an excuse to work on a project which feels frivolous, but should come in handy for prettifying future projects.

The project is a C library with a basic command-line interface. The library looks at the user's current desktop background and picks some number of unique colors from that background.

It then outputs the color values selected. When included in a C/C++ project, the color values can be used to theme the application to match the user's background automatically.

My inspiration for this project was from one of my previous projects, which creates color schemes for Emacs: This project is a reinvention of that past project. This new version solves several problems:

  • Low dependencies. My previous implementation relied on schemer2, which is written in Go, and my color processor was written in Python. These two languages require pulling in a lot more dependencies than a tiny C library, and cannot be embedded in C/C++ applications
  • Automatic. I've found I enjoy themes which match my desktop most, but previous tools require manual steps to make this happen. This project will be easily embeddable and automatically scrape colors off the user's background
  • First-class Windows support. I'm committed to making this tool work on Windows, which tends to get less love from the FOSS community (in part because it's objectively less theme-able)

Edited by Macoy Madson on

I've been thinking about a hex editor that would allow a custom interpretation of binary data.

Hex editors usually have a left panel with hexadecimal characters and a right panel with a 1-to-1 decoding of the hex into ASCII. I would like to make an editor that allows a user programmable higher-level interpretation of the data in the right panel rather than only ASCII.

The right panel could contain:

  • JSON if the binary is a BSON file
  • x86 assembly if the binary is a program
  • Plain text FBX if the file is binary FBX

This year I've found myself working with large binary files that have an under-specified format. This led me to daydream about what a hex editor could do to facilitate exploration when interpreting binary.

Some projects partly fulfill these goals:

  • HxD contains a "Data Inspector" that allows interpretation of the selected bytes as various integers, character codes, time stamps, or even assembly. This interpretation is only for the selected bytes and is limited by the interpretations supplied by the program.
  • Rehex can interpret a binary x86 program as assembly. It is also user programmable by LUA; however, x86 interpretation is treated as a special case compiled into Rehex rather than one of many user configurable interpretations.
  • Frhed has some high-level interpretation hard-coded in a drop-down list. When a DLL is opened, the user can select "Go to DLL export names" to highlight that region of the DLL. A custom user specified interpretation would require adding a new drop-down option and recompiling Frhed.
  • ICY Hexplorer takes a different approach by featuring user specified macros. Just like with a text editor, the user can record a pattern of caret movement and insertion / deletion. This allows rudimentary "programming" for manipulation, but does not help with interpretation.

Viewing and editing binary files has been around for a long time. The old Unix tool "od" allowed dumping binary data into a variety of human-readable formats. It was released in 1971. Modern hex editors do essentially the same thing.

https://en.wikipedia.org/wiki/Od_(Unix)

Check out 010 editor: https://www.sweetscape.com/010editor/templates.html

It allows to write structured description of your binary data and then explore its representation. Has bunch of templates premade: https://www.sweetscape.com/010editor/repository/templates/


Edited by Mārtiņš Možeiko on
Replying to TimothyB (#25090)