some work on L5 tonight.

i updated blur filter shader code from gaussian to exponential and dialed in some good defaults. now it more closely lines up with processing/p5.js.

i also started building out a table of processing family langs, inspired by the uzulangs page https://uzu.lurk.org/

lastly i tried some initial work to fix my setup / load system but didn’t get to a solution yet. essentially i am currently running setup twice, the first time to grab the set global vars like width and height among other things, the second time to run any graphics code. this is a modification of love’s library which normally only allows graphics code in draw. the problem is that running setup twice can cause issues.

i tried setting default sizing that dynamically changes when draw runs the first time but for example this won’t work for fullscreen programs. i will have to step through my modified love.run() to better understand exactly how and where various globals need to be set before graphics draw. there must be a simple solution but i can’t seem to get it yet.

Tonight in L5 studies (which i began working on AFTER I was already supposed to be asleep), I coded a simple toothbrush timer. It shows a moon or sun smiling depending on time of day, and a rotating toothbrush. Every 30 seconds the toothbrush moves to a different position to remind you to move to a different quadrant of your teeth. When you're done, it just says "Donezo" but maybe it should stick out its tongue? dunno. I need to go to bed or else I'd have the animation be smarter (toothbrush motion, and more precisely moving through the quadrants. maybe i'll finish that part tomorrow).

Anyway, this was a good task because it reminded me I should add hour() minute() and second() functions (trivially easy in Lua).

#L5 #L5studies

Also, earlier in the night I went out with Fletcher and Grayson, who both wanted to know why they or other folks that already use Processing or p5 would want to use L5. (or even vs TouchDesigner, OpenFrameworks, etc for that matter). Good question! I gave some answers! To be presented later, but here's a few Answers:

- works on old/ancient computers (need to define this)
- stable, fast, consistent
- cross-platform
- consistent cohesive syntax
- long term reliability of Lua and Love2d
- small (size)
- can package up sketches into application
- advantages of compiled languages, advantages (and disadvantages) of scripting language, advantages (and disadvantages) of dynamic typing
- desktop-oriented though same code can (likely) be packaged for browsers via love.js (Emscripten)
- works offline - doesn't require Browser
- more TBA

I'm participating in the Creative Code Lab at MotionLab in Berlin today and am working on L5. I cleaned up the comments in L5, then implemented custom shapes - adding beginShape(), vertex() and endShape() functions - copying most of the functionality from p5.js.

#L5

and in L5 Studies tonight before bed I decided to use the new functions to draw a grid of random polygon shapes and colors

#L5 #L5studies

Warning: fast flickering frames in video.

Lots of fun today: woke late, read in the cafe for two hours, took a long walk, cooked with friends, then two hours of no-input-mixer-board music with friends in the studio (and on clarinet).

I also worked on L5 for a couple hours and implemented a lot:

* I fixed looping! loop(), noLoop() and isLooping() should all work correctly now
* I added default width and height to the offscreen buffer for createGraphics
* I added the ability to draw textures to (custom) shapes with newly implemented functions texture(), textureMode() and textureWrap()
* I added a bunch of reference pages, example code and screenshots

Then implemented a rapid L5 studies test drawing randomly selected textures to screen.

a further iteration testing out the functionality added. i tried adding a folder of 50 JPGs to load but found it crashed the computer. i resized them to screen size instead of 4MB files and worked fine.

not sure what speed i should run this "screen saver" at or whether i should do the abstract or more clear version. here's a medium speed abstract one using graff images.

During my dogfooding process of creating little art and code projects ("L5 Studies") while working on the L5 language, tonight I added in a basic loadVideo function and created a minimal example showing how to play a video in L5.

Unfortunately, it can only play ogg theora (.ogv) video files, which means mov, mp4, mkv, avi files need to be converted prior to running. This is a limitation that results from the underlying Love2d library architecture as well as licensing issues, as far as I understand. While it is currently a requested feature, it does not look like mp4 and other video codecs will be added to the library too soon: https://github.com/love2d/love/issues/2089

To consider, shipping a little video converter tool or linking to one, just as Processing has a color selector and video recorder.

Processing: video requires a separate library. Can be any codec video. API differs from main Processing.

p5.js: video requires loading via DOM, then some trickery to hide from the screen and then to draw to canvas. not hard, but maybe a pain since a different workflow.

L5: video can only be Ogg Theora ogv file (so videos must be converted prior to being added to the sketch), but loading and playing video is trivial.

was encouraged by @dantescanline to keep going on the quasi-broughlike roguelike i started yesterday while watching the Roguelike Celebration @roguelike_con

i added a bit more functionality, but this is still far from a fun/playable game

Nice studio visit with @computersandblues today, checking out the inkblot library and showing my progress on L5 and jamming with PureData/PlugData.

In the evening, I wanted to make a Captcha font writer type program and it took me a surprisingly long time. I added applyMatrix() functionality to L5. Each key press currently redraws a scrambled matrix so the writing gets re-funkified with each keypress and mousepress.

I solved a huge bug that I have been trying to solve for months, and that moves me much closer to getting ready to put out a pre-alpha version of L5. It relates to what I've been calling the "double setup problem."

Basically, I was calling a user's setup() function twice even though it's only supposed to run once. I did it once to grab sizing defaults, for example from the size() function or fullscreen. Then again inside the love.draw() once in order to draw graphics the first time.

By default, the underlying love2d framework only allows drawing in love.draw() but I am attempting to clone Processing's ability to display graphics in setup as well as in events like mousePressed and keyPressed. Basically what I had to do was majorly modify the love.run() underlying love2d, as well as love.load() and love.draw() and some other things. Finally, I have a solution, by handling canvas states at the correct place and buffer recreation.

Okay, then I found another bug. I could not get fullscreen() to correctly draw graphics to the screen any longer as a result of those changes to the underlying way that love2d functions.It's a testament to its incredible documentation that it didn't dawn on me til now that I should have perhaps studied Love2d's underlying functions for setting the mode because I was getting really stuck on why graphics rendering no longer worked. It turns out that I needed not just to declare setFullscreen but also setMode, so I needed to write this:

love.window.setFullscreen(true, "desktop")
local w, h = love.graphics.getDimensions(display)
love.window.setMode(w, h, {fullscreen = true, fullscreentype = "desktop"})

This to me looks bizarre, like I'm redoing the same thing multiple times, and it's likely a result of my monkeying with the underlying love.run but in any case, all 3 of these lines are needed to be able to draw graphics in setup with fullscreen on. Anyway...

I also made a change from p5.js style implementation of fullscreen(true) to Processing's cleaner/easier: fullscreen() or fullscreen(display_number) which will send to whichever specified monitor (by number of display).

lastly, i tried to figure out a way to allow a user to write code without a setup function but i couldn't figure out how to do that. Beyond this, I think I just want to finish the basic documentation reference site and get it up and then start doing a pre-alpha test with friends. Hopefully can wrap this in the next week or two. Maybe 2 - 10 hours more effort? (though by saying that, it guarantees i'll need double that time!)

