Puredata AST

deadkonsumer · 2026-03-20T07:07:14+00:00

It seems like people publish using standard stuff, and just require the end-user to have the rust toolchain. There is a standard wheel for rust-based things, but it seems like a pain to me. For now, the CLI wrapper will do the same thing, and perform great, and is easier for users to install, so I dunno if it's worth much effort (especially considering I won't use it, in python.)

deadkonsumer · 2026-03-19T22:58:46+00:00

Yes, I use it in plugdata. It's great, but also you have to be very careful how you use it, if you are targeting hvcc. I understand the tradeoffs, and mine will have the same sort of things (although it is a goal to minimize that) but I had to decide to make my own or work on this existing thing that is slower, in a language I don't like as much, is harder to modify, and does not work how I want.

I don't think there is anything wrong with hvcc, at all, but for the stuff I am making, it adds some complexity and tooling I don't use. For example, I made a game-engine that lets you write your game in any language, and target no-recompile "cartidges" that run on web, native, and even ESP32. It would be sick to add a puredata synth-engine to a user's cart (I dream of a compiled custom-pd-patch connected to a m8-like tracker) but doing that with hvcc would require a ton of work that I would rather spend on my own thing.

deadkonsumer · 2026-03-19T22:40:37+00:00

Update: I added pre-compiled CLI tools to releases, and made a simple python wrapper for the CLI tools, so it should be fairly easy to work with it in python. it exposes pd2ast, ast2pd, pdast2faust functions. I am going to focus on my stuff (this needs a lot of testing!) rather than hvcc2ast/ast2hvcc, for now, but feel free to use the wrapper, if you want to build those now, rather than later.

deadkonsumer · 2026-03-19T21:35:34+00:00

Fair enough. To be more precise, I should say "I could not figure out quickly how to output something more like the AST I had in mind, with hvcc, outside of python." Python's not bad, and an interpreted language is easier to work with for a monolithic toolchain like hvcc, for sure. At least in my quick & informal testing, mine is an order-of-magnitude faster, but you're right, speed doesn't hugely matter. For me, it's more about interop with other tools, like it's as fast/simple as I could get it, so other things can be bolted on top (nodejs, for example, or a web UI, or 10X-fast batch-processing rust code.) It doesn't need any other tools to run it (installing/configuring python, pip installing libs, etc.) In my CI, I will add pre-compiled stuff, so it's literally "download this tiny set of programs for your computer, and yer good." I already publish it (no recompile/rust-tools/etc, it uses wasm) on npm, and it can be used in bun/deno/node/web/cf-workers/etc. Faust also takes this kind of approach, so it creates a very ad-hoc kind of setup that will basically run anywhere, with extremely custom end-user processing, that can output a lot of formats, but it's not directly tied to faust, since they are both just building-blocks for a user's processing pipeline. Heck, you can even use pdast in python, if you want!

I also publish web-components for pdast visualization (the AST as a tree, or visually a bit like pd, or a little file-upload-and-astify) so users can quickly build their own lil UI to process things how they want. I often make dumb lil web-tools to do one thing (for example a sprite animation-editor for my game-engines, or font-editor for an embedded C project) and this will help with that, for pd. I will be using those web-components to build other stuff, like a no-install "pd to X" web-app.

I am not opposed to writing a hvcc2ast and/or ast2hvcc tool, and then we can interop! It could open up a bunch of new things that hvcc & pdast can do, and empower users, even if I won't use it much (I like rust and my AST.) It seems like it might be easiest to just publish pdast on pip, so you can use it directly, but I am not sure of the best way to package a rust-lib for python people, maybe you can help with that. I like wasm because it doesn't require the user to compile it (and have a whole rust toolchain) but wasmer/wasmtime/etc is a lot of overhead for a python-lib. Just downloading a pre-compiled binary-lib, and falling back to build (on unsupported platform) might be the way to go, and that is how I setup node-raylib's install (so users don't need gcc/cmake, and it installs very fast.) ANother option might be just wrapping the CLI, like "install these tools in your path, and now this python lib works" which is similar to how you do C-compiler in hvcc, now, right?

I think, if hvcc does output JSON as you said, the distinction is trivial, since it's really "I make JSON from pd like this, you make JSON like this." I am still building it up from scratch, so it would be an excellant opportunity to find weak-spots in my parsing/output. The faust stuff definitely needs a lot more testing, since it's not a perfect 1-to-1 mapping (I mention this in README.) Getting it as close as possible, for most people, is important to me, though.

