This is an old revision of the document!
Table of Contents
May 2025 newsletter
If you want to stop by the studio, our next Folk open house is in the evening on Monday, June 30, in East Williamsburg, Brooklyn.
What we've been up to
This has been a less eventful month for the system, aside from folk2 work; we've been spending a lot of time on fundraising and associated paperwork lately (let us know if you want to help out or have ideas for us).
Demos and applications
- Mason Jones has been updating his matrix demo so that its rotation is now relative to the origin point:
General system improvements
- Daniel Pipkin fixed up his ESC-POS receipt printer code – it had been broken by the new geometry logic from a few months ago
- Omar made laser blob detection opt-in to improve performance
- Andrés updated the layout of the /keyboards page
- Andrés also made a video about setting up a USB keyboard:
- Mason added support for the
anchor
andfont
options toWish $p draws text
- Mason has been working on a new version of the editor that can edit existing programs – currently reconciling it with the old editor
- Also includes scrolling
- (Omar: will also need to forward-port it to folk2 later, but that shouldn't be too bad)
folk2
Omar: it's still coming along. I would say the page quads side quest from the last couple months is now mostly resolved (calibration and editor working again; everything merged into the main osnr/folk2 branch now that I feel confident that this is the right way), so we're back to finishing off functionality so that we can start to merge folk2.
Re-porting the editor to use page quads
The editor works again now in folk2, and it draws on page quads! It feels really fast now and like it doesn't affect rest-of-system performance (since it's hardly doing any new draw operations), so you can pull out a ton of editors comfortably all at once.
An early glimpse of the editor working:
(I'm moving a page on top – this was mostly recorded to show the weird passthrough of the compositing.)
I implemented ''quad move'' so we can create synthetic quads to replace the synthetic regions that we previously used to make the editor area and virtual program area. (It's nice that I'm now forced to make the editor actually 3D-native; we've been wanting to do this transition from regions to quads since last year.)
It is pretty annoying to create synthetic writable images right now for virtual entities like that. We probably want some sugar/wrapper for this. You have to set up a synthetic geometry, a transformation matrix, make the GPU texture, etc, and you have to get all of those right or you don't see anything.
I changed the editor render logic to work in terms of real-world page-local coordinates, so that it renders properly onto the texture target (and also doesn't have to change whenever the editor moves, only when the actual editor content changes).
Memory leak fixes
I fixed some subtle memory leaks with the C implementation of Collect, where match collection Jim objects weren't getting decr-ed. (in one case, I was calling ListAppendList and assuming that consumed the obj, but it actually doesn't, since the list just gets iterated through to add its elements and not actually pointed at)
Hold debugger and bug fixes
I was debugging an issue with calibration where the new calibration sometimes wouldn't actually happen after all the poses were in place. It seemed to be an issue with the Collect when calibration poses are present but no calibration is present (that negated query uses a Collect internally). And that issue seemed to come from the Hold of the collection statement not locking in properly.
So I made a Hold debugger at /holds! It lists all current Holds in the system (key, index, held statement), which is a surprisingly useful lens to view everything going on in Folk (not as much spam as the full-statement list, and things that go wrong are usually Hold-related).
I used the Hold debugger to find 'anomalous' Holds that shouldn't exist, where the statement ref associated with a Hold is s0:0 (null). That means we tried to Hold a statement and then failed or something.
Calibration
Most of the month has been spent on trying to fix calibration. When we have good calibration, we'll be able to merge everything into folk main.
Bilinear interpolation issue
I fixed another really horrible floating-point issue with our inverse bilinear interpolation that caused tags to glitch out (which then halts your entire calibration process).
I isolated it to one draw statement with numerical arguments that trigger it, so I could just hammer against that in a program instead of running all of calibration:
(I think this issue was present in folk1 also and was causing the periodic glitch-outs where you'd have to reset calibration – it's just much more likely to appear now that we're working in local coordinates instead of global table coordinates)
(This is a follow-up to the fix from last month – I just took the fix for this bug from a comment on the page that I used last month.)
New homography estimation
Replaced the homography estimation algorithm from libapriltag that we were using with one straight from the Hartley & Zisserman textbook.
This is much, much more stable and doesn't get into weird states where tags blow up in size or get really skewed, which we were manually filtering out in folk1 and was even more of a problem on folk2. (We could do more by also adding a nonlinear optimization step at the end. I think OpenCV might do that. That's something to try if we need more calibration accuracy.)
Calibration starting to work?
Anyway, the good news this month is that I can now reliably calibrate to completion, just as well as on folk1, no weird glitching out (and it's a lot faster, like 2x faster – 150ms instead of 300ms cycle time).
The bad news is that calibrations on folk2 are much less accurate than folk1 and not really usable! And I don't know why that is yet. Here, the calibration on the left is from folk1 and on the right is from folk2:
Notice that error values are way higher on folk2. We have stereo error of like 18 pixels instead of 2 pixels. And it's even worse in practice – your outlines will be a few inches off instead of millimeter or even centimeter accurate.
I wonder if projector error in particular is just a lot worse and that's what's driving the stereo error.
AprilTag frame previews
I wanted to debug if calibration was poor because we weren't detecting enough tags per pose (or the tags were really off). (maybe because the system is faster and we're missing ephemeral statements when we check out the pose)
Started by implementing a new endpoint /apriltag-frame:
Then added a similar live preview to the poses view during calibration:
Looks fine to me, so let's rule some of these hypotheses out. I think we're getting decent tag coverage and the positions are pretty accurate. (it could still be that the internal homography is messed up and that's why our optimization ends up with a bad result)
(I think this is reporting functionality that we've wanted for a long time to make the calibration user experience nicer, so I'm glad to have it)
Jim updates
Added jim-base64.c, a C base64 encoder mostly copied from standard Tcl, because it turned out that the major bottleneck in the /images debug page taking forever to load was actually our pure-Tcl base64 encoder.
Updated the vendored Jim to 0.83+ (was on 0.82). This gives us aio timeout, so the web server hopefully won't freeze up forever (which has started to be a problem). We'd made some changes to Jim (mostly thread-safety stuff and source provenance stuff), but not too many, so rebasing wasn't so bad.
I'm relieved that we should be able to stay up with Jim better from now on (they've fixed a few bugs for us already, so it's useful to stay up to date with them).
Mason's shared objects branch
Mason has been working on a branch where objects can be shared between threads. He rewrote a lot of Jim so that pointer changes (when objects shimmer) can 'bubble up' into the interpreter so that objects can be treated as immutable and shared.
Omar made a simple test of whether it works in the presence of actual multithreading:
Finally, Omar digested the changes into folk2 so we can run Folk on top. Involved passing the interpreter into a lot of getters that may shimmer the object (because you need the interpreter to bubble the shimmer):
folk2 works as normal with this fork of Jim. But not doing actual object sharing between Folk worker threads yet; that's the next step here. Have put it off until calibration works and we can use that as a one-metric performance test (but we might be there now…)
Outreach
Open house
We had our open house on Saturday, May 31.
Omar showed the new evaluator, which is at least usable to the point of showing outlines, labels, and editor, and is visibly much faster – it was cool to finally bring that out during the open house and be fairly sure that it works.
We're trying a new format where we give a stage talk and take Q&A at the end to bring everyone together:
SenseScape event
Other visitors and interactions
- Kelli Anderson and her current Paper Engineering class visited on May 15; they had a lot of fun writing Folk programs, doing origami, and chatting about the possibilities of the system for paper engineering and beyond:
- (Andrés) Monique Evette visited the studio May 19th after we met at SenseScape the week prior
- (Andrés) Michelle Cortese visited and made this flower stop motion animation below. We also discussed her research and how Folk is following in the footsteps of her hedonic design philosophy to great effect.
- (Andrés) Our friend Kelin Zhang visited and we prototyped some stop motion videos! Got this comment on YouTube from our collaborator @dpipkin/Daniel Pipkin:
- “YouTube's shorts algorithm knows what I want. ❤ Also what the heck is happening at the end?”
- For the record, the error was an export issue because I uploaded the video and it looks like it got corrupted at the end because I was posting it while on the subway lol
- Omar and Andrés went to SVA to support our friends at Spatial Pixel celebrate the launch of their new spatial computing lab at SVA.
Discord changes
- Andrés got a little ambitious and change around the Folk Discord in the last week of May. A summary of the changes follows, DM or email (cwervo@folk.computer) Andrés to request access to the Discord:
- created the channels:
#rules
(which is a special ''Rules Screening'' channel, it gets a different little icon and everything)#ideas
(previously#ideas-and-photos
)#links
(a forum channel for posting links, currently has the tags:#nyc
- Andrés accidentally un-privated this channel for a few hours on May 29th and unintentionally invited every single person from all around the world into our supposed-to-be-geo-locked-nyc-channel 😅
- that said, if you _do_ live in NYC (or would like access to the NYC channel while you're visiting temporarily) DM Andrés (who is the Folk-Discord-czar until further notice…)
- (… need 3-more-0-member-channels before sending ……)
What we'll be up to in June
- Our next Folk open house is in the evening on Monday, June 30, in East Williamsburg, Brooklyn.
- Omar: make calibration work well in folk2, port some more functionality, finally make pull request?
- Andrés: video support, still need to find a solid couple days to debug the video frame stuff.