zep

zep, 7 months ago

// especially large groups of ips spamming search fields with a seemingly random dictionary of search terms. WHY?

zep, 7 months ago

@Felice aha! That sounds plausible ~ thanks for putting my mind at rest :}

zep, 7 months ago

@frew the Bard crawler was using your service's search feature? That seems very aggressive!
No useragent though -- just being curl'ed (and the ip address ranges don't belong to anyone obvious), so probably just spammers.

zep, 7 months ago

//
The changes can be in realtime because the current theme settings are stored in a lightweight ram disk file (/ram/system/theme.pod) that the theme editor app is allowed to overwrite every frame, and the desktop wallpaper app (also p64 cartridge, like everything else) can cheaply read those changes.

Apps can alternatively send each other messages addressed by process id, but writing to /ram is a good way to publicly share data with any other process who might care to poll for changes.

zep, 7 months ago

@rollbrettklauen It's a new (WIP) thing! picotron.net

zep, 7 months ago

@Liquidream yes, exactly. Although, there will need to be some restrictions on access from something run straight out of splore, so not yet sure how useful it will be in that context :D

zep, 7 months ago

@rollbrettklauen it's basically the same model as pico-8: the c runtime/lua interp is compiled to wasm, and exported cartridges are that runtime packaged with the cartridge data.

And yeah, interpreted Lua is really fine for a lot of things! ~ with a bit of care, enforced by picotron's "cpu" limits >:-)

zep, 7 months ago

@waporwave it's a different cafe, pico pico was never that busy! Oh, that's too bad. We've been closed since 2020, but had quite unstable opening hours before that (depending on how lexaloffle was going :D )

zep, 7 months ago

@jamesgecko being simple to generate is definitely a consideration -- there is a hexadecimal option for writing binary files too if base64 is annoying.

The files inside can be quite complex though (lz4 encoded object data of varying forms), so being able to reliably /read/ it is a different matter.

zep, 7 months ago

@fsouchu yep -- the working cartridge folder can be mounted as a regular folder on host (> mount /ram/cart /foo), exposing everything in foo as regular files that can be edited with external editors.

zep, 7 months ago

@Felice Unfortunately resources are normally already compressed (rle + lz4), so the single byte change problem still happens regardless of encoding.

Resource files are normally quite small though -- a 256x16x16 spritebank is ~24k compressed and so on average 12k would be stored in a diff for a random pixel change (expanded to 16k in base64, or 24k in hex).

zep, 7 months ago

@waporwave you didn't speak too soon, it is indeed currently impossible! But I have a possible plan for that later if it seems needed: an envelope type that maps pitch or volume to an output value; so it would be possible to get e.g. FM OSC that is only audible on a note or volume range.

zep, 7 months ago

@waporwave There is definitely a lot of overlap between env types -- e.g. I also kinda want to be able to control attack on the amp & frequency etc. for either.

LFO is supposed to be the one "simple" go-to option for a lot of common situations, but I think the answer will just be information hiding (a fold-out section with advanced knobs and loop points etc)

zep, 7 months ago

@jlamores So far there's just a bit on each knob that means "select randomly in this range", but it is already quite useful for getting things like subtle tonal variation. It works for pitch too of course, but would be nice to have something like a scale mask. hrrrm.

zep, 7 months ago

@waporwave I went down a bit of a rabbithole with this; thanks for your thoughts :)
If you're curious, here's an updated version I like much better that has a unified envelope header and also pitch controlled parameters (+ volume,x,y-controlled parameters, where x & y are general purpose meta-parameters controllable via tracker commands).

https://www.lexaloffle.com/dl/docs/picotron_synth.html

zep, 7 months ago

@luchak That's extremely interesting, thanks! It would be nice to offer something like this out of the box and fits in nicely with the current shape parameter ("elbow" -- I should rename that). I also really like the idea of allowing wavetables to be used as shaping look-up tables.

zep, 7 months ago

@luchak Ha -- that's a nice way to put it. I'm putting aliasing closer to the feature (character, performance) end of the continuum:

• lerp between wave samples / not between wavetable entries
• no cutoff parameters or eq
• lerp between envelope points (but bits reserved for alt interpolation in future)

There will be some wiggle room though if it turns out there are common gripes that are worth spending cpu / complexity on.

zep, 7 months ago

@Liquidream Here you go:
https://www.lexaloffle.com/dl/docs/picotron_synth.html

// The other manuals will get that feature next time they are updated :)

zep, 7 months ago

@Farbs Maybe too late to be useful but..
I think simply collecting every frame isn't a bad strategy; minimize worst-case spikes at the cost of perf over time.

PICO-8 uses the standard 5.2 incremental collector lua_gc(L, LUA_GCSTEP, 200), and falls back to a full collects if the incremental can't keep up (i.e. keeps hitting the 2MB max allocation threshold)

I tried an adaptive step amount, but that causes all kinds of chaotic behavior for carts with irregular allocation patterns.