Log In  
Follow
luchak
Audio synthesis: plucked string and delay
by luchak
Simple smoke sim
by luchak
RP-8 1.1 - now with pattern randomizer!
by luchak
SHOW MORE


load #pico_ripples-1
// to load from inside Picotron

A nice little raindrops-on-a-pond type of effect. Though perhaps with more of a shifting rainbow color scheme than most ponds.

Changelog

v1.01: Fixed initial splash height so smaller ripples should be more visible. This, to my eye, adds some pleasing visual variety.

P#143450 2024-03-17 06:42 ( Edited 2024-03-17 19:09)

SHOW MORE


load #picotron_smoke-0
// to load from inside Picotron

Yup, it's a smoke simulation toy for Picotron! Use your mouse to play. Should run at a nice steady 60fps after the first ~1s.

Uses userdata to make pressure projection steps almost free. That's great, since those steps were super-expensive in the PICO-8 version! Unfortunately, advection still has to be done with loops in userspace Lua code, and so that part didn't really see any speed increases, and is the new bottleneck.

There might still be some rendering tricks to speed this up, and I need to see whether some tricks I gave up on in the PICO-8 sim, like a MAC grid or vorticity confinement, might be viable here. Unfortunately higher-order interpolation, which I know would help a lot, is probably not happening without major new userdata features.

P#143262 2024-03-16 05:20

SHOW MORE


load #userdata_tunnel-0
// to load from inside Picotron

Here's a simple tunnel effect I did to test out doing pixel effects with userdata. Not super inspired, but it does run at 60fps at full resolution!

P#143044 2024-03-15 02:39

SHOW MORE

I've been thinking about ways to execute fast pixel effects on Picotron, and so I'm looking for ways to perform the effect entirely in userdata-land, and display the results as sprites. I've tried a few approaches, none of which seems to be quite ideal.

  1. Do math on f64 userdata, then render that to the screen. This gets me fast math operations, but of course the rendering result is completely garbled. I suppose some pack-ints-into-floats type nonsense could be attempted? But with just basic arithmetic ops this seems like a bad time.

  2. Do math on f64 userdata, then cast that to u8 in a loop. This is a lot of time spend calling getters/setters in a loop, and may not be any better than pset, not sure.

  3. Do math on integer userdata, then cast to u8 using the userdata:convert() method and display that. This would work fine if I could figure out how to get fast fixed-point going. Unfortunately, div and mod are slow, and shifts don't seem to work.

I think my preferred resolution would be to allow convert() to go from f64 to u8, but anything that allows any kind of math with fractional quantities, either floating-point or fixed-point, would be great. Drawing f64 userdata with spr with implicit casting would be great too. Just trying to avoid explicit loops to get to u8....

Or perhaps there's some other way to get what I want with what's in Picotron already and I've just missed it. Not quite sure what's doable with the 10-15ish ops/pixel this would get best case but I'm sure something neat can happen.

Other requests:

  • I would love to have min/max/abs or similar "sharp" functions available for userdata, to allow masking off out-of-range data or other similar conditional-ish use cases.

  • trig would be amazing but I assume that's probably off-limits, or at least would be quite expensive.

  • Even more amazing would be the ability to index userdata with userdata (and at this point built-in trig is probably not necessary)
P#143013 2024-03-14 23:31 ( Edited 2024-03-15 07:42)

SHOW MORE

I'm trying to make a classic synth pluck sound: a couple of detuned saw oscillators, plus a resonant lowpass filter that quickly opens up when a note starts, then closes back down. Unfortunately, I can't quite figure it out. I have an ADSR envelope modulating the filter cutoff, but since the envelope has a positive polarity and higher lowpass knob values = lower frequencies, the effect is exactly the opposite of what I want: the filter immediately closes down on note onset, then more slowly opens back up.

Is there any way to flip the sign of this modulation? Am I thinking about this the wrong way?

P#142951 2024-03-14 20:25 ( Edited 2024-03-15 06:51)

SHOW MORE

This is a tool to allow both time-domain and frequency-domain editing of the new custom sfx waveforms.

Cart #wave_designer-1 | 2024-02-29 | Code ▽ | Embed ▽ | No License
10

