Show newer

This zet is separate from my main wiki, and just beginning to get past the initial stages:

pbat.ch/brain/

Show thread

This year, I'm doing more studying/learning and getting my formal about it.

Pretty pleased with this automatically generated glossary page I made today. It extracts certain messages from my zettelkasten and formats them, in alphabetical order:

pbat.ch/brain/glossary/

patchlore boosted
patchlore boosted

Matrix
while :;do echo $LINES $COLUMNS $(( $RANDOM % $COLUMNS)) $(printf "\U$(($RANDOM % 500))");sleep 0.05;done|gawk '{a[$3]=0;for (x in a){o=a[x];a[x]=a[x]+1;printf "\033[%s;%sH\033[2;32m%s",o,x,$4;printf "\033[%s;%sH\033[1;37m%s\033[0;0H",a[x],x,$4;if (a[x] >= $1){a[x]=0;} }}'

With any luck, these poems should work on screen readers. Gibberish, but patterned gibberish that faithfully represents the symbols used to conjure the music.

Show thread

But wait, there's more!

The syllables used for encoding are organized physiologically: pa, fa, thu, de, yu, go, ha. The sounds start in the front of the mouth and work backwards.

Only 7 syllables are needed to encode 3-bits, because 0 is used as a separator in the bitrune parser.

Show thread

So, some words about the text.

I call it generative asemic poetry. It is a direct text-based representation of the glyphs seen in the video (and yes, those glyphs *do* work together to conjure the sounds heard in my live coding setup).

Each stanza corresponds to a row. Each word corresponds to a glyph in the row. The syllables in the word are used to encode the actual pattern of the glyph.

Show thread

3

fafa fathufa hayu yuhafa.
yuyu pahapa faha dehafa.
yuyu pahapa faha yuhafa.
fayu pahapa faha yuha.
fayu hayuha fayu hadeha fa.

On the horizon:

bitrune: a symbolic live coding environment for the monome grid, built on top of mnolth.

mnorns: a version of mnolth/bitrune designed to work on the norns.

Show thread

This was literally created inside of my other system, called monolith. Compared to monolith, mnolth is more focused. Does less:

no built real-time, only offline rendering

built on top of sndkit, my DSP environment, controlled with a LIL scripting language

tinyscheme (simpler, smaller) instead of s9 scheme

no janet

no built-in support for grid/arc

a completely reworked pipeline for rendering offline h264 video via x264

Show thread

Over the past few months, I've been restructuring my musical ecosystem.

Consider this a soft release:

git.sr.ht/~pbatch/mnolth

LIL code 

This is the LIL code for the test patch heard above. I got a little carried away with it.

hold [add 0 0]
regset zz 0
hold [add 0 0]
regset zz 1

metro [rline 1 4 1]
env zz [param 0.001] [param 0.01] [rline 0.01 0.1 1]
flipper [phasor [rline 0.1 0.5 1] 0]
expmap zz 1
scale zz 67 72
mtof zz
blsaw zz
butlp zz 800
mul zz 0.8
mul zz zz

dup
mix zz [regget 0] 0.5
dup
mix zz [regget 1] [expmap [mul [flipper [phasor 0.3 0]] 0.9] 3]

regget 1
vardelay zz [param 0.8] [rline 0.01 0.4 2] [param 0.5]
dup
mix zz [regget 0] 0.5
add zz zz

regget 0
dup
bigverb zz zz 0.97 10000
drop
dcblocker zz
mul zz [dblin -10]
add zz zz

wavout zz mix_test.wav

computes 20

unhold [regget 0]
unhold [regget 1]

Show thread

Added a "mix" node in today, which allows for things like sends, throws, and signal bussing.

My thoughts moving forward with literate programs are maps. How does one effectively guide the reader? There's very little in common between a novel and a Knuthian literate program beyond the print medium they share. There's is hardly any value to reading a literate program cover to cover. For a big book, Usually there's a good table of contents or an index. These are maps.

But literate programs aren't print medium anymore. it's just not how we consume words and text now. We have tiny screens that can dynamically display interactive content. We don't flip through pages. We scroll through threads and click on links.

There's a lot of meta information that a literate program can provide actually. In my system I've written, I'm only presenting a fraction of it when I publish the HTML. It could be more helpful.

Show thread