In L5 Studies tonight I implemented a first version of a webcam library!

I'm not targetting finishing this by the time I release a pre-alpha of L5 but it is important to me that there is a useful audio library and a camera library that can be used with L5. I have already set up a test of a audio library a month ago and it went ok. Tonight I tried to take on accessing the webcam, which wasn't obvious what to do. I implemented a little webcam library using libjpeg-turbo in C wrapped in a little webcam.lua library that can be used with L5.

still goin'. have been working on the documentation site for the past couple days. i am cleaning up the reference and reviewing missing functions. i kind of wanted to freeze where i'm at and do a little pre-alpha release but i am still trying to pick up and implement more bits of functionality.

tonight i added a few helper conversion functions from p5/processing: boolean(), byte(), char(), float(), hex(), str(), unchar(), unhex().

more on the way.

Ok, from my git log I also added fract, log, norm, pow, sq, sqrt, asin, acos, atan, atan2, randomGaussian, randomSeed.

I experimented with a headless noWindow() mode but basically it just closes the window. It's not really a headless mode for rendering graphics/sketches, so I removed the functionality and will rethink it again in the future if it's possible to implement differently (maybe not).

I also spent a great deal of time tonight cleaning up the L5 documentation site to get it ready for a soft launch. It still feels a bit basic in terms of design, but good to get something up and then build from there. I have 186 reference pages now! But in a fit of reorganization I realize I broke the reference page image paths tonight before bed when I fixed a different path issue. So tomorrow I'll have to write one hell of a regex to fix all of them in their various sub-directories! But overall, things are in a good shape.

