| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| newsletters:2026-09 [2026/10/07 19:23] – osnr | newsletters:2026-09 [2026/10/07 21:10] (current) – [September 2026 newsletter (WIP)] osnr |
|---|
| ====== September 2026 newsletter (WIP) ====== | ====== September 2026 newsletter ====== |
| | |
| FIXME htmlmetatags | |
| |
| {{htmlmetatags>metatag-og:title=(Folk Computer September 2026 newsletter) | {{htmlmetatags>metatag-og:title=(Folk Computer September 2026 newsletter) |
| metatag-media-og:image=(newsletters:FIXME_img_8432.jpeg) | metatag-media-og:image=(newsletters:img_8752.jpeg) |
| metatag-og:description=(Embedding-based object tracking; RFID localization works; Rob’s dotframes demo; SVA sound effect animals; Interface Studies podcast; color wheel contours)}} | metatag-og:description=(Embedding-based object tracking; RFID localization works; SVA sound effect animals; Interface Studies podcast; color wheel contours; atomically and graphics speed fixes)}} |
| |
| |
| Our next Folk open house will be in the evening on **[[https://luma.com/wa18i4hg|Wednesday, September 30]]**, at our studio in Williamsburg, Brooklyn. | Our next Folk open house will be in the evening on **[[https://luma.com/lggnfaib|Wednesday, October 28]]**, at our studio in Williamsburg, Brooklyn. |
| |
| |
| * /program/<whatever> Web endpoint: [[https://github.com/FolkComputer/folk/commit/5d2cca7d0908501b5938cdf9ed5b72d0b84106b2|Show the edited version of the program]] if it's been edited | * /program/<whatever> Web endpoint: [[https://github.com/FolkComputer/folk/commit/5d2cca7d0908501b5938cdf9ed5b72d0b84106b2|Show the edited version of the program]] if it's been edited |
| * [[https://github.com/FolkComputer/folk/commit/723d284503373b09bdf5477f27a79dbf8c8f91a9|Made destructor inheritance dedupe on each set add]], which fixes destructor blowup (and therefore out-of-memory; you can have millions of destructors, only 4-5 of which are unique) in cycles of reused/reinherited statements (which seem more common now? not sure why? I think it was maybe from editor pointing at itself during rapid movement, causing an inheritance cycle?) | * [[https://github.com/FolkComputer/folk/commit/723d284503373b09bdf5477f27a79dbf8c8f91a9|Made destructor inheritance dedupe on each set add]], which fixes destructor blowup (and therefore out-of-memory; you can have millions of destructors, only 4-5 of which are unique) in cycles of reused/reinherited statements (which seem more common now? not sure why? I think it was maybe from editor pointing at itself during rapid movement, causing an inheritance cycle?) |
| | * Python FFI: [[https://github.com/FolkComputer/folk/commit/d53fd676079f98b34622a831d1b5df91d7230588|fixed spurious zombie detection that would kill off Python process when main thread died]], even if Folk was actually still running and we were just terminating main thread's worker |
| |
| === Atomically === | === Atomically === |
| Fixes: | Fixes: |
| |
| - [[https://github.com/FolkComputer/folk/commit/61a193000af535e2c79d6fac83fb11fa63faecb1|Add correct dbInflightDecr on the exit path]] where provisional statement is immediately thrown away (to make sure the inflight doesn't stick forever and keep the new version from converging) | * [[https://github.com/FolkComputer/folk/commit/61a193000af535e2c79d6fac83fb11fa63faecb1|Add correct dbInflightDecr on the exit path]] where provisional statement is immediately thrown away (to make sure the inflight doesn't stick forever and keep the new version from converging) |
| * Should fix "(edited)" titles sticking around randomly / after program revert. | * Should fix "(edited)" titles sticking around randomly / after program revert. |
| - [[https://github.com/FolkComputer/folk/commit/f76f3564da9080b8dc1557bbc291355f806a23e3|Support multiple inheritance]] so a Match or Statement can be part of multiple AtomicallyVersions at once (from different keys) | * [[https://github.com/FolkComputer/folk/commit/f76f3564da9080b8dc1557bbc291355f806a23e3|Support multiple inheritance]] so a Match or Statement can be part of multiple AtomicallyVersions at once (from different keys) |
| - Support auto-atomically in first pattern in & join | * Support auto-atomically in first pattern in & join |
| - Collect retains previous version when atomic | * Collect retains previous version when atomic |
| - One-way hasConverged (latch convergence) to prevent 'livelock' where no version completes for a long time because versions keep getting unconverged by new work | * One-way hasConverged (latch convergence) to prevent 'livelock' where no version completes for a long time because versions keep getting unconverged by new work |
| - Timeout by parent removal instead of by time of last convergence: fixes title/outline blinking out on stabilized quad (where the last convergence is often very old but still valid) | * Timeout by parent removal instead of by time of last convergence: fixes title/outline blinking out on stabilized quad (where the last convergence is often very old but still valid) |
| - [[https://github.com/FolkComputer/folk/commit/3815a0d235f55de1185aea223dbe6303cceb5fb1|Do fresh atomically at match creation time instead of prologue]] to fix blinking because empty AtomicallyVersion (when root is invalidated) races and is accepted as valid | * You can also use the -keep option on the When to set a custom timeout, for things where you expect re-convergence to take a long time or just never want expiry (it's a 'singleton') |
| | * [[https://github.com/FolkComputer/folk/commit/3815a0d235f55de1185aea223dbe6303cceb5fb1|Do fresh atomically at match creation time instead of prologue]] to fix blinking because empty AtomicallyVersion (when root is invalidated) races and is accepted as valid |
| |
| Also comes with a [[https://folk.computer/notes/animation|new version of the animation program]] that can now blink much less and be more reliably timed, fixing bugs like this: | Also comes with a [[https://folk.computer/notes/animation|new version of the animation program]] that can now blink much less and be more reliably timed, fixing bugs like this: |
| ==== RFID localization ==== | ==== RFID localization ==== |
| |
| Current state of RFID localization is that it can talk to the tag at up to a meter and can also localize it reasonably well, but drops off afterward: | Current state of RFID localization is that it can talk to the tag at up to around 1.1 meters (but drops off afterward) and can also localize it reasonably well to within a couple cm. We went up from like 30% successful tag detection rate at 1.1m to around 90%: |
| |
| {{:newsletters:img_8722.mp4}} | {{:newsletters:img_8722.mp4?400px}} |
| |
| It's still a sort of coarse localization -- we need to use more fine phase data and also start triangulating from multiple radios, I think. | At home -- it talks to the tag fine on table but not once I move it further outward to couch: |
| |
| | {{:newsletters:img_8882.jpeg?0x200px}} {{:newsletters:img_8883.jpeg?0x200px}} |
| |
| | In September: |
| | |
| | * **Fixed channel estimation bug**: we were mistakenly treating all bits as flipping between reflective state and non-reflective halfway through, but only '0' bits do. This fix massively improved our distance estimates |
| | * Subtract baseline carrier wave to improve detection range |
| | * Faster RFID protocol implementation (integer arithmetic) so we are better at making the ACK deadline |
| | * Retain the channel at each hop so we can still localize even if we didn't get a valid hop last round |
| | * Persist stuff to disk, run headless for testing loop |
| | |
| | Hop alignment between RFID reader (in-band) and out-of-band localization helper radio looks pretty good: |
| | |
| | {{:newsletters:screenshot-2026-09-06-at-10.15.10-pm.png?450px}} |
| | |
| | Uncalibrated localization (we pick that first peak to probably be the line-of-sight path and tell us the estimated distance to the tag from that): |
| | |
| | {{:newsletters:screenshot-2026-09-06-at-11.42.20-pm.png?400px}} |
| | |
| | It's still a sort of coarse localization -- we need to use more fine phase data and also start triangulating from more than one OOB radio, I think. Would also be nice to increase speed. Will also do a Folk projector demo like what we used to have to make the detection accuracy more visceral. |
| |
| ==== Object tracking / DrawTalking ==== | ==== Object tracking / DrawTalking ==== |
| |
| {{:newsletters:img_8614.jpeg?300px}} | {{:newsletters:img_8614.jpeg?300px}} |
| | |
| | (Inelegant: pose registration step still requires SAM2, because SAM2 is how we cut the object out of the page/background so the embedding is only of the object itself. SAM2 can take a second or two on slower machines, as we saw last month, and you have to download the whole model. Did [[https://github.com/FolkComputer/folk/commit/209b19bbb7c0408d607488fe178f8d664d8ca9d0|fix some memory leak bugs in our use of it this month and simplified our API for this more limited use]]. Anyway, not as bad as having SAM2 in the inference phases, but would be nice -- for performance and simplicity -- to use some greenscreen technique instead of SAM2 in registration, IMO) |
| |
| Then I started doing localization, where we basically cut the viewport camera slice into cells and compute the embedding of each cell. You can get these really nice intepretable heatmaps of what the most 'cup-like' or 'army-toy-like' 'earbuds-case-like' (or whatever you want to find) regions of the viewport are. | Then I started doing localization, where we basically cut the viewport camera slice into cells and compute the embedding of each cell. You can get these really nice intepretable heatmaps of what the most 'cup-like' or 'army-toy-like' 'earbuds-case-like' (or whatever you want to find) regions of the viewport are. |
| {{:newsletters:img_8752.jpeg?300px}} | {{:newsletters:img_8752.jpeg?300px}} |
| |
| Only problem is that this doesn't account for rotation and different camera angles. Solution, which we'll do next: 1. record multiple physical poses with the object rotated differently, and 2. rotate the pose programmatically to get templates every 5 degrees so you can find the best fit (which also gives you an angle). | Only problem is that this doesn't account for rotation and different camera angles. Especially problematic to deal with asymmetrical objects. |
| |
| == Rotation tracking == | == Rotation tracking == |
| |
| OK, so harder to deal with asymmetrical objects. [[https://github.com/FolkComputer/folk/tree/osnr/dinov2-rotation|Record several poses with known rotations, find the best cross-correlation, use that to give angle.]] | Solution: 1. record multiple physical poses with the object rotated differently, and 2. rotate the pose programmatically to get templates every 5 degrees so you can find the best fit (which also gives you an angle). |
| |
| It tracks the orientation of this army toy fairly well (up to 180 degree flips, at least, which makes sense): | [[https://github.com/FolkComputer/folk/tree/osnr/dinov2-rotation|Record several poses with known rotations, find the best cross-correlation, use that to give angle.]] |
| | |
| | It tracks the orientation of this army toy fairly well (except it sometimes flips by 180 degrees, which makes sense for this toy): |
| |
| {{:newsletters:img_9382.mp4?400px}} | {{:newsletters:img_9382.mp4?400px}} |
| |
| === DrawTalking integration === | === DrawTalking integration === |
| | |
| | We've started talking about the graphics pipeline that would be needed to draw many-point curves for sketches from DrawTalking. Some discussion about how to translate from DT procedural mindset to Folk reactive/data-oriented mindset. |
| |
| {{:newsletters:img_9140.jpeg?500px}} | {{:newsletters:img_9140.jpeg?500px}} |
| | |
| | The graphics optimizations for the editor should help a lot here. Instead of reusing the existing line popeline, we probably want a custom pipeline with push constants for point A, point B, and transform, and then only the transform usually varies from frame to frame. |
| | |
| | I think this integration will be a good test of Folk performance for drawing complex objects and passing complex data through the DB (which is definitely something we want to support). Like a DT object with thousands or tens of thousands or hundreds of thousands of points. |
| |
| ==== folk-cnc ==== | ==== folk-cnc ==== |
| ==== Open Sound Control API ==== | ==== Open Sound Control API ==== |
| |
| Paul: I am in the process of building out a Folk music toolkit, and one of the core components needed for this system is the ability to send OSC messages from my Folk machine to arbitrary OSC servers to control synthesizers. I managed to implement simple OSC send functionality which allows Folk users to send OSC messages using the native Folk `Notify:` syntax. A Folk environment first registers the address of the OSC server using `Claim the NetAddr is <ip>:<port>` then once an endpoint is registered Folk programs can send OSC messages using the syntax `Notify: OSC at /path/ with args /values/`. | Paul: I am in the process of building out a Folk music toolkit, and one of the core components needed for this system is the ability to send OSC messages from my Folk machine to arbitrary OSC servers to control synthesizers. I managed to implement simple OSC send functionality which allows Folk users to send OSC messages using the native Folk ''Notify:'' syntax. A Folk environment first registers the address of the OSC server using ''Claim the NetAddr is <ip>:<port>'' then once an endpoint is registered Folk programs can send OSC messages using the syntax ''Notify: OSC at /path/ with args /values/''. |
| |
| Next I will add support for OSC bundles, which will allow us to write proper tidalcycles-esque pattern languages native in Folk! | Next I will add support for OSC bundles, which will allow us to write proper tidalcycles-esque pattern languages native in Folk! |
| === Interface Studies podcast === | === Interface Studies podcast === |
| |
| FIXME: Andrés or Daniel | Omar and Daniel showcased Folk on the first episode of "Conversations," Interface Studies' new podcast. We covered tangible interaction, natural language programming, and highlighted community and collaboration. |
| | |
| | {{youtube>uXHHnps4tU8}} |
| | |
| | Andrés: I've watched [[https://www.youtube.com/@interfacestudies|nearly every video Saleh's videos]], have started sending them to my interaction design students, and (if you watch a lot of educational/edutainment YouTube you'll know this is a high compliment) I think he's the [[https://www.3blue1brown.com/|Three Blue One Brown]] of interface design. I think [[https://www.youtube.com/watch?v=uXHHnps4tU8&lc=Ugwy-XkrsTxLt0vF6Lt4AaABAg|one particularly nice comment]] on the podcast Omar and Daniel were on sums up why I'm so impressed with the channel: |
| | |
| | {{newsletters:screenshot-2026-10-07-at-16.48.38.png?400px}} |
| |
| === SVA system === | === SVA system === |
| |
| {{:newsletters:img_9615.jpeg?200px}} | {{:newsletters:img_9615.jpeg?200px}} |
| | |
| | === Utah Meetup === |
| | We had our first Utah meetup in Lehi, UT. We chatted about the reactive database and introduced the system to our host Michael. |
| | |
| | We plan to do this monthly. If you are interested, reach out on discord or email <[email protected]> |
| | |
| | {{:newsletters:september-utah-meetup.webp?300px}} |
| | |
| |
| ===== What we'll be up to in October ===== | ===== What we'll be up to in October ===== |
| |
| * Our next [[https://luma.com/wa18i4hg|Folk open house will be on Wednesday, September 30]], at our studio in Williamsburg. | * Our next [[https://luma.com/wa18i4hg|Folk open house will be on Wednesday, September 30]], at our studio in Williamsburg. |
| * Omar: Ship RFID tracker | * Omar: Ship RFID tracker; do projection demo of distance to confirm visually that it works |
| * Omar: Build automatic folk-cnc driver and preview application | * Omar: Build automatic folk-cnc driver and preview application |
| * Omar: Calibrate RTBW CNC system | * Omar: Calibrate RTBW CNC system with 2 cameras |
| * Omar: More work to make editor usable on table | * Omar: More work to make editor usable on table |
| * Omar: Filter DINOv2+NCC+rotation tracker to be more stable; integrate with DrawTalking strokes | * Omar: Filter DINOv2+NCC+rotation tracker to be more stable; integrate with DrawTalking strokes |
| * Andrés: | * Andrés: Lamp! I'm working on a gadget-inside-a-lamp project using a few [[https://catalog.lightingspecialties.com/item/personal/luxo-ls-series/k110660001|Luxo task light lamps]] that were dinged up and unused at the SVA Interaction Design program. Will have more to show when I get more time in the studio next month! |
| |
| ===== Links we've enjoyed ===== | ===== Links we've enjoyed ===== |
| |
| ==== Andrés ==== | ==== Andrés ==== |
| * | * FIXME |
| ==== Omar ==== | ==== Omar ==== |
| * http://batteries.parametrek.com/index.html?mah=1514,_&voltage=7.4V,8.4V | * http://batteries.parametrek.com/index.html?mah=1514,_&voltage=7.4V,8.4V |