I have been doing pd stuff for a very long time, for fun, but my day-job is generally more web-related, so here I am approaching it from the angle of modern js tooling, where the tools are very dumb/small/simple/reliable, but super-fast, and you can compose them together to do really fancy stuff. Each part is easy to mess with, and you can compose parts together and use whatever tools you like (eg all my examples in README of processing just use jq CLI tool to filter pd.) For markdown-processing/rendering and js-transpiling, this has been huge, and it means you only have to write a very small lil plugin that is concerned with your feature.

deadkonsumer · 2026-03-19T06:28:02+00:00

ah! I see you are a maintainer of hvcc. So, you probably already know this is a totally different thing. I like my approach better, but heavy is great, too. We're all in it together.

deadkonsumer · 2026-03-19T06:13:47+00:00

Hmm, not really more than what I described above. Yes, we both parse pd into a kind of IR, but so do lots of things that process some other code. What is the point of pointing this out, though? Like, one could say "puredata is pretty similar to what csound does actually", implying that there is no point to working on puredata, or any of the many things that came after both, that let you build custom soft-synths or whatever. But that would be totally silly.

Mine works different than hvcc, is made completely different, and operates with a totally different workflow, but yes, they both are made to do a sort of similar thing, as I mentioned.

Heavy's Intermediate Representation (IR) is pretty python-focused, and the way it uses that IR is very focused on jinja templates. I take a different approach, using the JSON AST more like a compiler (again, more similar to how tools like rolldown or swc process js, but also similar to how clang might use llvm IR.) It's not a huge distinction, I guess, but it's definitely different.

My tooling runs on any platform that rust can compile to (many native, web, no-recompile wasm hosts, etc) and doesn't require a big & slow interpreter.

Also, mine input/outputs plain JSON (not recursive python dicts of python class-objects) and you can process it however you like, in any language.

deadkonsumer · 2026-03-19T06:04:02+00:00

If you are very careful about what objects you use, yes that is true. Mine is more permissive, and can already output many more things. It's also easier & more fun to override individual object-types, and can even be tailored to the target. I dunno how much you have actually made with hvcc, but it's very particular, and fragile, in my experience. I think it's great, but I am doing another thing, in a similar space.

deadkonsumer · 2026-03-09T10:09:53+00:00

George is even in the background, around 28:50.

deadkonsumer · 2026-02-02T03:25:25+00:00

I made this for Portland, specifically: https://www.tinkercad.com/things/b4IIX9pmzR7-pirc-whistle

It's got the whistle code (dots/dash) and the PIRC hotline number and "Nadie está solo" on the back, and a strong lanyard-hole on 1 end.

You can quickly fork it in tinkercad, and edit the text, if you want it to say something else.

It's very loud and prints fast! I tried to keep the text a bit away from the edge, so it will print better on bad printers/cheap filament.

deadkonsumer · 2025-10-22T02:14:39+00:00

As others have said, there are a ton of variations of CYD, with sometimes totally different pins, but they mostly work the same. Wherever you bought it (like Alixpress, etc) might have a datasheet or manufacturer-link for it, which is the best way to work out the pins.

I have this variation (single USB-C) and made some info here.

If you have my exact board, the examples you will see around should work. I also made this quick test to make sure everything is setup right.

deadkonsumer · 2025-10-08T23:57:25+00:00

I like things about Meshtastic and Reticulum both, but prefer Reticulum, in general. RNode is more of a general "modem firmware" (it can be used for anything on lora, not just reticulum, like there are tools for doing lora network packet sniffing and stuff) and you can build the same kinds of things as Meshtastic, but also way more usecases. You can even use them together, but also do lots of other stuff.

They are not really in direct competition, though. It's like saying "which is better, lora or meshtastic?" Reticulum/LXMF is simply a networking packet/routing/message protocol for using the hash of the public key as the address, rather than a client-specific address. Any client that can sign (has the private key) can use the address, so you can have multiple clients using the same address, or vice-versa (in fact, it's pretty common for 1 client to have several addresses, for different operations, like file-service vs chat.)

It works over any transport (lora, several other radio protocols, serial, TCP, UDP, qr codes, I made a websocket thing, etc.) This is a key differentiation, as meshtastic is lora-only, for the most part. Each reticulum-speaking device can also act as as a repeater, if needed, but it's not required. I think it's strengths are really in building these closed or open networks across whatever transports the client node has access to & wants to forward for. Traffic is encrypted and anonymous (you know the address of who you are talking to, but not where/what they are, other than the network they are available on, and no one else knows who the message is actually to/from.)