I have Openhaus open studios at ZK/U Thursday the 20th and would like to be at a point where I can tell friends about the site/language and have them start playing around and testing and giving feedback then.

spent much of the weekend plugged into my laptop trying to grind through the damn reference pages and fixin' little bugs. Fixed some of the color modes like HSB and HSL which I think should be working.

So now you should be able to work with colors in all of the following ways:

fill(grayscale)
fill(grayscale, alpha)
fill(R, G, B)
fill(R, G, B, alpha)
fill(HSB)
fill(HSL)
fill('HTML color name') or
fill('#3-digit hex code') or
fill('#6-digit hex code') or
fill(color-object-table) or

wow, that's a lot. and that's why debugging took me some time. i had to build in some sanity checks and make sure things worked correctly for:
color(), fill(), background() - which also takes an image file input, and fixed lerp(), lerpColor(), brightness(), lightness(), hue(), alpha(), red(), green(), blue().

In addition, I had to fix all of the documentation pages for each of these, plus many others, test all of the code and produce screenshots to add to the documentation pages. It's a lot.

Still a lot left but i'm on a roll. Will keep grinding through it this week.

oh i am so deep in this hole. i am hand-checking every one of the 200+ reference pages, which can take me 3 to 15 minutes a page or so. For each page, I check my automatically converted p5.js to L5 reference code examples (i have a bash script that built these!). then i alter the description if needed, run all example code and screenshot, and then usually have to hand alter the parameters section as my conversion script didn't successfully build those. Also, for a sizeable minority of these reference pages I realize I left out a parameter or add in an extra error checking code or something. So that expands the time considerably.

Yesterday I checked and edited maybe 20 or so pages and fixed textAlign(), textWrap(), text() (added BASELINE positioning correctly this time), added in error correction to rectMode(), imageMode(), ellipseMode().

With each reference page i generally compare to both p5.js's reference as well as Processing's reference. Well, Cloudflare is down today so I can't check p5.js's site which relies on it. A good reminder to myself NOT to use services like that, I think, as it feels very un-resilient.

Right now I'm testing the L5 website to run without Javascript. I loaded it up in Links and w3 in the terminal, w3 with the img extension actually, and then with @dillo
Looks good.

I am using mkdocs with Material (a static site generator) for rendering the site. It makes many things easier and organized well for a documentation reference site for an API, but it has one big drawback: while the site works without JS, I think the site is larger because of it, 6MB page load, which I'd really like to get down to under 500k but not sure it's possible with this framework! I tried to use Firefox's built-in memory profiler and read its documentation so that I can learn how to cut things down but (argh!) the documentation site for Firefox is down due to a Cloudflare outage.

In the meantime, here's 4 views of the documentation site so far:
1. with w3 in the command line,
2. with netSurf
3. with Dillo (landing page)
4. with Dillo (an example reference page)

One other issue: I've been using webp images to make everything render out in small file sizes, but that doesn't worth on everything! I guess I'll have to have jpg fallback files? I anticipate another bash script to make that happen...

ah, i think i fundamentally misunderstood how the memory profiler and network tools work and what they mean.

i removed loading 2 custom fonts, but that's it. might slim the fonts and put em back.

in the meantime, locally testing the site is about 650kb and i think that when deployed based on gzip compression it might go down a few hundred k more. hopefully i'm understanding this correctly.

fixed a ton of smaller functions and built maybe 60 reference pages total now. there are still 140 page to do! lol. one accomplishment: i fixed multi display support and tested on windows and linux so you can correctly specify which display to run a sketch fullscreen in.

here's my multi monitor installation coded in L5 with the updated library.

the last week was a bit of a blur as it was my last week in my art residency and then some international travel.

