logs

This leetcode crap is taking so much longer than I expected. Ugh. I spend the most time working on problems related to data structures and algorithms I never actually looked at. The most effective strategy is to put the time into doing some research and studying sample problems before attempting the leetcode problems.

359, transcribed skiena string compare to Python

1137, 746

790

875, Reading about backtracking.

Reading Skiena on Dynamic Programming.

374, 2300

2300, 162, 875

2542 (continued), 2462,

215, 2336, 2542

2542

399

399, 1926, 994

547, 1466

1466

450, 841

DBINT

Adding in time logs up to this point.

At this point, I have attempted about half the problems of LC75. I think I've chewed through most of the easy problems that I could do quickly. What remains are the sorts of problems I'll need to do more research into. I'm ready to slow down with these and change gears a little bit.

1372, 236

199

1161, 700

437 (partial)

437 (continued)

Even more 437.

cell layout, slotted pages, checksumming, managing variable-sized data

Summary: The "Algorithm": there are usually 8 different kinds of things you can use to solve a given technical problem: Hash Tables, Linked Lists, Binary Trees, Depth First Search, Sorting, Dynamic Programming, Recursion. By asking about the runtime and seeing what the problem is asking for, things can usually be reduced to about 2-3 options.

This was a pretty short overview. Going to need to find more books/resources on the subject of Trees and Graph traversal. Off to The Algorithm Design Manual.

104, 872, 1448 (partially, going to revisit soon)

1448. I gave up and looked it up. I was in the right direction with the recursive answer. C++ classes in the solution made it much easier. count was essentially kept as a global. When I didn't have to think about keeping track of that varibale in a recursive function, the problem and code got a lot easier to reason with. Lesson learned.

2095, 328

206, 2130

1657, 2352, 2390, 735, 394

933, 649

643.

1456, 1004.

1493, 1732, 724, 2215.

1768, 1071, 1431, 605, 345, 151, 238

334, 443, 283, 392, 11, 1679

And then it'll be done.

It's a good proof of concept for a proof of concept. I can return to it later, if I need it.

See: <<misc/i_miss_lorina_bulwer>>.

On second thought. This might be a little too intense for the RC crowd. But, I might give it a go anyways.

I might turn this into tamer prose we'll see.

But I have a working demo that I think I can post today.

I think it'd be a good exercise at some point to go back and try working through the exercises. But, for now, I think I'm at a decent enough stopping point.

I think it would be nice to work this out in such a way that it exports JSON data for the patterns. Probably just low-level row information for now (Serde?). Later that can data can be analyzed by other programs to do things like extract notes and durations and so on.

I'm trying to pick out some of "Scavenger's Reign", a show I just started watching. I really like this show!

It's too bad there isn't a good way to display this right now. I'll have to get an ink dagzet working at somepoint. Maybe.

I read the chapter in one sitting. I imagine it's much easier to read about implementing an assembler than it is to actually implement one. At some point, I'll try to find time to actually work this all out.

Teach Yourself Computer Science (TYCS) recommends reading the first six chapters of this book. I have done this. I think this is good enough.

Might go back and check at some point.

Got far enough to do some initial parsing of pattern data. Good enough for me for now.

I think I know enough Rust where the "it's in Rust" part isn't all that challenging anymore. There is one definitive spec file for IT.

Just some sine pulses.

Didn't get far at all.

Looked into this a while back. Going to give it another look today. <<trackers/ft2play>>.

I want to see if I can get this working on my machine without any modificatoins. From there, my hope is to try and remove the SDL dependencies. Then, I'll re-assess the codebase and see if there's anything else I can do to simplify it.

I've also created a test file that renders and compares outputs.

It might be quite easy actually to rip out SDL.

The thread is now gone. The code comments actually planned for people like me.

Dummy driver surprisingly straight forward. Really seems unnecessary since we're just using WAV renderer. SDL2 deps are gone it seems. I've also flattened the directory a bit.

Much smoother than I expected it to be, really. Next up, I'd love to rework the command line so it just something like "ft2play in.xm out.wav". From there, import it into mnolth?

I want to attempt to make the output reasonably clean if before inserting into mnolth.

Hey, not too bad these warnings. Not too bad, 8bitbubsy.

Actually, all those warnings introduced were mine. Oops. Very well done, 8bitbubsy. You are giving me a very enjoyable experience here.

Well, not it isn't. But nothing ever truely is.

Once I got past the C++ comments, the real stuff started to appear. Usual suspects.

This is a waste of my time. It doesn't actually do much for me for portability.

It really should aim to choose the closest pellet.

The only sound I have in mind right now are the sounds of placing pellets. One of those bubble popping sounds. Like the sounds on the switch.

The "consume and become larger" mechanic was an interesting ad-hoc idea. But it's Katamari Damacy. I should look into that game. They have a crazy soundtrack from what I remember.

I want to play with better colors here. Manic Japanese pastel colors. Think Kirby and Mario.

I think this game soundtrack should feel very tactile.

Maybe try to get this working in a tracker?

Looks like you can just do "cargo install c2rust", which is pretty awesome if it just works.

LLVM issues. Installed llvm-dev, trying again

another error: libLLVMDemangle.a does not exist

Let's see if this works.

Restarting, then trying again. The library does seem to be there.

I found an arch page that has it in LLVM18. I installed LLVM17. Let's see if that does anything.

The most promising command so far:

#+BEGINCONFIGSRC

Someone already made it. See <<rust/crates/xmrsplayer>>.

See: <<rust/crates/xmrsplayer>>.

Well it builds, but once again I run into the usual snags with CPal and ALSA.

People, add a fallback offline wav writer. Jeez.

Wonder how hard it would be to work that into a my monwav voxbox writer.

Did not know you coul do the thing with "cargo add xmrsplayer". That was so easy.

But ah yes, now the infamous build time.

It works!

I am not getting a warm feeling about this one.

No clicks, but this one is out of tune. Also very soft gain.

Not worth the time investment here.

wii music: good vibe. something about the timing

getz/gilberto girl from ipanema: there's something more playful about this pairing. I think it's cuz there's a bit more of film cliche happening.

Severance OST Theodire Shapiro "Labor of Love": The triangle makes this very funny. It's definitely a matter of tempo.

wii shop: ~170 BPM, ipanema: ~140 BPM, severance: ~125BPM.a

Desafinado Gilberto/Jobim/Getz ~140 BPM. This one also is very playful juxtaposition.

Didn't actually get anything done. Heading out.

Had a nice high-level chat with RB about a possible implementation. He called it an "object pool", which is pretty much exactly what I'm going after.

So, poke is really bumming me out. It's too much abuse.

Using no sound, just circles, to try out this initial idea.

There is a big white circle on the page. You click to place other smaller black circles (pellets). The circle waits, then moves to each circle to "eat" them, then repeats the process until there aren't any other circles.

Yesterday I showed another person my Poke demo [0]. Another very visceral response: "why did you make me do that to him?"