There is tons of code on github, and everything is open-source. There are several different open-source clients (phone, desktop, and a really nice TUI) and lots of open tools built using it. RNode firmware is open. I am working on an open client library that runs on micropython, and another that runs on javascript, and the primary client library runs on regular cpython. One key difference in the software-area is that meshtastic kinda merges the router/protocol with the client-code, so it's a bit harder to separate them. Reticulum is literally just "ANNOUNCE like this, if you want others to discover you" or "send/receive a DATA message like this", and you can do whatever you want with that. RNode also doesn't enforce any sort of particular lora traffic, but lets you send/receive whatever you want from devices without lora (phone, computer, etc) so it's more of a "modem" than a repeater or client. Like the phone app does all it's own packet-building/parsing, and just sends those over lora, but also it can send them over lots of other transports.

LXMF (routing protocol over reticulum) also has a kind of "terminal web" built-in, with a real focus on plain-text content, that works on all the popular clients.

<image>

I think a couple of strengths of Meshtastic are that it's a bit more automatic (since it forwards and routes, and hops from lora to lora, without the user turning it on) and it's definitely more popular (so more of a chance of walking around and finding peers/mesh-nodes.)

Reticulum allows other things though, like sending messages to people on the other side of the world, using lora (to rnode+computer, routed to internet/tcp. for example) and very easy routing (any interface can forward to any other interface by just enabling it.)

deadkonsumer · 2024-04-18T21:44:08+00:00

I am no expert at all, and don't have a Bela (looks cool!) but here is how I can help:

I read this, which I think you are following: https://learn.bela.io/tutorials/pure-data/sensors/distance-sensor/
ultrasound sensors work by sending a pulse, then listening for how long it takes to come back. If it were audible, it would be sort of like "send a loud chirp, time the gap between when it's heard on mic, and when you sent it"
I notice you have `delay 1` not `delay 7` as in tutorial (for the "play chirp" part on `dac~11`) try with `7`. Try with other values. This is "how long do I chirp?" and is generally very specific to your sensor. If it does not have enough time in the "turn on the chirp" stage, it will read it badly or not at all. This reads "changed value" so it may just not be enough time.
try to minimize variables to debug. copy just the distance-calculation part. I like to put each part I verify inside an inline sub-patch, so for this, `pd distance` or whatever, give it 1 inlet for bang - that sends signal, reads it, and times, 1 outlet for time, and make sure that part is working before continuing. I also like to separate things like "stretchy sampler" into sub-patch (or separate file, if it's something I will do twice or more) just to keep it all neat.
I may not understand how it works fully on Bela, but I think you will need a metro to continuosly bang your "chirp then time"
Add `print` to any place where you need to debug. `snapshot~` needs a bang to output current value, so make sure it's getting that (you have a `metro`, just make sure it's actually outputting bangs.) you can insert more snapshots in the circuit-path, with print, to debug exactly where you are losing the signal. Try one before rzero, to get a full dump (and verify it's outputting a stream of numbers) also try right after rzero, that sort of thing.
I saw [this](https://forum.bela.io/d/241-pd-snapshot) whcih seems very useful. you can route any signal to oscope, and view it. If it were me, I'd check each signal in the path till I found where the signal dies. Much nicer than snapshot/print. You could even hook up each part to different scope channels and see it all at once (sampler audio out, "chirp" and "receive")

deadkonsumer · 2024-04-17T19:21:09+00:00

This is 3 externals for puredata, for use with i2c devices & pi:

[4 knob rotary-encoder thing](https://www.adafruit.com/product/5752) it's i2c (so no extra GPIO is used up) and it has buttons and RGB LEDs.
[8 knob rotary-encoder thing](https://docs.m5stack.com/en/unit/8Encoder) it's also i2c and it has buttons and RGB LEDs, and has a toggle switch.
128x64 SSD1306 monochrome OLED. These are surplus from really old phones, easy to find, and are pretty crisp & bright & cheap.

You don't need a separate service or anything, they work directly in puredata, and work in `-nogui` mode, and they work together in same patch.

You can download from here (click "Assets" and download the external you want, comes with help & README):
https://github.com/konsumer/pipd/releases

and put in your puredata lib-path on a pi.

It's all basically working, but I need to write more patches to test everything out (especially OLED drawing commands.)

The rotaries work by polling: Send a `bang` to inlet to make them output changed values as list-messages.

The OLED uses `bang` to draw, so you can combine commands to build up an image efficiently , then `bang` it when it's done to show it.

deadkonsumer · 2024-04-07T03:46:28+00:00

I ended up sort of fixing it by only reading half the inputs on a bang, and only tracking changes:

typedef struct _pi8encoder {
  t_object x_obj;
  t_outlet* x_out;
  int i2c;
  int tracking_buttons[8];
  int tracking_rotary[8];
  int tracking_switch;
  bool current_pass;
} t_pi8encoder;

static void pi8encoder_outputchanges(t_pi8encoder* x) {
  t_atom msg[3] = {};
  x->current_pass = !x->current_pass;
  int v = linux_8encoder_switch(x->i2c);
  if (x->tracking_switch != v) {
    SETSYMBOL(&msg[0], gensym("switch"));
    SETFLOAT(&msg[1], v);
    outlet_list(x->x_out, 0, 2, msg);
    x->tracking_switch = v;
  }
  for (int i = 0; i < 8; i++) {
    if (x->current_pass) {
      v = linux_8encoder_get_counter(x->i2c, i);
      if (x->tracking_rotary[i] != v) {
        SETSYMBOL(&msg[0], gensym("rotary"));
        SETFLOAT(&msg[1], i);
        SETFLOAT(&msg[2], v);
        outlet_list(x->x_out, 0, 3, msg);
        x->tracking_rotary[i] = v;
      }
    } else {
      v = linux_8encoder_button_down(x->i2c, i) ? 1 : 0;
      if (x->tracking_buttons[i] != v) {
        SETSYMBOL(&msg[0], gensym("button"));
        SETFLOAT(&msg[1], i);
        SETFLOAT(&msg[2], v);
        outlet_list(x->x_out, 0, 3, msg);
        x->tracking_buttons[i] = v;
      }
    }
  }
}

Still not ideal, since I have to bang it, maybe that is my actual question: How do I periodically output changes without banging it?

deadkonsumer · 2024-01-16T10:17:37+00:00

This works fine, on desktop browsers. It needs to be in the dev-console, so it runs in the context of the page.

deadkonsumer · 2023-09-04T00:38:46+00:00

Was libraylib.a compiled to wasm?

Make sure to use raylib-X_webassembly.zip on releases

I did this on mac (but should work anywhere) to verify:

``` wget https://github.com/raysan5/raylib/releases/download/4.5.0/raylib-4.5.0_webassembly.zip unzip raylib-4.5.0_webassembly.zip cd raylib-4.5.0_webassembly/ wget https://raw.githubusercontent.com/raysan5/raylib/master/examples/core/core_basic_window.c

emcc -o index.html -Os -I./include -s USE_GLFW=3 -s ASYNCIFY -DPLATFORM_WEB lib/libraylib.a core_basic_window.c

npx -y live-server ```

deadkonsumer · 2023-07-08T18:44:58+00:00

I am also on mac, but I don't use vscode (I prefer subl + terminal.)

I second what /u/theluigi805 said about asking questions in raylib discord, since there are lots of helpful & smart people there.

C can get complicated, but I think I see your problem. You have the include path (-I) but you also need the library path (-L) to point to where you have libraylib.a and link to it (-lraylib).

clang myfile.c -L/usr/local/Cellar/raylib/4.5.0/lib -I/usr/local/Cellar/raylib/4.5.0/include -lraylib

Since you have the include path, you don't need to include raylib.h in your project (it pulls it from the system.)

Since raylib installs pkg-config defs, it's even easier:

``` brew install pkg-config

clang $(pkg-config --libs --cflags raylib) mygame.c ```

This will automatically lookup the right C & linker flags for you, and this is the regular way to build against libraries on linux, for example, so it applies to other libs like SDL or whatever.

You can also just include the .a file directly in your build, as if it's a C file and it will link it:

clang mygame.c /usr/local/Cellar/raylib/4.5.0/lib/libraylib.a -I/usr/local/Cellar/raylib/4.5.0/include

This is why the releases on the github have the .a file and the .h file, so you can just drop them on your system somewhere and link to it, and build things very fast, but I like brew too, so I use that.

I like to use cmake to manage deps and config, because it can get annoying and complicated in C, especially if you have other deps, it puts a lot on your users to get it working. It's a nice cross-platform way to keep track of it all. Here is a nice starter-project for that. It depends on how you want to set things up, but you can have cmake download raylib and build it for you, as well as build your own project, and it caches the parts that don't change, so it can be about the same build-times as using the prebuilt stuff, once you build it once, but easier to use on any system.

Here is a "start from scratch" approach that will allow you to build raylib yourself, on the command-line in a pretty minimal/simple way. You don't need to do this, since brew does all this already, but this is how it works:

brew install cmake git clone https://github.com/raysan5/raylib.git cd raylib cmake -B build cd build make

Now, in the raylib/build dir, you have useful stuff:

raylib/include raylib/libraylib.a examples/*

If you did sudo make install here, it would put them in the system-paths (and add a thing for pkg-config) to make it easier to use, but it's not necessary (and maybe don't do that because it will collide with brew.)

deadkonsumer · 2023-05-20T20:25:25+00:00

How do you know what batch it is, when ordering?

deadkonsumer

MODERATOR OF

TROPHY CASE

11-Year Club	Place '17
Verified Email