Controls:

  • Mouse: click and drag to edit the wave directly (green line), harmonic magnitudes (blue bars in the middle), or harmonic phases (maroon/lavender bars on the bottom). Or click the play button to toggle preview playback, which plays sfx 1 on loop. The waveform is stored in sfx 0.
  • Left/right arrow: switch between a bunch of preset waves.

Features:

  • Time and frequency domain editing, always kept in sync.
  • Mouse drags are interpolated so fast drags work as expected.
  • sfx 0 is written to the clipboard after every edit so you can use your creations elsewhere. You may need to press ctrl-c/cmd-c on the web for this to work; on desktop it should be automatic.

Limitations:

  • No undo.
  • You cannot load waveforms from outside sources, or waves previously created in this tool.
  • If you want to change the preview sound (sfx 1) you have to edit it in the tracker. You can replace sfx 1 with some other looping sfx if you want, it just needs to use wavetable instrument 0.

I may work on resolving some of these limitations eventually, or adding other features. Feedback is welcome!

P#142178 2024-02-29 04:59 ( Edited 2024-02-29 06:02)

SHOW MORE

Want sfx fast? sfxp can help! Adjust the sliders for new sounds, or click "random" for instant inspiration.

Cart #sfxp-1 | 2023-09-21 | Code ▽ | Embed ▽ | No License
17

Controls:

  • click/drag sliders and buttons
  • right click the random button to mutate the current sound instead of fully randomizing it
  • z/x to replay the current sound
  • left arrow to undo
  • right arrow to redo

You can export either to sfxp format (to share, or to edit more later) or to PICO-8 sfx format (to paste into the PICO-8 sfx editor and use in your PICO-8 games). Export works via the clipboard, which can be kind of weird on the web version of PICO-8. I highly recommend running sfxp on desktop PICO-8 if you have it.

You can also find sfxp on Itch.

Made for the PICO-1K Jam.

Update 2023-09-20: undo bug fixed and redo added.

P#134424 2023-09-16 08:24 ( Edited 2023-09-21 02:13)

SHOW MORE

I am pleased to announce Questionable PICO-8 Audio (QPA), a compressed audio format for PICO-8.

(Compatibility note: if you encoded any QPA files before 2023-09-07, please see the Changes section below.)

DON'T YOU LECTURE ME WITH YOUR 30K PICO-8 CART

Oh, but I will!

Cart #qpa_demo-0 | 2023-08-31 | Code ▽ | Embed ▽ | No License
21

Your song is synced with the clipboard - you can copy your songs out to text files (or this thread!) and paste song strings back in to the cart. You can right-click samples to preview them, and you can right-click the play button to skip the intro sample. Numeric modifiers come before the thing they modify. Hopefully you can figure out the rest!

Copy/paste is a little annoying on the web player, and PCM audio can also be unreliable on the web, so consider trying this cart on desktop PICO-8 if you have it.

You can also check out this song by me:

7⬆️✽0⬆️✽✽✽⬇️✽⬆️✽3⬇️▶▤웃⬆️7◀0⬆️ˇˇ♪♪♪□∧7⬆️∧7⬇️7⬇️∧

Or this much better song by @packbat:

➡️▶▒7◀▶…6◀░▶▒7◀▶…6◀★▶▒7◀▶…6◀█▶😐7◀▶⁘3◀⬆️▶⁘3◀⬇️▶▒7◀▶…6◀░▶▒7◀▶…6◀★▶▒7◀▶…6◀⬆️★⬇️⬇️⬇️⬇️▶★7◀▶▥▥⬆️2◀∧