On my flight I got back to L5 studies and built "Photocrapier", a photocopy machine emulator with various features like rescanning, jiggling the paper, glitching the paper (i guess jiggling it a ton while scanning?), sliding the paper around, rotation, etc.

I wonder if i should package these things up as little binary files and make them available for download. or at least make my whole L5-studies code in a git repo.

Staying with my parents is a bit like a mini residency. This weekend I worked quite a bit on the reference pages website for L5 and performed a variety of smaller bugfixes to the lang.

* max() and min() can now accept tables
* added exp() function
* deltaTime global var now outputs millis() to match Processing/p5 output
* added resetMatrix() and fixed addMatrix() (and used these to complete the L5 studies project photocrapier)

only 60 of the reference pages (out of about 200ish total) left to do.

I did 10 more pages of the reference and deployed to the (not-so-secret) website. Basically, the reason it takes so long for each reference page is that I use writing the page as a chance to go through and bug fix the actual function I'm referencing. loadTable() and saveTable() were my time stealers today, among other things. for example, I modified saveTable() to deal with both a single table as well as a table of tables. That added...dozens of lines of code, plus debugging.

I also kicked off #DecemberAdventure today after forgetting about this annual tradition and then seeing it pop off on Mastodon here. I participated in the last 2 years and basically liked it so much I continued doing it year round on my log page, so I made an anchor tag to jump to my December Adventure 2025 posts here:

https://leetusman.com/nosebook/log/#december-adventure-2025

#DecemberAdventure #L5

Today was spent working on reference pages and debugging the L5 language library, getting ready for the pre-alpha release. What I worked on today: save() can take an optional filename. I added an alternate data structure for single element tables to saveTable. I updated text() to deal with non-strings. Lots of fixes to events: key detection majorly mproved, fixing delete and function keys, etc reporting. Surgical fix so that keyTyped() reports true at the correct spot. Cleaned up mouseWheel() (no need to report x-value since wheel only scrolls vertically). The biggest update/fix was debugging and correcting the order of mouse handling events. mousePressed() runs as soon as the user clicks the mouse. mouseReleased() runs as soon as the user releases the mouse click. mouseClicked() runs immediately after mouseReleased(). Phew. Worked through a ton of reference pages and it looks like I have a bit under 30 left to do now. At the rate of 10 a day I seem to be on now maybe there are 2 - 3 days left.

churned through a bunch more reference pages, updated the p5.js to L5 conversion script too to help me with that. Thinking I will likely finish the remaining reference pages tomorrow.

#L5 #DecemberAdventure

A BIG DAY FOR ME: I HAVE AN INITIAL ALPHA RELEASE OF L5, which I have been working on for 4 months so far. I also have a nice website up for it with 200 documentation pages!

https://L5lua.org

My next step is to try to get the word out to friends to try out L5, give initial feedback, and see if folks find it useful, want to contribute, etc.

I then need to concentrate on getting some more tutorials done, more/better error() message reporting, just general bug-fixing/refactoring, and add a L5 mode to the Processing IDE application.

#DecemberAdventure #L5

I've slowly been adding tutorials and examples pages, ported from p5.js and Processing (and thanks to a CC-BY-NC-SA license), but adapted for L5.

https://l5lua.org/examples/

https://l5lua.org/tutorials/

It'll take me some time but I plan on adding many more.

#L5 #DecemberAdventure

I'm looking for some suggestions about the https://L5lua.org documentation site for L5.

At first I tried to optimize the site for small page load, focusing on making all images webp files.

Question 1: Is there some html or css only option that allows "falling back" from webp to loading jpg instead if needed for browsers that can't load webp?

Question 2: For example code that shows interaction or animation i'm showing animated gifs. These gifs can be quite large! I want L5 and the website to be able to work on lower-powered and lower-bandwidth computers, even ones without JS. Could my use of gifs be improved?

I'm currently recording the window with SimpleScreenRecorder at low fps as a mp4, then using imagemagick to convert to gif. On a tip, I found ezgif.com converts even smaller. Anyone know their 'recipe'? I would love to automate the process in the command line.

Question 3: Any other tips for how I can make the site work better, particularly for low bandwidth and offline browsing?

Boosts ok! Politely written responses appreciated!