Not everything should be a literate program. Most lines of code aren't worth working into a literate style. Choosing when to write in a literate style and when to avoid it has been a more conscious choice for me.

In sndkit, all the DSP algorithms, as well as the core system, have been written in a literate style. But that's only a fraction of the codebase. The rest of the codebase is either a third party library like LIL, or some kind of boring glue code that's mostly boilerplate.

Show thread

To be clear: inline comments in code are *not* literate programming, no matter how thoughtful you get with them. Never will be. It feels very different from writing code blocks in a markup language. A true literate programming system has the ability to write code out of order as well.

A nice consequence of using a markup language is that you can write and outline structure before producing any actual code. Many of my own literate programs started this way, and I believe they turned out to be better because of it.

Show thread

Programs that lend themselves well to literate programs are things that are complex, well defined, and that change slowly. Anytime I'm building some kind of core system or architecture, I like to do it in a literate style. Not only does it serve as a good reference document later, but it also forces me to think more carefully about what I'm doing.

Show thread
Show older
post.lurk.org

Welcome to post.lurk.org, an instance for discussions around cultural freedom, experimental, new media art, net and computational culture, and things like that.

<svg xmlns="http://www.w3.org/2000/svg" id="hometownlogo" x="0px" y="0px" viewBox="25 40 50 20" width="100%" height="100%"><g><path d="M55.9,53.9H35.3c-0.7,0-1.3,0.6-1.3,1.3s0.6,1.3,1.3,1.3h20.6c0.7,0,1.3-0.6,1.3-1.3S56.6,53.9,55.9,53.9z"/><path d="M55.9,58.2H35.3c-0.7,0-1.3,0.6-1.3,1.3s0.6,1.3,1.3,1.3h20.6c0.7,0,1.3-0.6,1.3-1.3S56.6,58.2,55.9,58.2z"/><path d="M55.9,62.6H35.3c-0.7,0-1.3,0.6-1.3,1.3s0.6,1.3,1.3,1.3h20.6c0.7,0,1.3-0.6,1.3-1.3S56.6,62.6,55.9,62.6z"/><path d="M64.8,53.9c-0.7,0-1.3,0.6-1.3,1.3v8.8c0,0.7,0.6,1.3,1.3,1.3s1.3-0.6,1.3-1.3v-8.8C66,54.4,65.4,53.9,64.8,53.9z"/><path d="M60.4,53.9c-0.7,0-1.3,0.6-1.3,1.3v8.8c0,0.7,0.6,1.3,1.3,1.3s1.3-0.6,1.3-1.3v-8.8C61.6,54.4,61.1,53.9,60.4,53.9z"/><path d="M63.7,48.3c1.3-0.7,2-2.5,2-5.6c0-3.6-0.9-7.8-3.3-7.8s-3.3,4.2-3.3,7.8c0,3.1,0.7,4.9,2,5.6v2.4c0,0.7,0.6,1.3,1.3,1.3 s1.3-0.6,1.3-1.3V48.3z M62.4,37.8c0.4,0.8,0.8,2.5,0.8,4.9c0,2.5-0.5,3.4-0.8,3.4s-0.8-0.9-0.8-3.4C61.7,40.3,62.1,38.6,62.4,37.8 z"/><path d="M57,42.7c0-0.1-0.1-0.1-0.1-0.2l-3.2-4.1c-0.2-0.3-0.6-0.5-1-0.5h-1.6v-1.9c0-0.7-0.6-1.3-1.3-1.3s-1.3,0.6-1.3,1.3V38 h-3.9h-1.1h-5.2c-0.4,0-0.7,0.2-1,0.5l-3.2,4.1c0,0.1-0.1,0.1-0.1,0.2c0,0-0.1,0.1-0.1,0.1C34,43,34,43.2,34,43.3v7.4 c0,0.7,0.6,1.3,1.3,1.3h5.2h7.4h8c0.7,0,1.3-0.6,1.3-1.3v-7.4c0-0.2,0-0.3-0.1-0.4C57,42.8,57,42.8,57,42.7z M41.7,49.5h-5.2v-4.9 h10.2v4.9H41.7z M48.5,42.1l-1.2-1.6h4.8l1.2,1.6H48.5z M44.1,40.5l1.2,1.6h-7.5l1.2-1.6H44.1z M49.2,44.6h5.5v4.9h-5.5V44.6z"/></g></svg>