(The reference, if you're not familiar)

Why QPA?

Because you want to put fun sound samples in your carts, but don't want to use too many tokens or too much space!

QPA provides three main benefits:

  • Tiny decoder. A fully-featured decoder that reads from strings, does quality-level detection, and rejects invalid files is 228 tokens. A minimal decoder is just 175 tokens.
  • Reasonable quality at very low data rates. QPA encodes mostly-intelligible speech at just 1.14 bits/sample (788 bytes/second) - or completely-intelligible speech, as well as usable instrument samples, at twice that rate.
  • Faster-than-realtime decoding speed. Precise speed depends on the decoder implementation, but around 4x realtime is a reasonable expectation for a token-efficient decoder.

As for how this works in practice: the demo cart PNG is just under 32k. It contains about 18k of samples (split 17k in sprite/map/etc. space, 1k in code) and 2k of other compressed code; the rest of the space is taken up by the label and other overhead. That 18k of sample data stores almost 14 seconds of audio. The samples are stored at a variety of quality levels, but more audio could have been included at lower quality, or higher-quality audio could have been used in exchange for more space. There also could have been a lot more audio if I hadn't tried to keep the cart around 30k - there's another 12k of compressed code space that could have been filled with QPA data strings!

What Is QPA?

QPA is an adaptation of the Quite OK Audio Format (QOA) to PICO-8's constraints. As such, it is a lossy, constant-bitrate format, in which the decoder attempts to predict future sample values one at a time, and compressed files store approximate differences between these predictions and the real sample values. To better understand how this scheme works, I suggest reading this introduction to QOA. QPA changes some details, but the basic structure remains the same.

So what changed to put the PICO in QPA?

  • Multiple quality levels. QPA offers a choice of compression ratios so you can optimize your valuable cart space. The highest compression ratio (7x) is noisy, but is still suitable for some speech, percussion, and sound effects. The lowest two compression ratios (2.25x and 1.75x) are approximately transparent for most sounds.
  • Minimal metadata. The only pieces of metadata in a QPA file are a magic number and a sample count. QPA includes no sample rate information, and does not support multi-channel audio (PICO-8 is mono only) or seeking to arbitrary points in a file (PICO-8 carts are small). This makes the decoder simpler.
  • 8-bit audio only. QPA assumes an 8-bit output resolution, and is tuned to avoid single-bit output noise.
  • PICO-8 numbers. Almost all arithmetic works on PICO-8's native q16.16 number representation, slices are now 32 bits to match PICO-8's word size, and the format is little-endian instead of big-endian.
  • Smarter encoder. At PICO-8's low sample rate, it is critical to avoid high-frequency noise, so the encoder includes some light perceptual tuning to push noise into lower frequencies. It also expands QOA's use of exhaustive search for parameter selection, making it easier to incorporate new encoding strategies in the future.

Resources

To use QPA in your own carts, please check out the following resources:

  • @bikibird's Defy encoder and Defy cart. You can use these to encode and play back your own audio files.
  • The QPA utility cart. This cart makes it easy to convert QPA files to strings, and contains low-token decoding functions to copy into your own carts.
  • The QPA repository on Github. Here you can find more documentation, a format spec, and a CLI encoder/decoder for QPA files. (CLI requires Node and NPM.)

Changes

On 2023-09-06 and 2023-09-07, new versions of all tools, code, and encoders were released to fix problems identified by Packbat. These new versions broke compatibility with earlier versions - if you switch to the new code, please keep in mind that you will have to re-encode your files. Hopefully this is a one-time only sort of change.

Future Work

I'd like to focus on getting better quality at approximately 1 bit/sample. It's possible that VBR or variable sample rate enhancements to QPA could get there, or it might be necessary to explore frequency-domain techniques ... although that might bode poorly for keeping decoder token count low.

But first - I think it's time to use QPA to build a tracker. No promises on release date!

Acknowledgements

  • Dominic Szablewski for the QOA audio format
  • @packbat for discussions and a whole lot of listening tests
  • @bikibird for Defy and being willing to integrate QPA
  • ferris for providing design feedback and pointers for future work
  • MissMouse for the demo cart suggestion
  • @NerdyTeachers and @Heracleum for help with the cookie/coffee test
  • The entire #music-sfx channel on the Discord for discussions and for putting up with a whole lot of QPA chatter
P#133755 2023-08-31 01:00 ( Edited 2023-09-07 20:50)

SHOW MORE

Would you like to play the piano ... in PICO-8?

Cart #sample_piano-0 | 2023-08-05 | Code ▽ | Embed ▽ | No License
9

Well, I can't imagine why, but there you go. Use the tracker keys to play. It's polyphonic.

If you want to change the sample, you can convert a .WAV file to any of the QPA formats - and only the QPA formats - supported by this WIP tool: https://luchak.github.io/defy/ . Then drag and drop the resulting file on the running cart and play away. This will also save the new sample to the cart using cstore() so you can make new carts for new instruments! That URL has been updated with some format improvements, so it won't work here any more until I update these carts.

Usual caveats apply about PCM output not always working well on the web.

For this use case there's basically no reason not to use 3.2 bit QPA, the highest QPA quality, since the file will be truncated at ~32k samples (about 6 seconds) due to table indexing limits and my laziness, and at that length 3.2 bits fits easily in a cart. But for future use cases perhaps the 2.3 bit format will have a purpose, and maybe even the 1.1 bit...

Yes, the WIP conversion tool is a fork of @bikibird's Defy. There's a PR out to merge it into the official version!

And if you're curious, QPA is closely derived from https://qoaformat.org/ and currently stands for Questionable PICO-8 Audio. If you think it might stand for something else let me know, you could be correct.

P#132750 2023-08-05 05:43 ( Edited 2023-08-15 02:43)

SHOW MORE

This cart is a barebones Forth implementation in 279 tokens. It could be smaller, it could be more usable, but I haven't really touched it in weeks, so here you go. Probably full of bugs.

Features

  • eval() function
  • Interpret and compile modes - extend syntax in Forth!
  • if/then (implemented in Forth)
  • A few useful comments, including some commented-out utility functions and basic smoke test.

Non-features / shortcomings

  • else (you can add this in Forth)
  • Arithmetic (you can add this for 11 tokens per binop, or 9 tokens if you're willing to use valid Lua identifiers as operator names)
  • Looping (you can probably add this for the cost of a few arithmetic/comparison operators, then add the syntax in Forth for no token cost)
  • Passing args or returning values when calling Lua functions from Forth (depending on how fancy you want to get, probably takes 20-50 tokens for a reasonable wrapper)
  • [ and ] are spelled _lb and _rb for some reason.
  • The inner interpreter works in a non-standard way that will make it hard to call arbitrary Forth from Lua outside of eval - this is probably worth rethinking.

A few ways to make it smaller

  • A few functions could probably be moved from Lua to the initial Forth definitions as-is, although since : and ; depend on them this will be a bit messy.
  • With the right Forth/Lua binding util, even more functions could probably be moved.
  • With some internal representation changes, even _interp and eval could probably be (mostly) boostrapped.

Anyway, enjoy. This may not be useful for very much, but the question of how little material you need to bootstrap a reasonable eval is still kind of a fun question.

Cart #bbforth-1 | 2023-07-11 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
5

P#131852 2023-07-11 21:17 ( Edited 2023-07-11 21:23)

SHOW MORE

Cart #raccoon_ball-1 | 2023-06-04 | Code ▽ | Embed ▽ | No License
30

Does what it says on the box.

(updated to fix a major oversight: now it bounces)

Photo by Toan Chu

P#130491 2023-06-04 06:02 ( Edited 2023-06-05 21:46)

SHOW MORE

Copy/paste is super cumbersome when using web exports on Mac. It appears that to reliably copy, I have to press ctrl-C and then cmd-C after text is written to the clipboard, and to get pastes to work I have to press cmd-V and then ctrl-V for PICO-8 to pick up the paste.

Is there a better way to do this? If not, can Mac exports be updated to only need cmd-C and cmd-V? I'd love to cut down the instructions on Tiny Drops...

It looks like this also may be affecting folks using the EDU edition: https://www.lexaloffle.com/bbs/?tid=51921

P#130011 2023-05-22 05:29 ( Edited 2023-05-22 05:58)

SHOW MORE

Bounce tiny drops that fall from the sky to make music! This began as a 500-character cart for TweetTweetJam 8. Or check this cart out on Itch!

Cart #tiny_drops-3 | 2023-05-22 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
14

The latest version adds many more editing features, as well as save/load and audio export.

Controls

  • Click and drag the mouse to draw lines, or to move line endpoints.
  • Z/X deletes a line. If your mouse is over a line endpoint, it'll delete that line, otherwise it'll delete the newest line.
  • Left/right changes line sounds. If your mouse is over a line endpoint, it'll change that line's sound, otherwise it'll change the sound for new lines.
  • Up/down changes the interval between drops.
  • E to start/stop audio export.
  • S to save to the clipboard. In the web version, you'll need to press ctrl-C after this to complete the copy. (Or, on a Mac, ctrl-C so PICO-8 notices and then cmd-C.)
  • R to restore from the clipboard.
  • N to get a new empty scene.
  • When you paste a saved scene into PICO-8, Tiny Drops will automatically load it. In the web version on Mac, you'll need to press cmd-V to paste and then ctrl-V to get PICO-8 to notice the paste.

Known issues

  • Can get slow if you trap too many drops on the screen.
  • When you start to create a line, you may hear "phantom" bounces until you start dragging the mouse. (Happens with 0-length lines.)

500-Character Jam Version

This version has no save/load, no audio export, and no concept of line hovering or editing existing lines:

Cart #tiny_drops-0 | 2023-05-13 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
14

P#129682 2023-05-13 00:11 ( Edited 2023-05-22 05:13)

SHOW MORE

Cart #boundary_peaks_tweetcart-0 | 2023-05-10 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
9

Just a small tweetcart.

P#129585 2023-05-10 02:02 ( Edited 2023-05-10 02:03)

SHOW MORE

The following code block prints only the number 4, though I would expect it to print 2, 3, and 4.

do
 if (false) if (true) print(1)
 print(2)
 print(3)
end
print(4)

Only the outer if has this property, the inner if's scoping is fine. Similar behavior happens without the do block, I just included it to demonstrate the interaction of this behavior with "normal" Lua scopes.

P#129196 2023-04-30 19:56 ( Edited 2023-04-30 19:59)

SHOW MORE

Here's yet another piece of simple data compression code:

Cart #simple_lz-0 | 2023-04-09 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
4

I wrote this for a (hopefully) upcoming player cart for RP-8 songs, in order to be able to pack as much RP-8 song data as possible into the spritesheet/map/sfx/music area of the cart. The compression technique is basically LZSS, with a couple of small changes / enhancements:

  • The code supports strings longer than 32kB - it will break them into 32kB blocks for compression and reassemble those blocks after decompression.
  • Literals are move-to-front encoded.
  • Match offsets, match lengths, and MTF literals are encoded using Elias gamma coding. The lowest N bits (N is a separately tunable parameter for offsets and literals, N is fixed to 0 for lengths) are encoded as usual, the remaining high-order bits are Elias gamma encoded.

The code works correctly on every string I've tested it on (so far) ... but I am less certain about whether there are efficiency bugs or not. The maximum supported match length is 1027.

If you would like to use this code, I suggest the following process:

  1. Find some test data, and copy it into this cart.
  2. Play around with different values of OFFB and MTFB to see which produce the smallest files. Generally, smaller values of OFFB will be better for smaller amounts of compressed data, larger values will be better for larger amounts of compressed data. 3 seems to be a good value for MTFB for most strings I have tried, but maybe you will find a case where a different value is better.
  3. Modify this cart to save out your compressed data in whatever way makes sense to you.
  4. Copy the functions pf_make_r, pf_decompress_block, and decompress into whatever cart needs to read the compressed data. You may want to substitute the various constants at the top of this cart with their literal tuned values at this time to save tokens. If you do this, the decompression code will probably clock in at a little over 250 tokens. I'm sure it's possible to make it much shorter.

At some point I may play around with having the compressor try out different OFFB and MTFB values on its own, or have it do some form of optimal LZ parsing. Basically, experimenting with different ways to trade slower compression times for slightly better compression ratios. Or perhaps I should just write a Pico-8 decompressor for upkr.

And here's a 0-clause BSD license for this code so you can go ahead and use it without worrying about the CC attribution or share-alike provisions if you want:

Permission to use, copy, modify, and/or distribute this software for
any purpose with or without fee is hereby granted.

THE SOFTWARE IS PROVIDED “AS IS” AND THE AUTHOR DISCLAIMS ALL
WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE
FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY
DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
P#128358 2023-04-09 17:36 ( Edited 2023-04-09 18:37)

SHOW MORE

This code uses 11% CPU according to Pico-8, but if I delete the v[0]=1 lines in the if false block it uses 7% CPU:

v={}
::_::
if false then
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
 v[0]=1
end
for i=0,1023 do
 v[0]=5
 v[0]=5
 v[0]=5
 v[0]=5
end
flip()
goto _

Other observations:

  • If I put the v[0]=1 lines in a for loop with a huge iteration count this code uses 7% CPU. (No bug.)
  • If I put this code into _update() or _draw() it uses 7% CPU. (No bug.)
  • Adding / removing v[0]=5 lines bumps CPU by roughly 3% per line.
  • Replacing v[0] with v[1] makes no difference.
  • Pico-8 does act on this CPU info, the contents of the if false block will affect whether Pico-8 visibly stutters if I add draw code and the non-executing lines push CPU over 100%.
  • If I add a table u and do u[0]=5 in the second loop the bug still happens, no change in behavior.
  • The number of top loop v[0]=1 assignments only seems to matter between about 8 and 16 - the CPU usage seems to saturate outside of that range.
  • If I make v local, this behavior persists, but it seems to take more v[0]=1 lines to trigger it.
  • I can produce this behavior on both 0.2.5e and 0.2.5c, @freds72 reports also being able to repro on 0.2.4c

Since this only happens outside of _update() (I think??) I assume this isn't a big issue for most carts, but for tweetcarts etc. it does seem fairly important.

P#125085 2023-01-31 19:30 ( Edited 2023-01-31 20:16)

SHOW MORE

I've already posted this on the Discord and a couple other places, but, well, why not post it here too? Randomly generated snowflakes for the season.

Cart #snowflake_generator_3d-0 | 2022-12-24 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
12

P#122953 2022-12-24 21:07 ( Edited 2022-12-24 21:08)

SHOW MORE

This behavior feels possibly intentional, but I thought I'd check here just in case. If you run RP-8 with load #rp8, on loading carts, RP-8 gives the message unknown extcmd: set_title. If you ask it to open its folder with extcmd("folder"), it fails with a similar message. Both commands work fine if I save the cart to a .p8 and immediately re-load it. This is on 0.2.5c.

It'd be nice if folks could use load #rp8 to run RP-8 - even if this functionality doesn't end up enabled from Splore, perhaps it could work when loading carts by ID from the CLI? Also, is there some way to work around this and avoid showing the error message if the extcmd call isn't going to work?

At this point I'm wondering if I'll need to just point to Itch as the canonical download source for folks to get reliable results. That wouldn't be the end of the world, but offering a load #rp8 alternative would sure be nice!

P#117735 2022-09-20 22:19 ( Edited 2022-09-21 19:15)

SHOW MORE

I've been working on a song in RP-8, and I've recently modified RP-8 to not just write song files to the clipboard, but also to timestamped save files on the desktop. After a long session of working on the song, I tried to save, and got a message about there being too many printh files.

I wouldn't have lost too much work - the whole reason I have this many files is that I've been checkpointing frequently - and I was able to get the data out of the clipboard, but it was still frustrating. This was a very long session, Pico-8 had probably been open for 12 hours or more while I'd been working off and on. Creating so many save files would certainly be a problem if Pico-8 had only been open for a few minutes, but over 12 hours I feel like it's not unreasonable?

I'd love for Pico-8 to reset its number of files / amount of data limits after some period of time, even an hour or two would be fine for my purposes.

I'd imagine this isn't super high prio, but it would be very nice. As I get closer to releasing RP-8 I'm starting to think more about awkward situations and edge cases I'll have to explain in the docs, and this would certainly be one of them. The really awkward thing about this one is that it undermines trust (since the user feels like they're losing work), and it's somewhat difficult to get around in a nice-feeling way...

I guess I could have a save counter and add some sort of visual warning and/or exit when you've created the last save possible in a session? Still awkward but better than nothing.

P#114478 2022-07-17 19:37 ( Edited 2022-07-17 19:38)

View Older Posts
Follow Lexaloffle:          
Generated 2024-03-19 08:15:55 | 0.161s | Q:79