On the one hand, I guess I should be pleased that I am getting strong reactions to my art. On the other hand, no, not like this :(

I find myself agreeing with the reactions. It's very hard to make the "poke" action feel consensual. Even a "tickle" is an invasion. I wanted to build something whimsical, but I didn't really consider the implications of the mechanic. No matter how cute or whimsical the design is, the poke negates all of this.

I feel a little more deflated than usual about this. With "Poke", it sometimes feels like I've accidentally added a bit more cruelty in the world, which was the exact opposite of my intention.

But, weird stroke bug in firefox. The line has variable thickness, and some dots. In chromium, this is a non-issue.

Somehow need to convert times to be pixels per second.

It's traveling on a line, so maybe just the line equation. It can be a normalized slope velocity too. Something to add to a point until it reaches a target.

So, calculate progress, and then use an easing function to make it so it can slow down or speed up to a target.

It's not quit what I wanted it be. I'd need to rework it to make it work with easings. The current implementation just calculates an relative trajectory, and I'm adjusting how fast that trajectory goes based on the position. interpolating between two points would be better.

Behaviors now have different interpolation schemes. They are also randomized now, and can have randomized speeds.

When they get too big, there should be a forced pause, and the Blob should shrink again.

Like it's about to burst.

It chooses chords too quickly (when the lead changes), and should only think about changing chords when the lower/upper notes happen. I had a concept of "committing" to a chord. A faster thing might be to just move the chord changes to when the lower note triggers rather than the lead.

Also, I want tonic bias. Every 4 non-tonic chords or so, there should be a switch that puts tonic as priority, it if it is available as a candidate.

I've just been noodling on this thing for the past 15 minutes.

That's how I know this is close.

I want to see if I can get the webaudio API to request a sampling rate (44.1kHz) because the voices are just going to sound better.

I am now coming to understand why gnuspeech decided to go the route of resampling from 16kHz to the host sampling rate. It's just going to sound better that way. The changes sound too weird.

I'm finding it's very hard to find in my interface, because the sliders end up being very close to zero. I almost feel the urge to have a min/max slider too to be able to "zoom in".

Oh wait, I made presure the input, which you would vary with an envelope. That's amazing. Good idea, past me.

I think it's time to move on.

It takes way too much time to try out sounds in the webaudio workflow I have. Having to recompile the wasm, go to the web browser, refresh the page, and have it maybe not reload because browsers can sometimes be weird about WASM stuff specifically, was apain.

If I were to do this again, I'd build a native version before getting it working on the web.

I am putting it in google docs and fitting it manually into the resume template. it is slow.

R mentioned this, and it's been a sentiment that others have mentioned as well. p5 just makes canvas calls anyways.

Following <<webdev/using_pointer_events>>.

Issue was a chrome mobile related issue. Had to use CSS to set touch-actions to be none.

Once again...

Interesting, the parser becomes stricter. I need to formally declare "i" in my for loop. All done by simply add "type=module" to my HTML script element.

Figured it out: it was the callback mechanics of requestAnimationFrame.

Solution: encapsulate in then.

I'll have to do the rest later.

I'm mouse events are happening either way

Logic bug. And should have been an or. Struggled to clear cache on Chromium too.

I'm not going to do macros, I'm just going to comment things out.

Had to generate cdylib.

It went from unknown opcode 192 to 193, after I commented out all the panics.

Nope, that wasn't it. Sigh. Gotta bisect.

Bisect tracked down the quick bugfix I made that checked for valid lower/upper values.

Opcode 193 is something that extends a signed opcode, which caused wasm-gc to panic. The lines that do that are in the measure_movement function. It was quick to find because it's the only time I deliberately cast from unsigned to signed. I happened to use i16 which caused the panic to happen. However, changing to i32 made things work just fine.

The exports and the interface are already there from the C prototype. It should mostly drop right in.

I wasn't passing in the dsp parameter.

I did, however, manage to get jackdaw running on my computer <<misc/jackdaw>>. I was very impressed with project, and didn't realize just how much tooling was built for it. Things like a layout editor, a YAML parser, and an XMl parser.

The audio devices weren't querying correctly on my computer, and we discovered that it was most likely a problem with SDL on my computer.

Added a new shape. Really expressive now. Vibrato not as bad as I remembered (with headphones on now instead of speakers).

Should resolve to tonic more often. There should be a built in bias to choose tonic.

I'm desiring the instantaneous mode again.

The chord changes are happening too quickly. If I select a pitch, go down quickly, and og back up, the chord shouldn't change. But it does.

Right now, a changing pitch triggers a set of chord progressions. But if they move too quickly, only the last one is heard. Which means effectively an arbitrary chord transition.

How to prevent this? A chord isn't a chord until all 3 voices commit. If the lead changes pitch, it uses the stored chord as a reference point. As it continues to change, this chord will continue to be used. The upper voice is the last person to commit to a chord, so only then should the reference chord be updated.

When the chord is officially committed for selection, only then does that chord get registered in the chord frequency table.

Oh my god this is consensus in a distributed system.

What are the changes?

Talk about Recurse Center. Looking at other resumes, should go into "education section". What did I learn about? Some topics, ordered by time investment: Rust, React, Typescript, Low Level Computer Architecture, (elements of computer systems), Gameboy Development.

More notes on Boomy: "Optimized WAV file generation using X and built method for measuring throughput". Prototypes: Describe what was built, intended functionality, tools used. It's okay if they weren't actually used.

Muvik: "Designed and implemented core audiovisual rendering pipeline in C and Lua". Also include bullet for study and link to patent.

I'm not consistent about ending bullet points with a full stop.

The education section is just bullet points. Not much detail.

oh hey, it looks like I already had some details for this one.

Okay no details.

Even though I still want to tweak the chord selection algorithm, the core work is done.

Doing this by hand, as a learning experience. Poke used as reference.

I am using "modules" now to help me better break up my code ahead of time.

Trying to do this the mildly correct way.

I'm making a new class off of p5, adding my own data to it.

No WASM bits yet, though there should be placeholder

Wrapping up this session.

Using this guide: <</digitalocean_typescript_new_project>>.

npm -i typescript --save-dev

npm i gts --save-dev

npx gts init

This seems to solve the formatter

npx tsc

Accidentally deleted sketch.js.

Might as well try typescript again.

There is literally one line that is the issue. I am going to attempt to patch this on my end.

I believe I have identified the entry points for the chord manager in the existing code, and I have built an initial dummy interface for it. There is a failing test now with the methods.

If I can implement this interface, I think it'll be ready for actual integration.

Upper/lower voice selection is based on minimal distance from lead voice. This could also change to be based on the minimal distance from the voice it is currently at while also being above/below the lead.

Writing this down, I'm realizing there's potential for chaos (an upper voice that somehow keeps drifting upwards, for instance). Could be a cool thing though.

Also running into a bug with chord harmonies. I get wrong chords. If I keep tapping on Do, I'll land on sustained chords, which aren't correct.

Still not fixing the bug I described above. The lower note is incorrectly holding onto the note of the previous chord for some reason.

Retriggering the lowest note causes it to alternate between a major chord (correct) and a sustained chord (incorrect) The upper note is correct, while the lower note is incorrect.

The state transitions aren't shuffling through the states as well as I'd like. Also, there's too much unnecessary voice movement.

How can the system choose interesting chords and also minimize movement?

Specifically: I want the system to be introduced to the minor 4 (without resorting to randomness), and I want the voices to resolve in an expected way.

It is a constraint problem. Each voice has different behavior.

Upper voice should move as little as possible while still being above the lead voice.

Lower voice should move the minimum number of steps required to complete the chord, based on what the current upper and lead pitches are.

New heuristic idea: of the candidates, choose the least used chord so far. Probably keep a running heat map. This solves the chord selection problem, but not the voice leading issue

Another heuristic for chord selection is to find a candidate chord that requires the least amount of movement, given the current upper/lower pitches. This would require storing the current pitches of upper/lower, calculating the upper/lower pitches for each chord, and getting the combined step change for each chord. The one with the lowest score wins.

These are two different heuristics for selection, and I can imagine there would be a way to choose one over the other.

Least movement: for each candidates, get the working upper and lower notes of those chords given the current lead pitch. Get the absolute differences between those and the current lower/upper. The one with the lowest score wins.

A good hybrid could be something called "Lazy Least Used". Go for the least used, but only if the movement required is under a certain score. Otherwise, choose the one with least movement

Firstly, make sure the low-level chord measurement mechanics are in place and working properly. Then, simulate a chord change.

You need to store what the pitch actually is somewhat reliably. There isn't currently a caching mechanism in place for this.

The entry points for this happen when a pitch is actually scheduled.

Minimal movement means lots of situations where a note stays the same.

Shouldn't really matter, for now. It'll cause more complication if a check is introduced (for example, handle what happens if there is no previous note).

Lazy Least Frequent Heuristic, Y-axis expression.

Nice thing to have: some way to go from staggered to instantaneous behavior.

Fixed.

This one seems difficult to make a test for. I am tempted to just implemented it without tests, as the amount of effort it would take to find the perfect test situation wouldn't be worth it.

This is a good stopping point for my chords engine.

Write permission issues.

It occured to me yesterday that I am actually close to a proof-of-concept system. I already have one heuristic working. I don't need to build out the others yet.

I do need to build a fallback set of chords in case a chord isn't found for a particular note.

Instead of a lookup table, dynamically find the closest voices above and below a lead note given a chord.

I am incredibly exhausted today. What a long day.

I can test it out in Poke

Query: given a current chord, and a new lead note, find all the valid chords to transition to.

This requires moving the mutable stateful stuff out.

I am trying to transition D4 in the key of C. This should give me two chords (G and Dm). But I'm getting no chords.

Ah, my "RE" constant was miscoded. Phew.

Chords need to be removed.

Oh just figured it out. I was using "chord index" instead of "index".

This has an interface that applies the heuristic to the candidate, which effectively removes the previous chord in place.

I'm querying the chord, removeing the previous transition chord, and updating the note pair table in 3 separate steps. It feels maybe too low-level and could be consolidated better?

It has no effect at all apparently.

I'm 99% sure it's the problem, but is it worth the problem?

There are two kinds of references right now: zero-index and one-indexed. The one-indexed ones are used because it means 0 can be reserved for None. was_used_last expects a zero-indexed chord. But really, these indexes are transparent for the most part. add_chord returns a zero-indexed position as well.

I think it makes sense to 1-index everything because that 0 is so critical.

Wow, that was tedious. Glad I had the tests. It almost makes me wished I used Option...

There is no way to account for this yet. It will catch it as having zero candidates though.

Because it's harder to calculate what that second index is going to be. There also needs to be a check to make sure prev/next is not equal.

I have just created the task for it.

I got some good suggestions.

The initial structures: chords, and valid chord transitions.

We want to make a query: given some pitch (0-11), and a current chord, provide a range of potential candidates for the next chord.

Since this is going to be used in a realtime situation. My thinking is to populate with a pre-allocated fixed size array that is managed internally.

There's one timing issue that I'm going to look at, but that feels like another task.

Sometimes, when I put the pen down on the tablet, the lower voice will wait an extra beat before turning on. I can see in the window that the time value becomes "1" twice, which I don't want to happen.

I think the issue here may have to do with how I am handling clock resets. It's possible that I missed something when I quickly add it in yesterday.

The sound could be done to facilitate this better. But I also think the eyes should change from bug-eyed to the kawaii "> <" eyes.

The graphics will be a faster change than the sounds, so I may want to get started on that in the next day or so

The issue is there is no sense of resolution anywhere. It still kinda meanders.

The test I had for it was too small.

"cx" is an external connection, and it allows you to make connections to nodes that are external

A partial implementation of cx is all that is needed for now. No aliases, no shorthands. It's all just full paths.

Any nodes used by cx get stored in a list (set?). When unknown nodes are checked, if it can't find the node in the locally created nodes, it'll check the nodes here.

Connections will work the same way since it utilizes a SQL command. The burden is on the dagzetter to ensure that nodes get created before they are connected with cx. This is different from co, which follows a more declarative style.

At this point, any unknown nodes should have checked for.

Is there ever a situation where an edge would have an unknown node missed by the unknown node error check?

It's a sqlite error. I need to figure out what the error is.

I need to use db:errmsg

I didn't configure the column name correctly.

I'm going to have to call it quits after this.

It is random too, probably due to randomness in lua tables.

Something is going wrong in the SQLite table generation. When I place debug prints in the shortname generator, I get a ton of stuff.

My goal is to take a look at the generated table outputs of both.

This is probably due to the randomized hashmap structure in Rust.

But, the node IDs are the same, monotonically increasing unique values.

There seems to be duplicates. I generated and sorted the connections alphabetically and found these.

The rust version also has inconsistent connections as well.

It is consistently this. I wonder if "cx" is partially to blame. disabling all the cxs now.

There are 15 cx connections made, and that accounts for the missing connections.

Now, let's see if the error goes away.

I think I really mean it this time. It generates the data without crashing and everything. Peaking around, it seems to produce the data just fine.

I am putting it in "main" instead of priority.

Let me get these last few projects in a good place (demo-trio and dagzet-rust), and then I'll try to find time to start this?

I know, I know. I'm putting it off.

Classic mistake: forgot to add BEGIN/COMMIT

This one is slightly more interesting because of how the data is represented in SQLite vs how it's entered in dagzet. From a dagzet point of view, tags are a list of entries associated with a node. In SQLite, they boil down into pairs.

Tags should be able to be called more than once.

I think I'm only going to have time for the initial test before I break for lunch. Maybe.

I'm not sure why it's not getting the correct number of tags? Oh well, will have to look at it later.

I was misinterpretting the boolean result of the hashset insert method. Negating that fixed stuff.

tags finished.

I think for the most part these could be thought of as integration tests.

Nevermind. I just won't fight it right now.

Installed with =cargo install --path .". Replaced my lua program with my rust program. Looked around on the generated ouput. It seems to be right so far? Publishing to see what will happen.

Yeah, it says it is fine. so that's pretty cool.

I've done enough for one session. It's almost there.

It should have crashed. Make it crash, then I'm done for now.

oooh. the "dagzet" tool and "gendb.sh" are different. I gotta replace it there.

I need better error reporting. It seems like this version of dagzet has stricter parsing (you can't have duplicate tags, for example, whereas my old implementation could).

Going to create an interface where hooks are automatically appended and interated through.

Lower voice seems to behave as expected.

Most of the event logic behaves as expected. I'm a little stumped as to why is starts so late. But it feels a lot better now. What's important is that I can reason about it now, and construct simulations in a very precise way.

I think the event handler needed to reset the head/tail indices as well. That fix seemed to clear up all the gesture related issues which I was suspecting.

Leetcode provides validation of solutions, which is nice. But having a format that distills the problems into something offline for reference would be nice.

I think I might just manually transcribe the questions to markdown and put them in a repo.

I'm trying to more formally establish a way to manage how the voice scheduling works for trio.

I have the basic actions and primitives for the most part. Now, they need to be composed and worked together to trigger events for the other voices.

These events need to be triggered exactly once.

Event triggers at the start of a tick.

In a test, one should be able to tick() then ask the state questions. Is the voice supposed to launch? Is it playing already? Did the voice just turn off? Is it supposed to turn off? Etc, etc.

These events need to happen exactly once. Tick, check and see if things need to be done, tick, those things are done.

prev/curr state system could probably do this? At each tick, update prev to be curr. So, that means changes and probing would have to happen together before the next tick?

I was trying to figure out when to trigger certain events like gates and pitch changes. I was has having difficulty getting to the bottom of pitch changes for auto voices: when they are initially turned on (happens when the gate is first on), the pitch needs to be instantaneous, otherwise it is scheduled. How does the voice know the difference? What state information is needed?

This is the best I got so far.

Consider the state needed to determine a pitch change for an autovoice: it happens when when the lead note is on, and the timer has reached a particular value. An extra value could be used to determine whether to immediate set or schedule based on if the voice is turned on.

An auto voice will always be immediately set to a pitch first, and would therefore set the voice flag to on. Subsequent voice changes will be scheduled until this voice flag is turned off.

The only way the voice flag is turned off is when an gate off event happens. This will turn off all the voices in the state.

I'm tempted to have this be a set of state separate from the current set of state. I believe you could make the case that the flow of information is one-way: changes from the main state influence the states of the auto voices, and not the other way around.

Separating state like this I think will make it easier to test.

Right now, it doesn't know the difference between an instantaneous vs scheduled pitch change, but the scaffolding is there.

Okay, nevermind.

Haptic rotary knob controllers. What was I supposed to do?

Prev: DAG Zettelkasten / generates database code / more will come later Next: || dagzet-rust: Figure out remaining commands needed to get things working in the RC dagzet, and get them working in the implementation

I just need enough to generate my RC dagzet and replace the lua implementation.

The results of my shell-ing:

$ cat *.dz | awk '{print $1}' | grep -v "^$" | sort | uniq -c
    127 co
     50 cr
     15 cx
     59 fr
     38 gr
    165 hl
    357 ln
    280 nn
     40 ns
     96 rm
      1 sn
     15 td
     76 tg
      4 zz

Done: co, cr, ln, gr, ln, nn, ns.

TODO: cx, fr, hl, rm, sn, td, tg, zz

Wow that's more than I expected. And there's going to be a non-trivial amount of time troubleshooting the SQLite generated code because of course it's not going to work on the first try.

More slow, incremental testing?

No, the errors are going to come from incorrectly generated SQLite code, and SQL code validation is outside the scope of dagzet.

I need to generate that once, and cache it in dagzet.

The connections can remain as strings.

Oh yeah, that's right. This has some shorthand behavior as well. '$' is used to reference the last file. This might take up the rest of my morning before I break.

Some of the slowness comes from building up the test correctly. I'm doing this one right, becaues I've already done it wrong.

Comments in place, testing a handful of edge cases. Now I just need to implement incrementally. That's for another time.

No. Not it does not. Typical glibc woes.

Most of this boils down to string generation. It'd be good to have some intermediate structures before that.

Being able to generate sqlite schemas is a good start. A table as named values, each with a type.

It would be nice to have a consistent ordering of these names, for things like generating insert statements.

A table itself also has a distinct name.

stringify() could be a behavior that types and tables implement.

Ah, stringify is already a behavior the standard libary implements.

The best thing would be to have some struct map to the VALUES part in an INSERT statement. A method on the table, such as sqlize_insert, could then take in a pointer to a struct implementing that row that's able to generate values.

Trying to un-confuse myself: supposing I had table A. I'd want to make it so A.sqlize_insert(row) would generate an insert statement from data in row. Another table B attempting to call B.sqlize_insert(row) would get a compiler error due a type mismatch.

Generics for trait? Like this trait can only work when the type is A, not B.

The table schema itself needs to be a concrete type, which it is not right now. If that happens, then I can make a row type for that table.

Define the interface that I want to see in a test, then work backwards from there.

See: <<rust/phantom_types>>.

Real quick stuff.

Lots of elaboration needed, but it's a great start. Things work.

I'm trying to rework the nodes table code into something more re-usable.

It feels like it's just starting to slip into something out of my grasp.

This makes me feel better. It has an easy code smell.

Make this an interface somehow?

you know what they are just going to be functions. refactor later.

I'm hoping to use the trick in C where the file handle can be standard out as well as a file.

Let's try the connections table.

Most of the hard stuff is accomplished I think.

I turned on gesture again, and I think the wrong notes are caused by the event graph not removing events at the right time. I think. Anyways, this needs to be rebuilt for sure because I don't want to live life doing guess and check.

My goal is to use this rust port as a drop-in replacement for my current dagzet program. So, a good thing to do would be to write a program that scrapes all the current commands used in my RC dagzet instance.

I also have more than enough here to begin working on implementing topological sort and SQLite code generation.

One of the things I am doing in Trio is forcing a phase reset on pen down so the voices always stagger the same way. The funderlying rephasor in the gesture signal generator does not have a way of handling phase resets, so it'll assume a faster tempo change and cause unwanted jumps in time. The rephasor needs a way to be told that there has been a phase reset, which would cause it to skip calculating the delta time in the next sample tick.

I wonder if we can build a test around this?

I want to not only do the fix, but create a test in the test suite that showcases the problem before the fix is created, just so I know that I properly understand the problem that I am trying to solve.

This is more difficult than I expected. A connection remark needs to reference a connection (the last connection made). So, how does one reasonably accomplish this?

Since the connections are a pair, one approach is to use a 2-dimensional hashmap of values. It feels like a lot more space is used up here. It also duplicates some of the logic in the connections hashmap.

Another thing to do is to somehow reference the connection. An actual Rust memory reference could cause the borrow checker to be grumpy. Using unique ID values to reference each connection, and having that be a key in a hash table could work. This could become a bookkeeping problem if I ever added the ability to remove connections, but there are no plans to add such a feature.

Connection ID can be their position in the "connections" vector.

Since there is no way to selecting a specific connection, it is reasonable to assume that the last connection will always be implicitely be what remarks are being written to. So, the ID will always be length of the vector (minus one for the index).

It was silently erroring. I needed to add a namespace.

I initially thought I was ready for topsort and cycle checking. But unknown node resolution should happen first.

An edge list should be created from the connections for the topsort. But those should all be resolved ID values. "Check unknown" nodes should return a set of nodes that do not exist in the node.

Rust does have a set in their library! Huzzah! Called HashSet. That's what I need.

The trick here is that the connections need to be resolved, which is another step to test independently.

A connection list, after it has been verified, should be turned into an edge list. This function is still allowed to error out. This edge list then gets passed in to the cycle checker.

Note: Topsort makes use of sets that will expand and grow. I expect to dynamically generate these inside the function.

Generating an edgelist should come first. Panic on missing nodes for now. that can be fixed later.

The top-level cycle checker should be a method called check_for_cycles. The original implementation was able to get some information on these cycles.

Looks like the original topsort populates a "loops found" list. I will do the same, only it'll be a HashSet. On success it will return an Ok, otherwise an error code.

Implementation will come next. Signing off for now.

Somehow, this needs to simulate a phasor reset, and measure specifically what goes wrong.

I need to re-remember how this rephasor works. Luckily, I wrote documentation for the C implementation.

The current rust implementation is a little cryptic. Add docstrings now.

Establishing a line of thought here.

A phasor reset occurs when the ramp suddenly resets back to 0 in the middle of period.

In this scenario, the reset happens as a result of an intentional interrupt. It is known precisely when this interrupt happens. The rephasor is called immediately after this interrupt. For this reason, the idea is it can be told ahead of time that the phasor reset itself, and to act occordingly.

Other than the interrupt, it is assumed that the clock is moving at a steady rate.

In order for the rephasor to handle a reset phasor properly, it must keep the overall increment amount approximately equal to the increment amount of the phasor. Any jumps indicate a failure to handle this result properly.

Assmuming rephasor scale amount is 1 (same as input), the increment of the rephasor is determined from the correction coefficient and the delta of the previous sample.

Possible solution: don't update anything with the clock reset artifact in it. Wait for it to pass through the system before updating correction and incrementor.

I think waiting two ticks should do it.

I wrote the test wrong which is why it was failing in the first place. But, now it works.

I think this test might be resilient against this particular kind of reset beacuse the phase goes to exactly 0 and also that the overall slope doesn't change.

No changes needed. But the test is in there to prove this.

I'm feeling a little overwhelmed at the moment.

Erased my changes. Took a breath.

It did not crash. Not one crash. Thanks, Rust.

This can be like a method or something like immediate(). Setting the next/prev values to be some scalar value should work for the most part. The event queue should also be cleared as well.

There's too much spaghetti right now. I think I need to actually attempt to model this as a state machine and add some tests. Otherwise, I'm never going to figure out the issue, and this code will become too unwieldy to maintain.

Not sure if this is my scheduling logic, or some subtle bug with the gesture event queue, or a mix of both.

Testing is definitely in order. But like, not today. I'm pretty drained.

Yeah, considering I want to change the chord selection logic, it's going to be even worse. This needs a rewrite.

I have built what is essentially a concurrent event system. So yeah, this is tough one to do correctly.

More reading on sequential logic.

Attempt voice staggering using event-driven gesture algorithm, see what goes wrong.

It's got a good scope, it's got data structures, and I'm putting in the time to incrementally test as I go.

This is also a migration project. If I do this right, I should be able to drop in the dagzet program and have it replace my adhoc lua code for my knowledge tree generator, which I'm using to power the knowledge graph here.

vscode does not work on Alpine, and NeoVim works well for my needs.

See <<rust/clippy_book>>.

hashmaps are used as the data structure to ensure that a node isn't created twice.

if I wanted to get a node name from a string, how would I do that? Right now, the answer seems to be enumerate through all the keys and find an answer. I could also just make a separate inverse lookup table out of a vector.

It's a memory hit, and there's room for the eventual possibility that the tables will go out of sync. But, it's good enough for now. I imagine I'll be doing this lookup operatoin quite a few times I don't want to do a linear sweep every time.

Variation on a theme, I suspect. Unplugging and getting lunch now.

Now that I supposedly have an event-driven gesture, I need to begin work incorporating those mechanics into the existing demo.

Now, for the initial process of introducing these eventful gestures.

Before any events can be added to any gestures, we need to be able to simulate adding events. Events should only be added after the lead has held onto a pitch for one period.

The easiest way to do this using a global timer that keeps track the phasor ticks, which occur once a second. If a u32 is used, how many seconds is that?

Okay, so that's about a millenium short of 50k years. I think there's no general risk of things overflowing. I will be long dead and forgotten before that happens to a potential user.

Is this enough granularity though if I want to detect pitch changes? Maybe not actually.

Might need to ink this one out.

First, implement things so that it detects changes in pitch. Then, build a sample and hold with along with a global monotonically increasing clock that increments at the start of every tick.

Now, any time a pitch change occurs in the lead, it can be compared against the sampled pitch. If the pitch is different, but the timestamps aren't, the whole period is marked as having been changed for the rest of the period.

The "dirty bit" trick is used in situations where the pitch changes quickly inside a period.

I think there may be another state required.

How about this: If there has been a requested pitch change from the current lead pitch, and this request has been held for a period, apply this changed pitch to the current lead.

This should happen at the start of every period.

I was setting things to be negative oops.

Caching the lead value and also storing the last changed value may be what I'm looking for.

Essentially, this lead value needs ot be updated regardeless, but the other two voices need to be delayed.

I can't simply cache the last lead pitch every time because I'm setting it every time.

Now I am looking to delay chord changes on the upper/lower voices.

I think I'm going to have to do this anyways because the event scheduler in the eventful gesture is so small, and can really only take one vertice at a time.

The logic would need to be: lower gets set first, then upper.

Initially I had it so that the chord would be determined, and then you'd send off the events with delays. Rethinking this a bit.

I want it so that the upper pitch only changes if it waits 2 beats, and the lower pitch changes if it waits 1 beat.

I want to have a state when the lower changed, but the upper hasn't. When the upper gets changed, the lower changed gets setup.

This causes some very rude sounding glisses sometimes.

I co-presented with Dan and Seamus on "bbl_vizzy".

First time at stickies. Would go again.

DF had a good pair of questions for me. First one was "what is NAND?" "Not AND". Follow up: "Why NAND? Why not AND?". I could not answer this well, but luckily JK was there. I am paraphrasing, but it turns out that the negation operation is important for Turing completeness. You need the negation to do things like turn a 1 to a 0.

Both NAND and NOR are what are known as "universal gates", in that they can be building blocks to implement the core boolean operations like AND, OR, and NOT.

I figured out that some of the example game does have sound working. I don't know what I am missing here. Don't think I'll have much more time for this during my batch though.

I don't think I can justify putting more time into this, unless I can make something that is presentable.

I don't love this. This feels like busywork.

I'm crashing when I run cargo clippy. Let's make it not crash. I can deal with the warnings later.

Scalars are being handled, now to work with the other types.

This is why nothing gets done. I've been wasting time trying to make Clippy happy all in the name of supposedly "better" code, and I'm almost 45 minutes with nothing to show.

It warps the brain, seeing all these squigglys in an editor. Like a teacher marking up an essay in red. I don't think it's actually possible to turn syntax off in nvim. The usualy "syntax off" trick doesn't work.

I think it's reasonable to think about starting the Gesture.

I'm liking these incremental tests. What's a good way to test that things are working as expected?

For starters, I need to be able to initialize this gesture by pushing an initial set of events.

Behavior we want: events should only be processed at the start of a new phase.

Situation: I push an event A and call preinit. I then push event B, after the tick is called. What is the expected set of states for each period?

Pre-init sets things up so that our first period for sure starts with A. I believe that first tick sets things up such that the next state it is transitioning to is also A. Either that, or it is uninitialized. Not sure. Checking.

My test is currently failing to get the next point as expected.

Oh wait, it's because I'm checking the external clock's phase changes, not the internal change.

The order that things get set is very crucial. I want to see if I am doing the timing correctly here.

It is eventually correct, but I have to wait about 5 samples after the first period.

Before the first tick, event A is pushed, and then preinit is called. This triggets the next event to happen, which dequeues the event and sets the value.

At the first tick, next vertex is called immediately. There are no values. The cached vertex is left unchanged, so it is still A.

Note to self: I am using new_period wrong. The timeline

Event B is pushed as an event before the next tick. It will not be read until the next period. When will the next period happen? The current phasor is currently set to have a incrementor value of 0.1, so 10 samples per period. The rate multiplier has been set to be 2/3, which is like slowing things down by a factor of 1.5. The test does seem to pass after about 15 samples through trial and error.

I need keep track of the interal rephasored value and watch for new periods there.

Works!

Wait are events that tell the clock to wait some number of periods before processing the next events in the queue.

A wait time of 1 will wait one whole period before allowing further events in the queue to be processed.

If I push a wait of 1, and then a scalar in the middle of period A, the start of the next period, B will dequeue the wait, and then suspend reading other events. At the next period C, there will no longer be a wait, and the next value will be set.

This feels like a dead-end at the moment. Maybe if there was already an existing following of tic80 peeps who were adventerous to make their own builds. BUT, this is not the case right now.

I'm sticking to shareable presentations that work on the web. Unfortunately, the wasm is pre-built so there is no great way to hack audio into this.

I honestly don't have any meaningful things to do with this new hack I did. It serves no other purpose than "oh, I did it". It's not enough.

Connect adds a pair of edges to the graph.

These are set to be local connections. ID values work just fine here.

I'm curious about knowing how I did cx? Was that another structure? Am I checking cycles there?

cx is another structure and loops/cycles are not= being checked for.

My original dagzet implementation reperesents the dagzet connections as strings that are only checked at the end of parsing when all the nodes have been added. Only then does it attempt to resolve the symbols. This makes for a more permissive parser.

My dagzet parser does the topological sort with the strings. I think it would be better to resolve those chunks into local ID values before the sort.

This is intentional. Verifications are defferred until everything is parsed. Verification is beyond the responsibility of connection.

There is a linear check for already existing connections, and a test is put into place to make sure this is all properly caught.

Adding TODOs for that.

I've implemented enough today.

Finished up reading last bits in chapter 1. Read chapter 2 (shorter) on Boolean Arithmetic and their ALU.

I have not done any of the projects yet. I am hoping this can be one of those things I can return back to when I have a chunk of time available.

I want to believe that "just reading" without doing projects is "not nothing, not everything". That is to say, I hope I'm getting something worthwhile from this.

This time around, I am hoping to learn how to make some kind of musical instrument sound toy for the gameboy. I want to do it in assembly, and I want it to run on my analogue pocket. If I build a ROM that allows me to push buttons and make it actively control the APU somehow, I'd call that a win.

I click on it, and then they disappear.

The bios I downloaded from retroarch was called gbbios.bin. Let's see if that works.

It works!

Works! -- Also tried some emulators. Does not work, yet.

Also skimming a few other documents while doing this.

I can compile the source, let me see if the audio code can change the buffer size.

I did find the code. If anything, increasing the buffer size caused more issues. Ugh. Linux, amiright?

Actually, I'm going to do the part 2 tutorial now. I feel like I need more context than what the docs are giving me, and it would be nice to have something I know works.

Got it displaying stuff with a Duck.

Thing is, 16:30 is coming up quickly, and sound is more important than making a game. If I can figure out to just get a pulse working, that'll be a success.

Let's see if I can get an always on tone with unbricked, then I'll feel like I've accomplished something original.

It does not.

The last part of this chapter had the reader implement things like AND, OR, NOT from NAND. I could get NOT without too much trouble. I figured out an implementation of AND, sort of (NOT-NAND did not immediately come to mind. I was too busy trying to find patterns in all the cases). I struggle with OR, even after looking at the answers. It's clear I need to build up more intuition.

I'll briefly try to defend the notion that it was mostly a good effort. For starters, I got very a convenient linear gesture interface, which required some moderate thinking about design in rust with ownership in mind. Secondly, I got Rust code working in mnolth for the first time, and this is important because it shows that I can leverage what I've done before to boost what I'm working on right now.

Using the trait system in place, the problem is a matter of how to build the "next" gesture. I'm thinking of implementing an event queue, possibly fixed sized.

I think the plan is to have this work in a single-threaded context first, then building abstractions around that inside of an existing event system. (in a webaudio worklet, this would wrap around the "onmessage" passing interface used).

Zulip will be a re-cap of last week with a link to the weekly page.

Eventually this will be populated with data from the commands.

Being able to add in-line descriptions of struct contents that get rendered to rust documentation would be helpful.

I have a incremental TDD approach to porting this, which feels nice.

I'm making use of Result and putting return codes into a single Enum. This is just mirroring how I'd do it in C. Hopefully it's idiomatic enough in Rust.

push/pop makes sense to me, but those are stack terms not queue terms.

Wikipedia tells me they use the terms "dequeue" and "enqueue".

Side note: my tired brain is having a great time parsing the "ueue"s of these words. Imagine if you pronounced it "wehweh". Hilarious.

I'm kludging it into a struct with optionals for now. This doesn't spark joy. I'm going to test this well, and when/if I refactor, I can rely on these tests.

For enqueue, I should only be passing specific data types, and then mutating the internal event array. Right now, deep copying an entire event.

For dequeue, I should either return a reference or an id that eventually resolve to a reference.

Turns out it doesn't have a lot to say. Voxbox, on the other hand, is a mess.

I also think some of the examples are broken?

019:00 home

added a lines command. now I'm very tired.

This is going to bother me if I don't write it down. I made a mention that having a buffer size of (sr/10) would effectively downsample the buffer by 10x, and this is not true. It's not true because that buffer is not filling in a second of audio, it's 1/60th of a second of audio.

Let it be known that many incorrect assumptions and guesses were made here. I leave them intact for historical reasons.

I've got a linear gesture interface that works pretty well in VoxBox, and I'd like to be able to use it with mnolth. I also want to be able to populate gesture from within lua. To do this, I'll need to build out an interface in rust, export a C interface, and write some mnolth glue code (mnodes).

mainly doing this so I can compose some of this audio telephone thing using mnolth. Frankly, the Uxn thing in GestVM is a bit cumbersome.... the setup time takes too long.

First, I'll build out the initial interface in Rust, which will wrap the existing linear gesture node with a self contained vector of paths. I'll then write some C-style functions that make it possible to do the following: initialize, append, tick, and destroy. I will make a quick example of this in Rust, which will be a good stopping point.

The next parts involve actually getting this inside of mnolth/mnodes, and creating the glue code there.

Using this as an opportunity to learn how to build a function with proper error handling and testing. I was going to do a more elaborte check validating each "okay" one, but it was less messy just to see it catch errors.

Instead of building on the existing LinearGesture Generator, build a new gesture interface that owns a vector that can grow.

Going to work on the C interface next.

I think I can do that right?

I did a bit of a hack, which was to duplicate "src/lib.rs", make it "src/clib.rs", and then add an example in the Cargo toml file.

Most of the day has been wasted away. Going to try to move quickly on this.

Gotta compose now.

Meant to do a weekly re-cap end of day, but I got caught up in an ad-hoc bytebeat coding session.

I still need to write up yesterday though...

Looks good. Gotta go back there and actually get something. Also got caught up in conversation with JM.

I am here to be interrupted.

I'm not entirely convinced that DSP works at a constant samplerate, because I think the timing is controlled from the drawing function.

My belief right now is that the audio callback works by taking any samples produced since the last time it was set, and then stretching it out to fit the required number of samples needed for the host audio callback.

I was trying to describe my issue with this codebase. What makes this impenetrable is that is that the use of macros makes it very opaque. I can't simply grep or use ctags to find definitions in the codebase.

Take, for instance, this line (breaks and indentation my own):

The output of blip_read_samples is reading a pretty constant 735 samples at a time, which is the number of samples read at 60fps. So it is actually working at the host audio rate. My timing theory is feeling a little shaky.

TIC80_FRAMERATE is hard coded to be 60, so it's filling the max amount. Based on the READMEs, I think it doesn't have to be? It seems like the blip_buf library is designed to discretize sound chips that don't necessarily have a clock. You just note the times when amplitude changes, and then it turns that into a buffer of audio samples.

For starters: there is no blip_start_frame. A call to blip_end_frame implicitly begins a new frame.

When it is called, a constant called END_TIME is used.

The END_TIME is defined as CLOCKRATE / TIC80_FRAMERATE. The framerate I already knows being hardcoded as 60. What is CLOCKRATE, and where is it defined?

CLOCKRATE is defined as (255<<13) in core.h, or 2088960. I do not understand the signifigance of this value. Going to try to look up that number, as well as the hex version of 0x1fe000.

I put it into chatGPT, this is what it said:

It's used in runPcm, there's some math done so that the loop works on a fixed PCM buffer size of TIC_PCM_SIZE, which is 128, but the incrementor is in these "clock units", not sample units.

Whenever this is called, a new delta is added to the blip buffer (delta-encoding). This seems to basically mean, "add a sample to the resampling buffer".

called in runPcm. It seems to be writing PCM data (128 samples) to the blip buffer.

called in runEnvelope and runNoise. There's a similar pattern to both of these, where a "period" is determined from some frequency value.

In the sfx callback, which is in tic_core_sound_tick_start.

when I comment the call runPcm, sound still works. This must some way to get PCM data in like sample playback stuff.

If my intuition is understanding this correctly, I think this program takes in a pile of delta time values, and turns that into a workable buffer? I have two optional things to try. One could be: write new deltas directly to the blip. Another could be, write to the existing PCM channel.

I got noise working! But, It's stereo noise, and I was expecting mono noise. I forgot that stereo synthesize is called twice, once for each channel.

Noise is working! It is being written to the ringbuf PCM data before calls to stereo_synthesize are made. I'm noticing gaps in the noise when I go between the editor and the console.

I get the sense that I might not be handling the data type correctly. It might be short (16-bit) ints, not 8-bit ones. A pitched square will for sure be able to figure it out.

The pitch is wrong. I'm assuming a 44.1 samplerate in the square calculation. But the blip-buf might be targetting another samplerate like 8kHz or something.

So the function blip_set_rates is definitely being set to be the host sample rate of 44.1kHz, however, the blip buffer gets initialized to be only a 10th of that size, making it effectively ~4khz max. Right? And that's assuming 1 channel. There are 4 channels that need to share that buffer, so that's like 1kHz?

Okay. I'm fighting blip-buf itself somehow? I don't want to waste any more time trying to figure that out.

It wasn't opaque, I just wasn't looking in the top level directory. It's in include/tic80.h. Wow. That's embarassing.

My square shouldn't be crackling. I refuse to believe that it's buffer xrun. Sure does sound like it though.

This is a clue.

I just messed up the logic for filling up interleaved audio.

I think I might have nerfed the experience with the pitch quanitization to be honest. It seems like the people I showed the quantized version to used it for less time compared to when it was "fretless". People really enjoyed the fluidic expressiveness of the pitch control and getting it to emote things using just inflection. Food for thought for another demo?

I think I might call it "trio", and the elevator pitch is that you control one voice in a trio, and there is an algorithm that controls the other two pitches to form 3 part harmony.

Follow-up task created: demo-trio.

My hope is that the lua implementatoin is trivial enough that I can bring it over to rust without too many complications. I will outline some of the broad strokes steps required to get this program up and running.

While writing these thoughts

The first thing I'll need to be able to do is read a file from disk, possibly entirely into memory. The dagzet parser works line by by line, so if there's some iterator abstraction that allows me be to do this, great.

For parsing commands, I need to be able to read the first three characters of each line to determine the command code. Commands are two characters followed by a space, with the rest of the line being being arguments.

Commands need to map to functions which can parse the argument data of that line, and potentially append or modifiy a rust data struct representing the graph being built up somehow. But, just setting up a convenient way to map commands to functions would be great. There will be quite a few, and I often find myself wanting to add more commands to meet my needs. I made use of Lua tables to create a look-up table of callbacks. Hopefully I can do a similar thing in Rust without too much fuss?

I need to be able to split data up by spaces. Lua does not have a built-in split() like you'd see in other languages. I'm hoping Rust standard library has one somewhere (this functionality should be standard not outsourced to a crate right? right?!)

I need a top-level data struct that can be populated with information that is parsed. I the lua implementation, I used tables: usually as a hashmap or array structure, sometimes an array of array. IIRC Rust STD has hashmaps, and vectors I think should be enough. I can't foresee too many ownership issues due to how imperative this is, but who knows.

I need to implement topological sort (Kahn's algorithm). My lua approach used node IDs instead of references, so I think this is going to be mostly Rust-friendly to port. Still, I get the feeling that I may be forgetting something that will be a pain point with Rust.

When it has been determined that the graph contains no cycles, generate the SQLite code to standard output. This seems pretty straight forward to me, more or less going through the generated struct (read-only) and printing equivalent SQLite code.

Going to try to use neovim for this now.

tangent: trying to get auto-import working. Found: <<neovim/nvim_cmp>>.

how to get this working with lazy, README only has vim-plug?

Wait, it's already installed, according to the Lazy control panel. What does InsertEnter mean?

Okay, I get the recommendations, but I don't know how to insert it.

Got it! Typing "File" then hitting ctrl-y does it.

I have it parsing command codes in the test file, and there is some placeholder stuff where I can eventually do stuff with those commands.

I got a nice big screen here. Looks nice.

For now: given a pitch (octave-wrapped, 0-11), find the corresponding triad. Use a lookup table (vector, probably).

I'm going to need to rework this to make it work with gesture and chords, but this is a good start.

Side note: the LED sign is 96x38

Considering how few of these I'm realistically going to get to, it's going to be easier to just manually print them to PDF to get them on my RM. Solid attempt though, had a good adventure.

Look at tic_core_sound_tick_start and tic_core_sound_tick_end.

Now onto demo

Going to try and timebox this to just today. What I want is to get pitch snapping on x-axis, reverb and delay effects, as well as y-axis intensity control.

It seems like there's a ring buffer of registers, and a register holds the data for one frame of audio. A frame consists of 4 channels of sound. Each channel is represented as a 32-bit signed integer.

When the end tick function is called, it gets the current register in the ring buffer, copies the register information in memory (RAM) to that ring buffer, then copies the "pcm" and "stereo" data bits as well. The ring buffer head is then incremented, but it's inside some conditional. I can't fully grok the conditional, but it seems to be some kind of bounds checking? I'm going to ignore it mostly for now.

Yup, it's getting called.

No. No we are not in Sokol.

I've zoomed up to the top-most callback level which looks familiar enough to me. Still, it's doing stuff in a less than straight-forward way than usual.

This is the code worth digging into a bit, which is responsible for copying TIC-80 PCM data into SDL's audio buffer. I have reformatted it a bit to make it more readable. Initially, it was all on one line.

*stream++ =
((u8*)tic->product.samples.buffer[
    tic->product.samples.count *
    TIC80_SAMPLESIZE -
    platform.audio.bufferRemaining--
];

The stream variable here is a chunk of u8 vars.

The TIC80_SAMPLESIZE ends up being 2. This could either mean it's a stereo frame of 8-bit values, or the sample type is 16-bit and the samples are interleaved if it's stereo. Unclear.

The bufferRemaining variable is decreasing by 1 every sample, and being subtracted from the total number of bytes that the buffer has. This feels like a bit of round-a-about way to avoid using a for loop structure.

When the audio buffer counter goes to zero, it fills up the tic80 buffer again using studio_sound. It continues doing this until the SDL buffer is filled.

Meanwhile, tic_core_synth_head updates the head. The relevant bits of code look almost identical.

There's some kind of async stuff happening I think. A tick start always follows up with a tick end, so that's being called on one thread. Meanwhile, the synth sound function can be called a few times in between these ticks. Sometimes once or twice, or not at all.

There's mention of a tic80_tick function, but when I try to printf from it, nothing shows up.

Okay found it! inside gpuTick() from SDL, the call chain is studio_tick, renderStudio, then calls to tic_core_tick_start and tic_core_tick_end, which makes calls to the sound tick starts and ends.

It's looking to be an interesting sound problem, because the timing of sound rendering is related to the drawing callback. There's things like jitter and frame-drops. How does it handle that sort of thing? Does the so-called "blip buffer" smooth things out somehow?

But we are back. Attempting to clean up main a little bit. Starting with the arg parsing.

It keeps screwing up my terminal window when I ctrl-C.

I don't have preset import/export, but that can be another task.

I want pitch quantiziation, and a y-axis controlling intensity

32767 both directions. which potentially poses a problem if you want the aspect ratio.

Just measured. 4x3 inches. so 4:3 ratio.

In theory, it's 15 bit resolution, which is great considering the size. But is it actually 15-bit? or just upsampled.

Also wondering: how to get max resolution automatically of touchpad?

Ah, yes it does <<misc/libevdev_get_abs_maximum>>

Note to self: I gotta organize this script better.

Ah, I don't think I have to care about that, I can process data directly.

Wait, runNoise is what I want.

I don't understand what update_amp is doing. It seems to be some kind of delta encoding.

I'm just putting printf statements in functions now to see what runs and happens.

It can be found in core.h. The value I think that is relevant for an arbitrary sine tone is "amp", which is the "current amp in the delta buffer". Does that mean the amp is delta encoded or PCM encoded?

There are 4 channels of sound.

How can I print any non-zero sound PCM values to terminal?

What's the deal with registers? How do they end up in a PCM buffer?

I have access to a Wacom tablet now, and I kind of love the size of it.

I think I know about enough to get started on hacking in a sine tone into the TIC-80 sound codebase.

A sine tone is ideal because it's a pitched pure tone, and it can be easy to tell if I'm getting the buffering and sample rate correct. If I can get a sine.

There is a bit of overlap here. I want the end of the "drawing tablet experiments" to have sound, and the "drawing tablet demo" to build up from that initial demo, tuning the sound better, and adding an abstraction that will make it easy to go between tablets.

In the true yak-shaving tradition, I want to build a quick webscraper that takes all the links in the LC75 page and then prints them to PDF. From there, I can view them on my remarkable, so I can be a way from my computer and study them with pen and paper.

I think it would be good for me to iterate on this. I'm getting great feedback.

Someone yesterday got very surprised by the sound and immediately closed the browser. Oops.

Wacom Intuos PT M 2, according to dmesg. Researching.

More specifically: CTH-690 [Intuos Art (M)] (using product/vendor ID lookup).

Super cheap to buy on ebay.

Is it multi-touch?

I'm counting 10 points multitouch.

X axis resolution: ~2143 (2150?), Y axis resolution: ~1333

No need for the OSC bits, but the sound and DSP are a good start.

udev permissions are in order.

Tried to an xp-pen tablet working that Seamus had. Could not use evdev to parse the tablet events for whatever reason, but I could read the raw bytes using cat and xxd.

It had the data embedded in there from a JSON blob. I was able to extract it in Vim. Currently jq-ing it.

Here is my big query:

jq .props.pageProps.dehydratedState.queries[0].state.data.studyPlanV2Detail.planSubGroups data_pretty.json

It's an array of items, split up by category (of which there are 22 categories). Each entry is an object with a questionNum field. When you add all the questionNums together, you get 75.

The key I want for the URL is titleSlug, and the id is questionFrontendId for the LC (I can use this to reference the problem tersely online). These are objects found in the "questions" objects, aka .[0].questions[0].

It's not going to matter.

Given a leetcode article, I can find a cached version on wayback machine, which I can then curl to an HTML file. Most of the HTML can be stripped using w3m -dump.

It does! There's a URL you can query and get a JSON response from. It does produce HTML, but, even with w3m it does seem to be kinda messy. Damn.

For example, my "balloon" control signal generator could probably work here.

Note to self: we're calling this voxsculpt.

Happens when I attempt "await startAudio" in onclick callback.

Also paired with Dan to help out with things.

Timebox it to about 30 minutes. Give it one last look, then send it to Jobs Chat.

The approach here isn't interactive enough, and I think I need to keep focusing on interaction. I'd rather have one mediocre vowel shape and interaction than several excellent vowel shapes and no interaction.

Things involving Gesture mechanics. Specifically, the concept of getting some kind of "auto-accompaniment" to work with Gesture signal generator systems. Something something event scheduler. Might be good to write some things down.

I shouldn't be terribly surprised by this, but the output is 8-bit.

Tested on my linear gesture demo using SoX. The darker sound actually works favorably for this synthesizer.

Converting to LPC10 (via sox), however, sucks. The pitch is wrong.

It could be that that's just a raw byte format. The sound code here is fairly involved. I'm going to need to look at this more.

It is unclear to me when things are computing a single sample of audio (tick), and when it's writing to a buffer.

For example, SOKOL seems to be writing shorts (16-bit).

What I do know is that samples eventually show up in something called "product->samples.buffer", but I cannot find that definition yet (there's a lot of macro magic in this repo). There is also a buffer count too. It appears that these could be interleaved samples.

As far as I can tell, product.samples is dynamically generated. It's not actually anywhere in a struct. The tic80 stuct I have yet to actually find. Same goes for product.samples.buffer and product.samples.count.

There are two top audio callbacks that tell tic80 to generate soud (how much sound not sure? but it's definitely multi-channel). I'm looking at the one sokol uses called studio_sound. This calls tic_core_synth_sound(), which I assume writes to product.samples.buffer somehow. If I can inject an effects processor right after the buffer is fully written, I think that can be enough for me.

These calls seem to happen right before they are resampled.

Can it work on linux okay? I can I use libevdev with it?

It even does touch to click this is incredible.

X max: 21600, Y max: 13500, Physical units: 8.5 x 6 inches,

Along the Y-axis, this evenly comes too 2250 pixels/inch. The X axis is about 2541.1764. Huh.

They still work in my test poller.

I think I already have URL code in the TeX code?

oops maybe not

This concludes the "managing state" chapter.

I've been on and off about this for a few days. I think it could be a good interface to try and tune vocal synth parameters. But, I should make a decision by end of day.

Thinking about using this with my number pad, somehow. I like the minimalism of the numpad, and consider it an interesting interface challenge for the task of musical sequencing. The tablet could be a good way to get continuous fine tuned gestural control.

Performance interface too?

How hackable is it? Is it feasible to shove my rust DSP code into the TIC80, audio callback, and control it from tic80 code?

I think this could be a fruitful way to build an ecosystem of toys that match my current aesthetic. I have semi-long term plans for this potentially.

I say "semi-potentially" because for its constraints, the software has quite a complex software stack. I don't expect this to be the most portable thing in the world. The most portable things are ideas, and after that, bytes of data (8 bits to a byte is fairly universal). There is a cartridge format, which may end up being a promising data format for portability, but we'll see.

Short term (as in this batch), portability or longevity is not a concern. I just want to hack stuff.

During my walk, I realized this was a perfect device for exploring vocal synthesis control. A sort of gold standard I could use to try out interface concepts before porting to the web.

I'm starting to see building instruments for the web as "redux", as far as solo interactive musical experiences go. It's incredibly convenient, but ultimately the medium of the browser is still lackluster, and usually there are tradeoffs.

Future thinking: collaboration and share-ability are the big strengths of the web. Something I haven't really explored yet. Maybe that's something to think about?

I want to move forward with an ensemble demo, but coming up with the interface has been a blocker for me. I don't want to blindly recreate Blob Opera or Choir. It's been hard to see past that. How do you meaningfully control multiple voices?

Then I realized, it was never about controlling multiple voices in Blob Opera or Choir. You were always controlling one voice at a time, and the rest would follow. A leader-follower, or soloist-orchestra relationship. Such a thing I will call a "concerto" format.

The initial proof-of-concept should ideally be flexible and modular. I'll want to prototype a few instruments with this thing. The inputs will be the 10 keys on my numberpad, and the XYZ inputs from the drawing pad. Realtime audio, etc.

The idea is to find the files, then add them to codestudy.

I think I found the music. One file sound.c, almost 600 lines. Not too bad, actually.

Adding to codestudy.

why didn't sound.c import?

oh it did, but the CSS broke. why did it break? Gotta look into this. again.

Confirmed broken on my website as well.

git blame says CSS has been unchanged since it was initially added.

demos CSS still works fine.

Huh. so the file works on a smaller portion of sound.c.

Looks like an overflow bug.

The issue is, I don't know how this CSS works. It was just lifted from SourceHut.

It seems to be a flexbox attribute. I changed flex-wrap to be nowrap and the problem went away.

I want to see an audio callback.

I think I'm pretty close to understanding how the callback stores audio into buffers. There's a resampling step which I need to figure out more, but I believe I know where I can inject custom DSP. At that point, I'll be ready to make a follow-up task.

This is looking pretty good though.

I've gotten good feedback from people, and was really interested in watching people interact with it. It's apparently has startled many cats! I may want to scope out some follow-up improvemnts to this, if there's time. Some things include: wall collision sounds, more dynamic interactions when poking, more variation in sound, and more empathy mechanics (feeding, laughter/tickling, etc).

It's been nice getting most of my resume structured as data. It's very "music tech" oriented, with a strong emphasis on DSP and "low-level" languages like C/C++. For some reason, I didn't expect for a narrative like that to so strongly emerge. I could probably find enjoyment in "systems" oriented things: studying databases, OSes, computer architecture, etc. Rust seems like a good way to stay relevant in these fields.

I think the leetcode is going to resume next week. If I can find time every day, I could do about 30 leetcode problems before this batch is over. But, leetcode takes more time than people think. An hour of focused time is quite valuable. If I can work my way up to 2 every day, that's most of LC-75 (80%). If I do 2 every other day, and at least one every day, that's about 45, or 60% of LC-75.

I want to get typescript under my belt. The handbook <<webdev/typescript_handbook>> is a little under 40 pages, so probably something I could feasibly read. Then again, maybe it's just good enough to throw up some sliders in React and just bump around typescript that way? How much of my time is it worth?

Maybe if I can get neovim up and running, I think I may have a better time doing webdev stuff and feeling "modern"? (He says while typing in a very vanilla vim editor in termux running on Alpine linux using vintage IBM colors.)

But damn, get this resume built up and send it off to Jobs Chat already jeez.

It works!

Key things I did to get things working:

Clone the kickstart repo to ~/.config/nvim. That is to say, the repo becomes the folder "nvim" as your base config. Opening up nvim does the rest.

the init.lua file in nvim is chock full of comments and README stuff. I searched and skimmed around for ways to turn on rust-analyzer with lsp-config, it was a line I had to uncomment.

Also had to uncomment a line to include new plugins, like the typescript neovim plugin I found. Installing stuff through this plugin manager thing called Lazy is basically a matter of appending table values to the return table value in lua/custom/plugins/init.lua. Opening up nvim handles installing stuff.

the LSP also does autoformatting. It will touch your files once they are opened, so note to self be sure to commit the files before doing anything when they are opened in neovim for the first time.

oscsend did not work. But: HACK THE PLANET

Did this by running npm run build then examining size of "build" directory.

By comparison, my vanilla JS project was only 12kb.

Visuals: eyes and mouth, make sure they all collide against walls. Sounds: use envelope to modulate pitch, used smoothed gate for amplitude (decay doesn't work).

Resist the urge to tune and tweak all day.

I'm honestly losing motivation for this, but it's important to me that I do this in order to learn.

This is a pretty open day, so there's a chance I'll have time for this.

"passing data deeply" (23 pages) and "scaling up" (20 pages)

open/close and shape morphing

Sometimes the pokes don't register because you are out of bounds.

That way, eyeballs can go off screen. I'm not going to do collision checks on mouth/eyes. Not worth the time.

I wasn't hearing what I wanted to hear. Turns out the jitter was getting in the way. 10:45 Android testing again #demo-poke #timelog:00:03:38 Feels okay enough. Maybe a bit too shrill on phone speakers. But I'll worry about mixing another time.

Short answer is: no.

Okay, so I just want to preview the data right now. I'm going to render to markup. 11:49 I wrote a CV in plain tex once, trying to compile #resume-setup It still works!

Gotta love this. There's a header file called execinfo.h that doesn't exist on musl (alpine) and there's a specific macro that disables including this file. There's probably a way to set this macro using a flag somewhere in a deeply nested Makefile, but it's just going to be easier to comment these bits out. It's only this file. FAUST is like this sometimes.

It is building...

I get weird permission issues when it builds? https://stackoverflow.com/questions/72978485/git-submodule-update-failed-with-fatal-detected-dubious-ownership-in-reposit. So sketchy.

I have this feeling that one of the optional submodules is causing issues.

Oh, it was more sketchy stuff that I had to comment out. The "install" target of the Makefile had this weird line that was triggering the git issue.

Starting this at home on my Mac.

The offline example should have some parts that will eventually be designed to be modulated by user input (poking). Poking can be simulating using a triggered gate. The gate would go into an envelope (envelopes?) of some sort as way to shape things like fundamental pitch and jitter.

Basically, my source of inspiration for this one are those poptart commercials that were around during the early 2000s <<demos/poptarts>>

It'd be nice to get collision working for the eyes, because I think they will bulge out of the face occasionally.

Mouth shape needs to be flexible enough to support mouth shapes. I want these to be synchronized with the mouth shapes being synthesized by the audio.

I keep procrastinating and yak-shaving on this.

This will drive the tgate. This can be made from a phasor. Any time the phasor resets, produce a trigger.

Created a phasor to trigger utility called PhasorTrig

Actually, I'm building out a metro that combines phasor and phasortrig.

I will opt to port the envelope I made in sndkit.

Now it works. Forgot to add the exp and update pgate.

Chatter sound needs to be consolidated into a struct rather than in a main function. There also needs to be a poke method, which will eventually be the thing called when the user pokes the circle on the screen.

So I think this task can be considered completed. The rest of the sound design work will be polish for the poke demo.

Up to this point, "poking" has been simulating using a metro object. This metro needs to be pulled out of the struct, and replaced with a gate fed into a threshold generator. The metro function will exist outside, and when it ticks an impulse, it will call the poke method. The poke method will flip a gate signal on and off. Inside ChatterBox, it will detect changes in the gate and turn those into triggers like before.

It works! It's a coarse experience, but it sorta works.

termux is awesome, because I can run it locally on my phone.

It works. definitely needs some refinement. But a good enough stopping point.

Okay that works! Nice.

The first will be a randi like module clocked with an external phasor. The second will be a phasor whose rate can be randomized every period. Together, they can build a pretty decent jitter signal.

I'll probably be extracting my LCG logic into an RNG module as well.

I know, I know, I'm overengineering this.

Dan mentioned using VSCode again, and I'm inclined to take his advice. However, before I try that, I want to see if I can get some decent LSP things working with NeoVim. Would be especially helpful if I can get it running on this Alpine thinkpad.

Found Kickstart while trying to google "typescript in neovim". This was the other thing mentioned too: https://github.com/pmizio/typescript-tools.nvim.

As reference, there is my resume dagzet code which has some prototype syntax.

My lua implementation was always designed to just be a prototype, and nowadays it's getting quite heavy. Now that I'm a bit more familiar with the language, I don't think it'd be too difficult to build it in Rust, tbh. I think the standard library has enough rich data types that it should be pretty straightforward.

I think I know what I want in the schema, but it comes down to naming. Working out the words here.

A list belongs to a node, and has items in the list, which are other nodes in the current namespace. Each item has a position in the list, which is known. I will want these positions to be zero-indexed.

This approach I'm using for representing lists is more SQL-y compared to say, how I'm handling dz_lines. I'm using more rows: each list item gets a row with a position. In theory, I should be able to reconstruct the list using some join and amalgamation operation in vanilla SQL.

By comparison, the other parts of this code represent lists as JSON arrays encoded as strings. SQLite does come with JSON bindings now by default, so it seems this is reasonably portable. But it does require that extra JSON parser, and a part of me wonders if that was the right decision.

So, consider this an experiement. I'll have both: more SQL-driven and more JSON-driven, and I'll see which one feels better over time.

Nice! There was a double join on the same table I had to do and I pretty much just guessed it.

The query I made:

SELECT dz_nodes.name, group_concat(itemlist.name) FROM dz_lists
INNER JOIN dz_nodes on dz_nodes.id == dz_lists.node,
dz_nodes as itemlist on itemlist.id == dz_lists.item
GROUP BY dz_nodes.name
ORDER BY dz_lists.position;

An ideal jitter line would be a random line segment clocked a phasor that some kind of variable fluctuation in timing. But how does that phasor's rate get controlled?

The best answer I can come up with is to have a specialized phasor whose rate can be smoothly randomized within a range. This, combined with the random line generator made previously, would build up the components for a jitter line generator.

As a test, this random phasor could be used on the chatter test to modulate how quickly the shapes are changing.

Yes, I think I'm going to call it RandomPhasor. I'm going to copy and paste the phasor code for now, since there's not a lot of code. It just doesn't seem worth it to DRY it right now.

This completes the idea I was thinking about

Unexpected Knowledge Acquisition: Learning about some of the old oil pipe constructions in the US, and their ecological/environmental implications. Apparently some of these pipes were transferred in carts in a way that the pipes would rub up against eachother. The friction would produce weak spots, which would turn the pipes into "swiss cheese". I just love that imagery.

Someone in summer 2 wants to work on boot sector games, and I am in full support of this.

As a sidetrack, try to see how hard text templates

I tried exploring go templates briefly. I don't think this is really going to help me. The data format is what is most important. I think I'm just going whip something up in janet, shell, or lua.

Triaging, figuring out what to do next.

Oh. Looks like I had a placeholder page here already.

Ah, what makes this interesting is that these demos aren't wiki pages, can't use ref, and you can't have them be typical links either.

add a new janet function for creating these links called "pagelink" which doesn't do any checks.

Part of my hesitation with my initial "port it to react" is: how bulky will this end up being on my website? Do I even want it there? Does it even matter if it just is code that's here in my Recurse monorepo and nowhere else?

See: demos/taskgroups/demos.

One of my concerns with building a react app is that if I host these on my droplet, it's going to clog things up in and take space. What I want to know is: when I go through the process of minifying and exporting the code, how much space does it end up being? What goes into uploading and running this on my webserver?

My other concern (which I'm trying not to think about too hard about) is: my website is 99% static, and introducing JS could mean adding an attack surface to my website. Probably just being paranoid.

built jitter signals / summer 2 conversations / then I napped a bit

Next steps are to port the rest of the UI into React

I think I know enough now to start getting the rest of this UI ported to React. I can just focus on the UI elements first, and then worry about hooking it up later.

The most important thing for this demo is the vocal-like chattering. So this example will more or less aim to build the model. The new thing to try out will be morphing between DRM shapes. The critter here will be quite small, so the tract size wlil be quite small.

I will be thinking more about the design today.

The chatter sound model will feature DRM shape morphing using a pre-defined set of tract shapes. This will be a simplified version of what I'm expecting to do with the Gesture shape morphing. The chatter system will interpolate using a phasor, but there won't be the rephasor component. The code structure will also attempt to be simplified as well.

I want to see how much I can do of the LC75 problem sets.

Going to use my phone for this, as the touchscreen is the best interface I have right now.

I need to find a better way

I think I want to implemented an ordered list command.

Thinking about something like randi, but phasor-driven. And a phasor that can have randomized periods.

amidi --dump -phw:1,0,0

Goal will be to figure out initial technical scaffolding, getting p5 in a windowed context, mouse pointer stuff, etc.

This will build on the vocal chords demo, and will most likely be something vaguely like Blob Opera and Choir. Slightly lower priority than demo-poke because that task will let me focus on details for one face and voice, which can be a helpful learning experience when I go to do the choir app.

This shouldn't take any time at all.

After studying the boilerplate in way too much detail yesterday <<codestudy/hello_ts_react/app_tsx>>, I feel ready for this.

You can't actually use dzref to link to graphs, only nodes. Hoping to fix that cuz it comes up a lot.

It's a good contrast from the vocal chords demo, and a good way to start the more whimsical toyetic vocal demos.

This has been a repeating theme: my audio code doesn't work everywhere, but Glicol does tend to work everywhere. Why?

Found an interesting line:

window.AudioContext = window.AudioContext || window.webkitAudiotContext

More importantly: sounds suddenly worked for my vocal demo?

Both my vocal chords and glicol demo work.

I did do some cache clearing in the dev tools, so that could be partially to blame for why it's suddenly deciding to work.

Unrelated, but that webkit line may be how to get sound working on some iphone devices.

I've made a new task for this vocal-chords-older-iphone.

Scew it, outlining in markdown. Text will set us free.

it is stored in this repo under resume/resume.md.

I should pandoc this at some point. -- okay it didn't work out of the box and this frustrates me.

Crazy overengineered idea. Write the resume in dagzet, compile to SQLite, then produce tex structure from this.

This could also be a good pre-cursor to the shape morphing stuff, as all the code could be a bit more relaxed and inside some sample rust code.

Not a good sign for future developments on the thinkpad.

Chromium plays isorhythms okay! Just one of those things.

I was there for 15 minutes, and nobody showed up.

Now that things work if we "run in chromium" (sigh), things can move forward.

Found the documentation: https://archive.p5js.org/reference/#/p5/p5.

Going to put it in a 400x400 window, or something.

scratch that, let's see what 400x680 does. approximately pacman proportions.

It doesn't work, but it's a good start.

Approximating the timelog to be about 15 minutes. Solution was much less complicated that my thinking. Instead of wrapping slider in react, just use stateful hooks.

And we are done!

Poking Propulsion

Worked Better In Chromium

Markdown Resume

New Resume Time

Stored state in sliders

I initially was going to time my morning triage stuff. But I don't think I want to do that.

Also, comments on the triage itself aren't all too helpful. I'd much rather comment on tasks themselves

Sounds do work on youtube, so I am getting browser sound. No clues in console. Locally hosted versions do not work either.

Ah, still running into issues with uploading. I didn't finish setting things up.

Ooops I just blew up my recurse site. ROLL BAAACK.

Seeing what I can accomplish in 15 minutes, then I have to quickly leave for errands.

Looks like the escape string is wrong. I am using "'" instead of """. I did this to myself when I was trying to update the SQLite generator scripts (they got stricter about single vs double qoute usage apparently. Technically, you're supposed to use single quotes only, but they used to allow both interchangeably).

I think this is fine actually? Looking at them, it seems like I meant to delete them. I was worried that I accidentally deleted the tasks or something.

I've just decided to start doing my daily check-ins as Haikus, so I was destined to find this today. It was printed on a wall of a builing. A haiku by Richard Wright. The creeping shadow / Of a gigantic oak tree / Jumps Over the Wall

This thinkpad isn't fully provisioned yet. Upstream mplayer doesn't have jack support, so I need to build it from source.

I remember this taking a while. Uh, maybe I should look at other things.

Nevermind? It just finsihed as I wrote this. That's not a great sign.

Ran into build issues. Great. Downloading from git, using the APKBUILD as hints.

MPlayer is kinda SVN? But this build script is using git?

Not what I wanted to do, but here we are.

Bandwidth is slow even at the hub. git feels slow too. I wonder how much faster it'd be on a newer laptop.

Build time wasn't too bad, so I'm rebuilding.

Package installed in packages/community/x86_64.

Can be done with apk add foo.apk. I don't think I needed the --allow-untrusted flag because it was self-signed.

I love how straightforward that was.

I created the project with this command: <<webdev/npx_create_react_app_typescript>>.

I think...

Initially I was going to add a small method to the tract that linearly interpolates two DRM tract shapes, given a position. BUT, the DRM shapes aren't in there. So, I actually have to plan out a new interface.

Basically, I want to generalize the values that can be interpolated. It is currently set to be 32-bit floats, BUT, it'd be nice to make them generics. That way, the shape morphing can work on those generics.

The core Gesture and GestureVertex structs take in generic arguments, with the rest hardcoded to take in f32. This was much less friction than I expected.

Next steps: have the linear gesture signal generator take in generics as well. After that, the generics can be refit to take in shapes. Somehow. (Indices? references?)

Does it look like the other react code I've been examining?

Actually not too much of an issue, I have enough printing happening now that I can update when/if needed.

The magsign_cpp is what we are investigating. What would need to happen for it to not show up in cpp?

Not sure if that is helpful or not.

Of the three, It's also the only one that only shows up once as a left-node (it only has one parent node). That parent is magsign_cpp.

As we go down this tree, we are approaching the only two external nodes here: rust/std and rust/std_iter_zip. The TOC generates the links just fine, but it just seems like anything that has those links doesn't want to show up.

What's up with that?

Removing those external nodes causes it to render properly.

I don't think the edges are supposed to be nil, even though they are here.

I have another hunch: there is a local node called "rust", and the namespace for these external nodes also starts with "rust". Going to re-introduce the external nodes, and change the local "rust" node to be "rustrust". It could be that there is some faulty logic related to string matching somewhere.

Neither worked. Okay, so I have to check out those nil edges now.

While populating a local copy of the edges table (to be pruned later by the topsort algo), I added a check to see if the left node id shows up in the nodes list. If it doesn't, it indicates that it is an externally linked node outside of the namespace.

TL;DR: Check for foreign nodes.

Okay that didn't work.

This gesture is currently hard-coded to work with floats as values. Which, most of the time, is fine. However, for shape morphing, the values that need to be interpolated aren't floating point values, but tables.

The hope with generics was to be able to elegantly use the existing linear gesture logic to create gestures that morphed between DRM shapes.

Things would be set up in such a way that when tick() would be called, it would know to interplate between two DRM tables and store it somewhere in another table. That table could then be taken and passed to the vocal tract.

Stopping for now because I've had enough of a day.

It was a helpful excercise, but I need to move forward.

Probably a target run today.

installed npx:

sudo npm i -g npx

Got to figure out why this npx command didn't work:

npx create-react-app my-app --template typescript

Solution: https://stackoverflow.com/questions/7718313/how-to-change-to-an-older-version-of-node-js

Instll n, run n stable. Basically, the version of node was "bleeding edge".

And we're running!

Using magsign_cpp as an example, which currently has the id of 146.

It doesn't seem to be showing up.

Connections look right.

This comes next after populating connections. I have a feeling that calling table.remove and table.insert aren't doing the things I expected.

Checking these nodes.

I mean, I guess it looks right?

"cpp" would have to be added to the "no incoming" table. Which, I would expect wouldn't be happening.

The nodes_connected_to function: which way is the direction? if "nodes connected to A" returns B, is it "B->A" or "A->B"?

It's checking if the node is on the left, so "A->B", so the parent nodes.

If this is true, header_file_looks_like_boilerplate (id 137) should return the cpp node (id 134). Let's test this.

It's not showing up. Nevermind that was my fault.

Okay the cpp node is indeed showing up as expected.

This is insightful: the cpp node shows up 2/3 times. The missing node here is magsign_cpp. So, cpp might be forever missing if magsign_cpp is missing. That's enough for today.

Hopefully I just wrote them in wrong.

So, I've added a task for this. add-day-titles.

Precursor to getting tic-80 working. Oh wow that was easy. Little did I know I was 30 seconds away from getting this working last night.

Now that sokol example works, I think I figured out all the graphics issues

I like the scale and form factor of this.

The bundle includes the tic80 card and a wasm file. I have no idea where the wasm comes from. It's not a file included in the source, and there doesn't seem to be any clear indication where/how it is being generated. My best guess is that somewhere it gets made with emscripten because I see mentions of it when I grep for wasm-y things.

I missed my chance months ago (waited months for this). Can't afford it. Oh well. Still buying.

These are the missing files

How is this being created?

Not the problem I wanted to troubleshoot, but hey I need this for the visibility.

The debug mode flag is never set to true here. Confirmed with printing and filtering output.

Also confirmed that it doesn't matter if you're using the function dbg I made or checking the variable itself. It's the same. So, I'm pretty sure the dbg shortcut function is fine.

I need to be able to track down when this is being set, and then unset.

I think what's happening is the variable is being copied over when it is loaded up in the module. Hoping to fix this by using a big global that can be read everywhere.

This is NOT what I'm debugging. I just need visibility.

I have a clumsier approach now, but it works, and I've wasted too much time chasing this pre-bug to improve it.

Confirmed that the nodes do come up, but they aren't being traversed for whatever reason.

should be 33, but I'm getting 20.

I tried looking for something to make sense in the code, but I can't yet see a pattern for what is there and what isn't there.

Clocking out for now

printf-ing to console works, even if gdb crashes

Sounds like it might be trying to download something from the internet? Yeah, that could be a problem here.

Firslty, the printf I placed there isn't showing up. Secondly, it makes a call to empscripten_fetch, which I do not (think I) have.

Maybe it is defined elsewhere?

Ah, there are multiple definitions here. Wonder which one is the actual one.

The tic cart loaders are pre-compiled wasm files. The path is /export/1.2-dev/html.

Basically, HTML export works by fetching from a URL. This downloads a zipfile that already has the wasm in there. Exporting is simply a matter of dropping that TIC file in the in the zip file.

So, it's looking like doing any kind of hacking on this would be a fairly ambitious task that would take up most of my time. It looks like this wasm file is the only thing I have. What I'd like to do is to somehow patch it, potentially. And get it to load in custom code for audio playback.

It's not a no, though it would dramatically change what it is I came here to do. Instead of doing funny vocal synth stuff, I'd be going deep into trying to reverse engineer this thing. Feels very much in the spirit of RC. And this is more motivating to me than more frontend-y stuff. There may be less polished things to show, though.

Needed for reverse engineering tic80 wasm bundle.

I love how easy it was to build, and the tools look very neat.

Using this to make any sense of tic80 feels like something that would take me maybe months to a year to do maybe. Hacking the tic80 source code itself would take less time. I'd probably have better luck building my own cartridge loader.

I think if I wanted to go deep on wasm rather than frontend stacks, I'd definitely want to look into this. This stuff sparks joy more than javascript/React.

I am pretty sure it's lua5.3, based on grepping for version for the built in luajit.

Functions defined in cart.c. Looking at music.tic, the code for the seems to be at the very bottom.

Ink on paper.

I want to focus on designing more musical experiences using my vocal synthesizer, that run in the browser.

This, however, is not enough of a project, and risks being too design oriented rather than technically oriented. I am also quite seriously considering putting some work into hacking my vocal synthesis DSP written in Rust into tic80.

Why tic80? I like the aesthetic. And hacking the software's source code seems to very much be in the spirit of RC. It is also possible to export to WASM, but not with the hacks. As a stretch, it may be possible to somehow hack the wasm TIC cartridge wasm blob, or even write a custom TIC loader based on the TIC-80 codebase.

Design and presentation is still and important factor. There will be two kinds musical interactions: ensemble and solo. The main ensemble sining project will probably be something similar to blob opera. The main solo singing project will be "A Blob Named Bucket", a chittering singinig virtual pet that you have to coax out of hiding with food.

A Blob Named Bucket will be the more complicated project, requiring a procedurally generated critter generator, and a character engine simulator Bucket's behavior. For this reason, these components will be broken up into smaller self-contained demos. These need to be self contained because it's likely I may not be able to get to the final project.

The ensemble demo will probably just be for the web using p5, and will building off of the chords demo I made in the first half.

TIC-80 demos will do their best to follow some of the ideas in the p5 demos. Could be thought of as "redux" versions? I want to do my best to refine the mechanics of these demos, reduce until they are distilled into simple elegant forms of sonic interaction.

Tooling will need to be made as well. These will probably be HTML/WASM, and for practice, I will use React for these.

I did not think about this too hard for this. That's what next week can be for?

Source <<gamedev/tic80/github>>.

Starting on my Mac. Looks like pretty typical CMake stuff.

Seems to work! now off to try Linux.

Going to try the vanilla CMake TIC80 instructions first. I don't expect it'll work and I'll need to install packages.

Holy crap, the CMake script ran without any issues. That's surprising.

Running into Makefile errors. Turning off -j flags.

"RAKE-NOTFOUND: not found": is this a ruby thing? It sounds like a ruby thing. Installed ruby-rake and mruby and then re-ran cmake. The build is moving forward.

TIC-80 seems to include most dependencies in the source directory. This probably makes the thing a bit more portable. Reminds me of how I think.

Wow! It built. It looks like there may be support for JACK via pipewire. I've never actually looked into pipewire, but if there's a way to use it with my existing JACK applications, that would be great.

Oh crap. Alpine just permanently removed jackd when I installed pipewire-jack.

Pipewire-jack research is going to be half a day of research. Going to hold off for now. Fortunately, I managed to re-install old jack.

If there is pipewire support for JACK that works with TIC-80, I'd probably want to use that to get sound working on my Linux box. Further reading <<audio/pipewire_docs>>.

It's going to need to get done, but I can't have it in the priority bin like this.

I've just had the idea to look into tic-80 and hack the audio engine. This seems to be most in the spirit of RC, and probably going to be more fun than trying to get a bunch of graphics libraries working.

Sokol would be what I'd want to try as well for something similar to tic-80 graphics-wise, but that's more upfront work.

There's always p5.js and friends for very quick rapid prototyping. I really need to convince myself to try using these for time constraints.

Basically, "A Blob Named Bucket" will most likely be a culmination of other mechanics I try out.

As I type this. I can't help but wonder if this will be too time consuming to try and implement.

You know what. I'm going to story-board the gameplay for bucket. That's what is missing.

A good follow-up to my initial scoping. I'm kind of paralyzed with tech stack choices, and I'm very limited with time, so boiling down game design is a good choice. I know how with a certain degree of accuracy how long pen and paper takes.

Probably won't get to it until next week. This has been added to my priority group.

See: <<retrocomputing/next>>

Other than the sound engine working, getting the drawing pipeline working feels like it'll be the most time consuming thing. I don't know if I want to spend my time doing that.

See <<webdev/wasm/mini_wasm_renderer>>.

It works!

Using the alpine wiki

I need to figure out how to troubleshoot this

It's in /var/log/messages I think, tailing now.

I can get more verbose output with service networkmanager start -v

I get an "not authorized to control networking message", which is a known thing in the Alpine wiki. There is a config file I make:

[main]
auth-polkit=false

I will feel pretty much accomplished by then.

For example nodes like "cpp" and "magsign_cpp" are missing.

It's not being added to the data.

jq .nodes[] | .name data/codestudy/potential/index.json | grep magsign_cpp

Late start. Ironically, I was trying to wake up earlier, but it backfired.

There is always the temptation to bite off more than one can chew, and once again I feel like this is starting to happen. I'll probably want to leave this up for the rest of the week and see if any more thoughts emerge.

I want to build demos exploring a some of the core "verbs" I wrote down, like "poke", "eat", "move (to target). Probably in p5. Sound design would be a great thing to garnish it with after. Sound design will be another task too.

Basically, there are default header/footer functions for HTML pages. I need to rework this so that the dagzet files use their own custom header/footer functions.

Does weewiki store the current page name somewhere? Yes, it's ww-name.

I'm going with global mutable state, because that's ultimately going to be easier.

Oh boy, this is tricky. By the time the Org gets parsed, the headers/footers are already set up. This means I can't actually disable the templates from the Org file itself. It needs to come from a lower level.

I can add the files to a list, but that's error prone.

Okay, files are going to have the "dzfiles" or perhaps "dzf" extension for terseness. So for example, a file called codestudy/potential/mag_sign.rs would have a prefix of dzf/codestudy/potential/mag_sign.rs. My weewiki server would then be able to filter those pages and disable templates entirely. So far this is the best hack I got.

testing out hacky idea

Initial idea working. I'll need to inject the rest of the HTML next.

Halal cart nearby. Pretty good.

I showed my "milowda" work and my vocal chords demo. I feel a little self-conscious about showing the vocal chords demo, as it was a little too polished. This work is also very personal too me, so I felt quite anxious after presenting. Did not expect that. I'm usually pretty okay with presentations.

As I think I've mentioned already, this is turning out to be more of a DSP problem, less of a programmer problem. It'd be cool to have at some point, but not during my time at RC.

I think I need more musical demos now.

Sokol and/or SDL is probably going to be my solution moving forward. The general approach is to use textures and rectangles for sprites. There is documentation on this that I can read.

I think this is a very important aspect.

This could be done in a p5 app. I just want a circle that giggles and jitters when you poke at it. It'd be a good pre-cursor to other experiences I want to make like "A Blob Named Bucket".

link: https://github.com/seyhajin/webgl2-wasm-sdl-sokol-sprite.

WASM builds and runs okay with emcc. I was hoping it would have had a sprite moving, but it's just projecting a static texture.

I'm starting to feel diminishing returns, as this "simple idea" might turn out to be not as simple as I thought, and might require more time/focus than I have right now.

Fail early. Fail often.

the "spine" examples seemed to be closest to what I was looking for, but it turns out it's also not what I'm looking for and intended for much larger games that I'd like to build: http://en.esotericsoftware.com/spine-in-depth.

link: https://github.com/edubart/sokol_gp

The OSX build in this makefile is out of date. Getting errors. I'd like to see this work, so I'm going to try and get this running on my Linux box. If that fails, I'm back to just learning more about sokol_gfx.h and actually reading the documentation.

Okay! The makefile works on my Linux box! Good. Progress.

Making a dagzet graph for sokol.

I want to get the text rendered to a PDF somehow, so I can read it on my remarkable.

Learned about :hardcopy in vim. :hardcopy > foo.ps.

set popts+=number:y will include line numbers

There are two kinds of programmers: those who understand why text editors have a "hardcopy" printing feature in 2024, and those who do not.

Uploaded PDF to Remarkable.

Found this while looking up how to do pixel art on OpenGL: https://github.com/SergiusIW/gate

running into linker problems.

Solved by adding println!("cargo:rustc-linker-arg-L/opt/homebrew/lib")=.

Now it is panicking because it can't find OpenGL/GLES library. Probably something to do with it being a Mac?

Working out test file. https://stackoverflow.com/questions/26745284/cmake-not-finding-gl-h-on-os-x. This worked fine, though I had to change the include file from GL/gl.h to OpenGL/gl.h.

Digging into gate library a little more, since it is just SDL underneath it.

There's only so much stack tracing and debugging I can do before I call it quits here. This is another nope.

I think the sokol headers are out of date. OSX references things like cocoa, new sokol headers references metal.

Nope. Fortunately, there's documentation on the build incantation used to build cube-sapp.c in the sokol-samples repo:

cc sapp/cube-sapp.c -I ../fips-build/sokol-samples/sapp-metal-osx-make-release/sapp/ libs/sokol/sokol.m -o cube-sapp -DSOKOL_METAL -fobjc-arc -I ../sokol -I libs/ -framework Metal -framework Cocoa -framework MetalKit -framework Quartz -framework AudioToolbox

I want to update the Makefile in sokol gp to match this better

Made a build.sh script. Still getting a lot of weird metal-related junk errors.

Took the clear-sapp example in the sokol-samples and gradually added lines from the rectangle sample in the sokol gp repo. We have a rotating rectangle now!

Files are stored in dz_textfiles.

Files given some sort of path, which can be analogous to a dagzet namespace URL. I'd probably opt to replace things like periods with underscores though.

Take something like codestudy/potential/mag_sign.cpp, that could a page called codestudy/potential/mag_sign_cpp. Some assumptions could be made that codestudy/potential would already exist and that mag_sign_cpp wouldn't be a pre-existing node.

A janet function could be written to generate the appropriate HTML given a file path. This could then be called using inline Janet, which could then be created procedurally using a script.

Gosh there's so friction getting this to work cuz everything is so connected. I wanted to just write Janet code, but I needed other things, so I put it inside a placeholder org file and ran parse, but the CSS parse path is wrong.

I need to point to a brand new CSS file. Overwriting the usual one isn't going to work. Stopping for now because this will require fresh thinking.

let's find out!

Link: https://github.com/parasyte/pixels.

Space invaders example works on my Mac. Good lord that's a lot of dependencies though (it's okay, it's okay, just grit your teeth and do it).

Web example runs on my mac. Noticing use of wasm-bindgen. Is it time for me to bite the bullet and actually learn this? I wouldn't be able to get it done in a weekend.

Link: https://github.com/floooh/sokol.

More "comfortable" because it's closer to a tech stack I know already. I've never used it before, so the learning curve may be just as big. But let's see!

Sigh... Emscripten.

Uhhhh... my harddrive just filled up I think.

This is an omen. I am ditching Sokol for this.

Damn. Fast internet fills up disk space quickly.

This is the ultimate test because nothing every wants to work.

Link: https://github.com/rust-windowing/softbuffer.

Good ol' glfw backend works. I do not really like the strange build system.

I'm starting to think a solution might involving having different backends, with as much logic in the Rust layer. This might take too long as well. Sigh. Graphics.

This will be a good way to test out tract length while on my Linux box. -- Actually, this won't work. Interpolation doesn't smooth discontinuities, but allows smoothing transitions with floating point values. I will need to build an example.

I was hoping this would be a quick matter of linear interpolation between the last two samples at the output, but I I'm still getting issues. It's starting to turn into more of a DSP problem than I'd like it be, which is not why I'm here at this program. So, I'm putting it to rest for now.

The attempts are managed in the "tractlen" branch on my voxbox repo

Somehow I think the fractional tract length needs to be considered while computing the scatering junctions. But I'm not sure how yet. I added in best guess but it's not right. Okay I really really need to stop this.

What does the schema look like? What kind of information does it have? How do file names get translated into things "seen" by dagzet? How to make sure file range links go to the right place? All this and more... later...

This would be the quick and dirty approach, no interpolation.

Including this tract size behavior. I am ignoring that fact right now.

Oh okay. Just needed to clean some caching and rebuild.

The velum now sounds more nasally everywhere pretty evenly.

Found some sheet music. I want to hear how the sonorities sound.

09:24 Off to get batteries for my scanner wand

It's very helpful for tongue control.

this proved to be more challenging than I expected because I was flipping between instantaneous and filtered and I wanted to make sure that doing things like setting the smooth amount wouldn't cause any jumps, which lead to some subtle logic. I think I got it mostly right. Well, good enough.

In an uncharacteristic move, I went back to to the hub at night to work out some of the harmonies in this youtube video I found <<misc/artemisia_agnus_dei>>.

I accidentally wandered onto a movie set in the historical district of Brooklyn and stayed and watched. They gave me a water bottle, so now I'm part of the Movie Industry now.

In rust, this might be slightly difficult with how I am currently arranging things because I have my OSC listener component separated from the DSP component. Ideally, I'd like to have the DSP be a reference inside the OSC component, but that may be tricky.

Because the main loop in C, I'm leaking memory when I allocate the DSP object.

It involves calling unsafe{Box::from_raw()} and then drop.

Initial extraction and studies in scratch/lines_css/.

The rust library <<rust/crates/cpal>> didn't work on my alpine linux box, but <<rust/crates/rosc>>. was fine. So, the plan is to build something up using libsoundio, then have the inner loop be implemented in C.

Now we have some C code making sound, and some exported rust code setting the frequency of a sine tone.

This code is from the libsoundio sine example. I need to make sure this is organized well enough that I can start putting custom DSP code from Rust, and eventually add OSC polling.

Okay, nevermind on the splitting. I have a better sense of this control flow. I want to make sure I can get my Rust data into C okay.

While I didn't do any refactoring, I did manage to figure out how to send userdata to the SoundIO struct.

When I initially wrote this, I didn't really know what it is I was talking about.

The goal here is to be able to use a NameBrand JS Framework to get better at understanding how this tool works. I think when I initially wrote this, I was imagining React to be more of a widget library, when really it's more about managing state of the widgets, and the widgets are somewhere else.

Perhaps what I really want are some nice looking sliders with CSS, and then using React to manage the state of these?

I don't have any other apple device, so this is a painful experience. Do I even bother?

Surprisingly, it seems to work on Alpine for now. It's nice to know that I can use that as an option in a pinch.

/voc/pitch, /voc/velum, /voc/tongue/x, /voc/tongue/y, /voc/volume

It doesn't have to be all the files, just enough to understand how the plugin architecture is organized. Figuring that out now.

I stripped my editor of all features a while ago, now they are slowly creeping back in.

Eventually, I'd like to generate interactive pages of code, but that can wait.

The issue with the chords at the moment is that the voice parts don't sound right, which I think is due to the shapes being wrong. If I am able to tune the size along with the shape, I think I'll end up with better sounding results.

Right now the syntax is #timelog mm:ss, but if we include the time in the tag like #timelog:mm:ss, SQLite would be able to parse it.

I forgot to close out an inline Janet expression.

We have sound! More fiddling with voxbox gesture path required.

Units will be in CM, and there won't be any interpolation.

I can't believe it worked haha.

Things are starting to sound pretty.

see: test-dz-log-task-linking. Calling this one done now.

I think the secret to getting a better ensemble sound is going to be tuning vowel shapes for each particular voice type (soprano, alto, tenor, bass). Each of these need slightly different tract sizes. It would be very helpful if there were a way to dynamically adjust the size. No idea if this would work.

I don't want the eye strain reading on this OLED screen.

I didn't realize how the documentation was organized. So, I've created a new task called react-describing-ui.

I'll just be tacking on reading progress on this section on react-describing-ui from this point forward.

I've been trying to pick out "Fire and Rain" on acoustic guitar by ear.

I think the path argument might just be a reference to an array of gesture vertices, which seems to mean lifetimes. no no, this will be good for me.

In theory, I think I have something that might work. But now I have to get back to interfaces.

Amazingly, it seems to mostly work.

Right now the example timings are off.

I realized I had to make sure behavior logic was working as expected (Aval -> (A_dur, A_bhvr) -> B_val)

Got a make error.

Reading through Rack dev tutorial https://vcvrack.com/manual/Building

Okay this is going to take a while. Sigh. Will get back to this. 20:30 Back at it #compile-potential-vcv #timelog:00:17:22 20:45 It builds, and it seems to open up in VCV Rack #compile-potential-vcv I put the potential repo in the plugins folder of the Rack directory. Also, compiled Rack from source. 21:00 Okay I've seen enough. I'll have to see what I can do to study this. #compile-potential-vcv

I'm thinking about building a simple web demo involving 4 voices, reverb, and some buttons that allow you to switch between chords. Probably just 4 or 5 buttons with chord states. It would be cool to be able to switch out chord sounds too.

Looks like a small overview page, with some follow-up links.

(Other tasks linked here).

I need to get chip clips (for holding my remarkable in place on easel) and maybe chocolate.

Thinking about abusing my tagging system in my logs to link TODO tasks with dagzet items.

It just worked out of the box which is nice.

The "dz" is the prefix for a node in the dagzet. following that is the path, with slashes "/" replaced with dashes "-".

As a proof of concept, I'll need to write a program that can use this log entry to link the task it belongs to the dagzet node being referenced here.

I've also created a proof of concept

Will follow up on this... at some point.

This will make it easier to spin up voice demos.

Moving Nose to its own file.

Creating Voice file with struct

Adding Voice example. Does this make the unused warning go away? Oh, nevermind. I wasn't making the struct public.

Wow, it sounds bad.

https://youtu.be/aynHSTsYcUo?t=21

See: <<rust/potential_vcv>>.

Okay fixed. Glad that was an easy one.

I probably needed to restart the browser.

See: <<career/system_design_primer>> and <<career/interactive_coding_challenges>>.

There are some follow-ups that I'm probably not going to do.

Going to start a stop watch, and then somehow use the tag system here to log a duration with the event as the start time.

I found a hard copy of the Elements of Computing Systems and read the preface and intro

HACK THE PLANET!

A group of us ate at NAYA.

At this point, I was very out of my depth. Jeff was very patient with me. Thank you, Jeff.

We were struggling getting zoom to work with the iOS emulator. But our thing did technically work. Sort of felt like I made a jerk of myself in front of everyone. Oops.

John Cage once asked how he felt about his audience laughing at some of his (admittedly odd) work, to which he replied "I prefer laughter to tears". No tears, only laughter. I suppose I was entertaining. So, I'll take the win.

I think I am what you'd call an Introvert's Introvert. Being around people at RC is quite enjoyable, but it has been draining for me. I'm really starting to feel it. I'll need to see what I can do to find some quiet and recharge later this week.

Suddenly being around so many people after years of being around so few is an ongoing adjustment for me. Still, it is important to me that I try to push myself a bit and coax myself out of my apartment into uncomfortable situations. The people here are friendly.

The extension doesn't work on the current iteration of react ("This page doesn't appear to be using React"), but it does work on the React website.

Moving on with the tutorial without it.

Originally, the idea was to use this is a proof of concept for the WAV writer. Things have moved forward without needing this.

LFOs are still a thing that would be nice to have though, so I'll keep that in mind.

Thinking about building a simple gesture signal generator in Rust this week.

The thing that makes this difficult is that I want the UI elements to update with the internal state. I'd need to build something out to do this.

What's a quick way to get this done?

https://stackoverflow.com/questions/35659430/how-do-i-programmatically-trigger-an-input-event-without-jquery

I need to set the slider from JS, then fire off an input event to set the rest of the parameters.

A little bit more challenging, since those sliders are made an older way. Hopefully I an refactor this so all the sliders are made the same way.

I suddenly ran into some weird issues with the textarea textContent value, so I changed it to be value instead.

See: <<webdev/textcontent_mdn>>. I am not sure how it was working all this time then suddenly not working.

It took a few tries, ended up looking up a draw.

In the rust version, I'm getting 2.0. In the original, it's -0.1.

Similar deal actually. The original is still a small negative value.

I have my velum set to be 0 in the rust version. So there is definitely something wrong with these left/right reflection coefficient calculations.

It is larger in the reference (~7.3) vs my implementation (1.062).

I had my nose starting position calculated using a relative percentage of the tract length. Maybe this is an unstable way to do this?

There were typos in my reflection calculations. Additions that were supposed to be subtractions. Looking up the wrong index.

I lost the ideal tube shape sound. Going to need to fiddle around with the interactive example.

I think this was getting in the way of wasm compilation.

lots and lots of trial and error

At this point, I'm just having fun. I think the velum is correct haha

Now, time for cleanup.

My shapes for the throat singing example are ruined once again because there was some code I accidentally commented out.

Textarea with a button that says export/import. Export fills the textarea with the current vocal tract state. Import loads the stuff from the textarea.

Probably not going to be an ideal design pattern. I can already see why an architecture like react would be helpful.

Good enough for tonight.

There is something wrong with the omega (w) coefficient being computed inside of compute_scattering_junctions. Peeling that back some more now.

w_r[i - 1] is fine, and doesn't NaN before w.

w_l[i] is also fine, and doesn't NaN out before w. r[i] is the only variable left in there. Let's see if it NaNs.

r[i] is also fine. huh?

I'm guessing it must be an overflow NaN. Some big numbers somewhere. Going to use dbg! to inspect the variables w_r[i - 1], w_l[i], and r[i].

Check it out:

[src/tract.rs:183:17] w_r[i - 1] = 2.5360622e38
[src/tract.rs:183:17] w_l[i] = 1.0904602e38
[src/tract.rs:183:17] r[i] = 0.0

So, I gotta figure out why these numbers are getting so large. In my experience, it's usually due to numbers being so small.

I could change the precision to f64 instead of f32, but this moves the goal posts, and might not actually fix the underlying problem.

Found an intersting thing here. I wanted to break down the components giving me NaN. So I wrote some debugging code that looked like this:

    let add1 = w_r[i - 1] + w_l[i];
    let add2 = r[i] * add1;
    if add2.is_nan() {
        dbg!(r[i], add1);
        panic!("NAN");
    }

The results of this are here:

[src/tract.rs:190:17] r[i] = 0.0
[src/tract.rs:190:17] add1 = inf
thread 'main' panicked at src/tract.rs:191:17:
NAN

If it's false, it's inf.

It's going to be in the nose tick function somewhere I think.

Specifically, i is at position 11.

Specifically at tr_jr[nose_start].

It seems like the reflection coefficients might be causing things to blow up.

Transfer inked up outline to graphviz dot format. See: scratch/howworks.

Useful guide on writing graphs with dot: <<misc/dotguide>>.

see: how_logging_works

Gotta get images working now...

images are new, just want to make sure that code works okay.

Above it is the computation for the left junction. I'd imagine a symmetry between them, but it is not symmetrical. The original voc source code looks like this as well. I think I may have to go back to Pink trombone and check on it. At some point. In the meantime, I've dropped a TODO.

It's the damn LCG again in the glottis.

going off track a little bit

But it sounds cool. Might want to import my reverb for added effect.

But the good news is that it did build.

I gotta get ready for a presentation.

Wiki page I presented from: how_logging_works.

Line by line debugging, comparing to reference C file. Yick.

looking at it again. I have tried to clean up the code to make it more readable.

Must be dividing by zero somewhere.

ns_r and ns_l both have it (which makes sense). Not sure which one gets it first. Going to check above.

Listing these as I go.

1367: tr_jr[nose_start].

1367: tr_l[nose_start] is NaN before tr_jr[nose_start].

NaN-hunting fries my brain.

So far, I believe tr_l[nose_start] to be the earliest introduction of a NaN as sample position 1367.

tr_l[nose_start] has a NaN at 1366 at the end of the computation loop, after the nasal component is made. It happens right after update_waveguide.

tr_l is copying over tr_jl with a multiply by 0.999. Where is the last place junction left is begin updated?

Junction Left at the nose start is the earliest instance of a NaN I have found in my code. At 1366, it is introduced before the nose tick, but after compute scattering junctions.

I think I've wrapped up most of my contributions to the game jam. I don't think I can afford to do much more.

"Velum" refers to the membrane separating the oral cavity (mouth) from the nasal cavity (nose). The nose is another waveguide. The velum is just a value that controls the opening of this waveguide.

I think I understand enough to start coding some things up.

I was out there for 2 minutes, got to half a block, and got completely soaked.

Things start to get trickier here beacuse I'm trying to separate tract and nose code, but this needs stuff from tract.

I inked up some of my thoughts, set up priorities, attempts to focus what the game components will be.

I guess I'll have to live with it?

Instead of updating the xoffset every time, create a new rectangle with global X offset applied.

I don't necessarily want double rectangles every time any more.

I have the schema, but more refactoring is needed. I want to load the raw rectangle and skip the tube positions (which then copy over to the rectangles).

The JSON file is loading rectangles directly, I don't think tubePos is required anymore?

Velum is not implemented in tubular <<voxbox/tubular>>, but it is in implemented in tract <<voxbox/tract>>. Getting tract code tangled and re-examine what needs to be added.

The original tract waveguide had a fixed size of 28, which should be a size in CM (which will most likely be expressed as proptional percentage of the tract width in practice).

The harddcoded size is 28, which I believe is 2x oversampled, so that's 14 samples.

Looks like it is around 10-12cm:

To derive, I opened the equation I was using to convert tract len (cm) to samples in bc:

(len * 0.01)/(speed_of_sound / sr)

or

(16 * 0.01)/(343.0 / 44100.0)

I forgot this week was the game jam. My velum work will have to wait a few days.

It is very faint.

Ah. Lag was at 0.7 instead of 0.07.

Ah, chrome was still caching stuff.

URL: https://pbat.ch/recurse/demos/singer_test/.

My friend says it doesn't work on iphone safari. I found a potential fix at <<webdev/audioworklet_safari>>.

I'm reverting changes back to what I did before

Here is what I wrote:

I have ported my tract filter to rust now [0]. I couldn't resist garnishing my "simple" example a little bit [1] to make it more musical and sing-y.

In addition to the bare minimum tract filter processing the glottal source, I've also added some controls over vibrato, amplitude, and tract shape (for vowel morphing). I tuned the tract shapes by ear using the distinct region model.

0: https://github.com/PaulBatchelor/voxbox/blob/main/src/tract.rs

1: [[https://github.com/PaulBatchelor/voxbox/blob/main/examples/tract_simple.rs

Link https://react.dev/learn/tutorial-tic-tac-toe

I want to push myself to get some singing sounds in Rust by the end of the week.

Struct initialization feels like a pain point to me.

Using this as a learning opportunity.

Okay, looks like I want to implement a filter as a trait. See: <<rust/books/rust_by_example/traits>> and <<rust/books/rust_book/traits>>.

I want to set aside some time to actually do this right. It's not quite fitting in my head at the moment, and I need to keep moving forward. Ultimately, what we want is to be able to have a nice way to define two two types: highpass and lowpass, which are two types that use identical data structs but slightly different methods.

I imagine it'll be pretty trivial to return and refactor. So far, this has been my experience with Rust.

These are needed to filter the noise source in the glottal model.

I'll just copy that over. duh.

Revisiting <<rust/organizing_code_project_structure>>.

Here is the winning code block for imports.

use crate::butterworth::{ButterworthLowPass, ButterworthHighPass};

Also needed to make sure that lib.rs had butterworth imported too.

I will need to return to implement the highpass filter.

There was an attempt to multiply with overflow. It seems to be a problem with the RNG.

disabling noise source for now.

Here is the debug script:

rm -f glot_simple.wav
cargo run --example glot_simple
mnolth wavdraw glot_simple.wav glot_simple.pbm

ah. I didn't finish setup_waveform()

I will log as I go.

setup_waveform: found multiply that should have been add. otherwise, it looks okay.

settuptable looks good. -- rest of initializer looks good. -- tick(): I messed up most of the exp function translations. Rust has a weird notation for this. instead of exp(x), rust does x.exp().

Looking at checked multiplies, <<rust/checked_mul>>, but that doesn't seem quite right. I want to do wraparound.

It seems to be okay with this solution:

fn rand(&mut self) -> u32 {
    self.rng = (self.rng.wrapping_mul(1103515245) + 12345) % LCG_MAX;
    return self.rng;
}

wrapping_mul was what I needed to keep the panic away. See <<rust/wrapping_mul>>.

I have finished porting the glottal source component of my singing synthesizer from C to Rust. It was a bit of a tedious effort, but luckily the setbacks were small.

The port can be found here: https://github.com/PaulBatchelor/voxbox/blob/main/src/glot.rs.

Sample code writing to WAV file: https://github.com/PaulBatchelor/voxbox/blob/main/examples/glot_simple.rs.

This implements a glottal source model based on the one described by Hui-Ling Lu in their dissertation. It includes a version of the LF glottal flow derivative waveform model (based off an implementation by Neil Thapen of Pink Trombone), as well as a synchronous pulsed noise component for breathiness and aspiration.

On the first pass manually translating C to Rust, I ran into some issues. Most of the issues ended up being related to the way Rust handles math functions. Instead of doing something like exp(x) like you'd expect, Rust tends to use notation like x.exp(), and I messed up the notation.

By itself, the glottal source component sounds pretty unremarkable. It will need a tract filter before it starts to sound talky.

Tubular <<voxbox/tubular>> is the port I'll be basing this off of, and already I can see I did a lot of pointer stuff to manage buffers. I'll probably need to peel things back a little bit and remember what I was doing before going forward.

I attempted to quickly find food before my next appointment. There was not enough time, and ultimately gave up. Fortunately, there was a bagel in the kitchen.

Ate in the food court.

looked into mutexes. <<rust/mutexes>>

see @(dzref "rust/tinyaudio")!@

I started with the general question "what is it that I'm trying to do here?" and worked from there. It ended up being a good way to articulate why I chose to do my singing synthesizer project.

I'm trying to find a job. I'm using my time here to diversify my skills to something less niche so I have a better time finding relevant jobs. My career up to this point has involved a lot of "legacy" systems that nobody is hiring for (unless it's a super senior position).

The project I have chosen here involves experiments in singing synthesis that run in browser. This to me has a good balance of familiarity (comfortable) and unfamiliarity (uncomfortable). Audio programming, singing synthesis, and DSP algorithms are comfortable things for me. The regions of the uncomfortale and unfamiliar lie in how I am doing these things. Namely, Rust (to webassembly), and just about anything related to web development.

I think my starting point is learning Rust. Even though it is quite complicated, it is the shortest distance away from my zone of familiarity, since this is where I'll be doing the audio DSP work. My first few weeks here will be spent building the core DSP kernel.

This is the algorithm I'd like to use: https://git.sr.ht/~pbatch/mnodes/tree/master/item/glot/glot.c.

This is hard for me because I don't actually know what the best practice is for organizing library code.

Found this: https://rust-classes.com/chapter_4_3

Basically, wanted to see how Rust projects tend to split up components in a project (rather than one lib.rs file).

Glanced at some docs for this <<rust/organizing_code_project_structure>>, and <<rust/bringing_paths_into_scope_use>>.

There doesn't seem to be any good way to have shared code in examples that isn't included in the library. Something like monowav <<voxbox/monowav>> isn't something that really should be a publically available functionality, but it's really useful for rapid prototyping. It's also too small to make it a whole other project. For now, I'm just leaving it in there.

Going to need this if I want to connect logs to specific tasks.

Will need a new table for this. I also will want to reference tasks specifically, so I need to make sure I can get the right rowid from the logs row.

I don't have a formal constraint for this, but this is a reasonably safe assumption. I'll use this to look up the rowid.

The tag parsing is always done immediately after inserting the log entry to the table. I assume it auto-increments and is the largest? This would be much easer.

It works!

select tag, logs.title from
logtags inner join logs on logs.rowid = logtags.logid;

This is some bold text.

This is because lines by default get their lines truncated.

My org parser is very strict about whitespace, and I had to be a little more involved about how to extract blocks here. It works though.

If the tag belongs to a task, then this is a comment history.

This seems to work:

SELECT day, time, title, comment from logs
INNER join logtags ON
logs.rowid = logtags.logid
WHERE logtags.tag is "add-tag-parser"
ORDER BY logs.rowid ASC;

The - - - (no spaces) is something I'm using as a divider. I reworked the logic so that it's included in the SQLite data, and then handled when the HTML is rendered.

Previously, it was part of a pre-processor that actually got filtered out before the SQLite table.

This will allow me to view a timeline of logs given a task name id.

This will be similar to what I did for dagzet. Create one page for each task, and give it a prefix like tasks/htmlize-tasks, which then displays a timeline of logs.

I was thinking this could be like taskgroups/priority, with taskgroups display a directory of all the groups.

This will just be at taskgroups.

What's left here is to add descriptions to tasks and grouptasks, and also to add ordering to the task group lists. But hey, this is good enough for now.

I have a slow phasor modulating the frequency of an audio rate phasor, which is getting filter by an LPF.

Here is the phasor implementation: https://github.com/PaulBatchelor/BoingBoingBoing/blob/main/src/phasor.rs.

Here is the example:https://github.com/PaulBatchelor/BoingBoingBoing/blob/main/examples/phasor.rs

I don't actually have a boilerplate script for this.

Now that there's a weewiki here, things should be more straight forward.

I'm not going to worry about the tag system here, that can happen later. I just want to be able to add the timestamps and messages.

This would be one line. This would continue the same line because there isn't an empty line.

This would be another line.

It looks like the parser I wrote ignores the extra line breaks. Rather than try to update the parser, I'm going to say that a line "

" will insert a line break, which makes sense.

I should have been using an "or" operation instead of "and". Funny how I keep confusing the two.

This whole rabbit hole started because what I was calling "comment" in the time events, I called "blurb" in the dayblurb. I was accidentally trying to get a comment from a dayblurb instead of a blurb. It was returning nil, and it was still considering it valid. I had to update the conditional logic.

Get all available dates, and then render each one by day.

I'm hoping it's not a weewiki thing because that would be tedious.

In weewiki, I use @!(foo "bar")!@ to do inline janet stuff, but in Day 3 I was using that in another context. The workaround is to put it in a code block.

I shouldn't be nested git repos like this

Adding for each entry would be cool too!

Just getting the boilerplate code and parser hooked up.

This table I'm currently on is just slightly too high.

sidetracked... took a picture of my new setup and posted it to mastodon.

Refactoring the script now...

Prev: more voxbox scaffolding, wrote a simple wav writer in C, presentations Next: start writing wav writer in rust, plan out DSP layout in voxbox and make tasks for them, building your volitional muscles

It kind of exploded. Hoping it will be okay.

Got into talk with someone

just some scaffolding

Got pulled into various conversations.

Doing some messaging on zulip.

Raining today, might go into the hub later.

Yesterday I pushed initial code: https://github.com/paulBatchelor/voxbox Used cargo to generate a library, with examples, similar to my boing^3 library.

Also setting up my adhoc workstation while doing this...

While setting up my adhoc workstation, my trackpad decided not to work. It was a faulty microusb cable. Tossed that in the trash.

I feel like I wrote a bare bones mono wav file generator somewhere in C.

going to write a quick and dirty one in C, then port it to rust. Reviewing the spec now.

Got side-tracked with Dan during this.

hex viewer is nice. I'm assuming it's only going to be one data chunk with PCM. What I'm not sure about is: how does it know to do 16-bit and not like 10 or 12 bit?

I figured there'd be a tool for this. exiftool looks to be about right.

I used sox to convert my generated wav into another wav, and it fixed some things. I diffed the xxd'd output and saw the header differences.

4 bytes for RIFF 16 bytes for fmt 16 bytes for data in riff?

next steps: get dynamic file size working.

Now, to tackle the file size things. I'm anticipating when I port this to Rust, I'll want to be able to write the stream of an indefinite size, get the total samples written to disk, and then update the header bits. It would be nice to do that using someo kind of r/w mode. Otherwise, just close and re-open.

My Orphium project is updating stuff in-place, which flag is it?

Ah, appears to be "a+".

Nevermind, just didn't update everything, and had to go back to the beginning of the file. Be kind, and rewind().

Making it a commandline application to take in input/output params.

I just looked up the man pages. "w" is fine.

Next steps are to port a version of this code to rust as a mono wav writer to boing^3. After that, it should be ported to voxbox with some sine code to make sure I can get WAV files generated.

DIY auto-encoder, RAVE: realtime auto-encoder, RAVE on Daisy (hey I know these guys!) (didn't work), on norns? Maybe I can help with the norns stuff?

pharo smalltalk VM

Navidrone, clerk (clojure)

"tech demo state"

Use checkin stream, show links in zulip. "closed" on monday. kind vs nice: try to be kind.

renaming logs so far

top 3 skills/attributes that I want to cultivate during my time here: Effectiveness, Agency, Conscientiousness

It's already blowing up. I'm going to lose track.

I should add a description metadata field to the task lists. that way it stays with the task.

Proof of concept should be to add @!desc as a known tag for description

looking up how to fix this.

Went to the apple store, which happens to be about a 15min walk away from the hub.

I want to build and run this locally, and document my steps for this. I also would like to take a closer look at the JS involved and see if there's any way I can improve this.

Got into some discussions while this was happening

I'm attempting to think up a simplified version of my zetdo system for use with RC. zetdo is built on top of weewiki/zet, which has too many intermediate parts. Ideally, I'd like to build up a simple markup that can be parsed and compiled into data for further processing later. Tasks have the following parts: a sentence describing the system, an optional description, and then a list of timestamped comments that can be arranged as a thread. Occasionally I group tasks into lists, but I haven't done anything complex enough to warrant a formal dependency system. For now, using my "descript" notation could be enough. This would allow me to easily build uniquely named blocks where each block could represent a task. > @foo-task this is a foo task > this is a foo description My timeline notation can then link to tasks using tags > @2024-05-21 > @08:48 I am writing a test comment for the foo task. #foo-task

What to do about tasks that are done? Maybe not think too hard about it and move to a done.txt and a nevermind.txt for tasks that I won't do.

There was a bug in my parser that I fixed previously.

It seems like for groups/states, I'll be putting things into files. So, current tasks are in main.txt, done tasks are in done.txt, cancelled tasks nevermind.txt, rust related things in rust.txt, reading in reading.txt, etc. Filename could be a meaningful parameter in the schema.

Attempting to take notes while I read.

Useful for autocomplete tags in Vim https://stackoverflow.com/questions/10789430/vims-ctrlp-autocomplete-for-identifiers-with-dash 'iskeyword+=\-' was good enough for my needs.

I'm realizing that I may want to spend some time getting used to how Rust is designed, instead of jumping into code (though I already have some boilerplate ready for porting DSP). I think overall things will be faster if I figure out how to think in Rust, rather than trying to apply my pre-existing notions of programming towards Rust.

Seems like some decent wisdom. There are many links and follow-ups, which may be worth looking at later.

I'm feeling a little bit bad about this, so I thought I'd write a few words on it. Firstly, I'm exhausted. The time between my last job and living situation and the start of my batch was too short. I knew this coming in. I'm adjusting to what are for me have been some huge life changes in the last week. Secondly, and perhaps more importantly, I think I'm also a little intimidated? Imposter syndrome, etc, etc. I've taken about a six month break from writing code. Lots of reading and research around the code. But coding itself has been fairly sparse outside of a few ad-hoc scripts. I also doubt my skills a fair bit. I really only know a modest amount of C, along with a handful of scripting languages on top of that. DSP and realtime audio puts a limit the kind of languages you get to study. Most languages used today are simply not suitable for realtime or soft realtime applications. As a result, I've never had many opportunities to work much with other languages. It's hard having that feel like the only language you feel only sort of comfortable in. I guess I wish I had more go-to "modern" languages that are less niche. I'm hoping I'll be better at getting over myself in the next few weeks.

Update: languages used in the pairing workshop: Javascript, Java, Scala, C/C++, Clojure, Rust, Lisp, Racket, MIT Scheme, OCaml, Ruby, Python, SystemVerilog/Hardware, Elixr, Erlang, R, Golang, bash, csh, Kotlin, C#, Julia, Swift, SQL, Zig, Awk, Elm, Nim.

Looks like this is just "rustup update"

Can I get this to build and run still? Do I understand what is happening?

Do I have examples, and if I do, can I build them with Cargo? I think there's a way, and I'd like to look it up the slow way (instead of stackoverflow: find a good book online, then find it inthe book)

I made a dagzet for the book at "knowledge/software_foundations.dz"

Adapted from my mkdb script.

Want to group things by top-level namespace, so I want to select up to first (nth?) "/", https://stackoverflow.com/questions/21328295/sql-with-substring-to-a-special-character-with-sqlite

Select distinct top-level nodes from dagzet > select distinct(SUBSTR(name, 1, INSTR(name, "/") -1)) from dz_nodes Curious if I can get secondary ones.

Making a "career" knowledge graph.

TODO: look at NIH plug for Rust plugins

I am currently writing this first log, then adding it to the repo.

I need to import my tools and make sure they can work outside of my repo.

Gotta get dagzet utility working.

This involves creating a rotation utility.