Was listening to some old compositions of mine and realized that I had a nice little instrument that hadn't made it into the midi library!
For the demo, I used the same trick I used then, and split the melody across two separate SFX so the tails of each note could ring out while the next note played. Bit of a faff to do, but it produces a very good effect.
As noted in the cart, at least to me, it still sounds good and has a harp-ish vibe with various combinations of Buzz, Dampen, and Reverb; Detune doesn't work because the bulk of the SFX is the triangle wave.
So, let's say you're building a synthesizer using the serial PCM output and you want a filter. What do?
Well, what I did was follow a link @luchak posted a while ago in the Discord to this SVF filter design by Andrew Simper, Laurent de Soras, and Steffan Diedrichsen. And then get blasted with noise, because a design that works great with double-precision floating-point numbers is not so great with 16b.16b fixed-point PICO-8 numbers.
Now, I'm not good enough at math to prove mathematically that this is stable, but I'm good enough at hacking together testing code to feel confident that, as long as:
- the signal being fed into the filter remains in the range -1 to 1,
- the resonance remains in the range 0 to 1, and
- the cutoff remains in the range 0 to 2756.25 (the Nyquist frequency for PICO-8's 5512.5 Hz PCM output)
...this should produce an output that remains within the range -3 to 3 -3.5 to 3.5 and is usable.
--this is the initialization section; do it outside the sample calculation loop local f_low,f_band=0,0 --these are the filter parameters --I haven't tested changing them while the filter is running but that's what I plan to do, so, here's hoping. local res=0 to 1 local freq=-2.0*sin(cutoff frequency/22050)--sin( 0.5 * cutoff frequency/(2*sampling frequency) ) --after you set freq and res, these two are derived local drive=max(0,.05*res-.0125)--0 for res<0.25, increase linearly to 0.0375 for res=1 local damp=min(2.0*(1.0 - res^0.25), min(2.0, 2.0/freq - freq*0.5)) -- -- -- do the calculations here to generate osc, your signal to be filtered -- -- --2x oversampled filter local f_notch=osc-damp*f_band f_low+=freq*f_band local f_high=f_notch-f_low f_band-=drive*f_band*f_band*f_band--distortion f_band+=freq*f_high--filter local out=(f_notch or f_low or f_high or f_band)>>1--half here... f_notch=osc-damp*f_band f_low+=freq*f_band f_high=f_notch-f_low f_band-=drive*f_band*f_band*f_band--distortion f_band+=freq*f_high--filter out+=(f_notch or f_low or f_high or f_band)>>1--...and half here |
To show it off, here's my current very incomplete version of a button keyboard cart. Same keyboard keys as you use for SFX editor note entry; left-right arrows to change octave. This filter is set up with a cutoff frequency of A5 (880 Hz) and a resonance of 1.
I think ever since @carlc27843's Impossible Mission R.T. cart came out, people have been wondering if they could make background music for a cart using PCM synthesis. carlc27843's Emulated Amstrad CPC Chiptunes post discusses using its engine that way, @luchak has had to let people know that the RP-8 groovebox can't be used that way ... folks are curious.
I don't know a lot about digital audio synthesis, but from the conversations that have happened in the PICO-8 Discord, it sounds like there's roughly three sides to the equation:
Cost
- How many tokens and bytes are cart designers willing to give up to the soundtrack? @bikibird's Speako8 Speech Synthesis Library is under a thousand tokens - is that a good target?
- What percentage of PICO-8's CPU budget? Four voices with 25% CPU seems possible in a few different ways, but is that too much to give up to background music?
- How much memory, Lua and addressable? Most forms of synthesis probably run out of CPU first, but this could be a question if you're making a lot of lookup tables.
Usability
- How do you program tracks? Does it use PICO-8's built-in tracker with its own sound sources? Does it have a custom editor?
- How do you add them to your games? Presumably you copy a bunch of code into memory and add a function or coroutine to your game loop, but where and how do you store tracks?
Quality
- How many simultaneous voices? PICO-8's built-in tracker allows 4 simultaneous sounds, but most game BGM is built with 2 or 3.
- What effects can you add? Reverb is probably out of budget, but echo is possible (if memory-expensive), and distortion and compression are totally feasible. As are filters - certainly low pass, high pass, band pass, and notch.
- What kind of synth do you make?
It's definitely possible to make:
- Simple waveform synthesis (e.g. sine, square/pulse, sawtooth, triangle)
- FM synthesis
- Sample-based synthesis (very storage-expensive!)
- Wavetable synthesis (the original PPG Wave synthesizers only had 8-bit samples! but this is also storage-expensive, if less than sample-based synthesis)
- Subtractive synthesis with any of the above as oscillators
...but the more processing you do, the more sound design tools you add, the more expensive your result will be.
Conclusion?
I don't really have one? But I think it would be good to have a space on the official forums where people who are thinking about this stuff can talk about it. I haven't made a lot of games, so I don't know what what a good budget would be for game developers ... and I haven't made much music with much outside PICO-8 and, like, an actual piano, so I don't know what a good synthesizer would be for game soundtrack composers. And I know barely anything about software synthesis, so I don't know what's possible, what's easy, what's hard, or why my low-pass filter makes hell noises if I give it the wrong parameters.
I think it would be cool to share knowledge, and the forums seems like the best place to do it.
I know a lot of people have posted functions for drawing cubic bezier curves, but I'm tossing my own into the pot because why not. Just skimming threads, it feels like most people use pset() to draw them pixel by pixel; this one uses line() to draw them segment by segment.
Some animated gifs, because they're fun:
To save you digging into the cart, here's the two versions of the algorithm I'd recommend, based on my testing. If you want to see how fast they run, there's a pause menu item in the code that draws sets of 5000 random bezier curves with a bunch of different algorithm parameters in two sizes - 16-pixel square bounding box and 128-pixel square bounding box - and adds up the total CPU needed at 60 FPS.
-
The polynomial coefficients function. All of the other code uses this.
--coefficient fn (39 tokens, shared by all) function cubic_coef(p0,p1,p2,p3) --coefs for cubic bezier return p0, -3*p0+3*p1, 3*p0-6*p1+3*p2, -p0+3*p1-3*p2+p3 end
-
Fixed-segments option. This one has 16 segments, which (a) is convenient numerically and (b) doesn't get too messy for small curves but doesn't look too chunky for large ones. From the benchmark, you could draw 220 big curves or 250 small curves in one 60 FPS frame.
--fixed 16 points (+80 tokens) function cbez_16(x0,y0,x1,y1,x2,y2,x3,y3) --cubic bez, dt predefined --precalculate polynomial coefs local a0,a1,a2,a3=cubic_coef(x0,x1,x2,x3) local b0,b1,b2,b3=cubic_coef(y0,y1,y2,y3) --set endpoint for first segment -- by poking ram with coords poke2(0x5f3c,x0) poke2(0x5f3e,y0) -- --optional: clear error to avoid bugs -- poke(0x5f35,0)--4 tokens for t=0x.1,1,0x.1 do line( a0+t*(a1+t*(a2+t*a3)), b0+t*(b1+t*(b2+t*b3)) ) end end
-
Adaptive-segments option. This one is a bit faster for small curves - like 320/frame - but much slower for large curves - like 110/frame.
--recursive, fixed 2px precision -- (+186 tokens) function cbez_recurs2(x0,y0,x1,y1,x2,y2,x3,y3) --cubic bez, adaptive points --precalculate polynomial coefs local a0,a1,a2,a3=cubic_coef(x0,x1,x2,x3) local b0,b1,b2,b3=cubic_coef(y0,y1,y2,y3) --set endpoint for first segment -- by poking ram with coords poke2(0x5f3c,x0) poke2(0x5f3e,y0) -- --optional: clear error to avoid bugs -- poke(0x5f35,0)--4 tokens --poly function local function xy(t) return a0+t*(a1+t*(a2+t*a3)), b0+t*(b1+t*(b2+t*b3)) end --subdividing draw function local function crawl(tp,tn,xp,xn,yp,yn) --draw curve recursively to tn local tm=(tp+tn)>>1 local xm,ym=xy(tm) --luchak fast abs local xerr,yerr=(xp+xn)>>1,(yp+yn)>>1 xerr-=xm yerr-=ym if xerr^^(xerr>>31)>2 or yerr^^(yerr>>31)>2 then --not precise enough; recurse crawl(tp,tm,xp,xm,yp,ym) crawl(tm,tn,xm,xn,ym,yn) else --close enough; draw line(xm,ym) line(xn,yn) end end local x5,y5=xy(.5) crawl(0,.5,x0,x5,y0,y5) crawl(.5,1,x5,x3,y5,y3) end
(Shoutout to @luchak, from whom I swiped this fast abs function - I think it ended up reducing runtime by about 3%, which might not be worth it but hey.)
There's probably ways to optimize these further that I haven't thought of - I'm just not very good at that - so please feel free to sound off with any suggestions.
Also, I tried to make good comments, but let me know if anything's unclear.
Out of curiosity, I was testing to confirm that the new limit on length of audio recordings via extcmd("audio_rec") was per-instance and not per-session ... and discovered that the length of recording I got was 2 minutes instead of the 8 minutes listed in the v0.2.5d changelog.
An 8-minute limit makes sense to me but a 2-minute one doesn't, so I'm assuming this is an error of some sort.
edit: confirmed fixed in v0.2.5g.
Taking a crack today at building drum kit SFX - I've labeled this one as a "High Tom", but if you play it on a lower note than C2, I think it'll probably serve for whatever tom you need. You do need to take care of fading out the notes yourself, though - the SFX ends on a held G1, just to let the drums have a longer sustain than 32 ticks.
The trouble with the General Midi 1 standard is that it doesn't include any explanation of what any of the names mean, so I had to spend multiple seconds of research on going to the GM-1 Wikipedia page and scrolling down to the best guess of the editors there. Apparently, by "SynthStrings", they probably mean a string synthesizer, or string synth, an electronic instrument originally intended as a relatively cheap and portable substitute for a strings section, but which people later started to use as an instrument in its own sake.
So, that's what I tried to imitate. And since GM-1 has two SynthStrings program numbers and says nothing about how they should differ, I just tried to follow what GeneralUser GS seemed to do and make the second version a little brighter in timbre.
Here's 050 SynthStrings 1:
[sfx]
...and 051 SynthStrings 2:
[sfx]
This one turned out to be a relatively simple process:
- Select the "Organ" waveform.
- Make it as huge as possible.
The preview sounds terrible because it loops the vibrato weirdly, but when used as an actual instrument, the vibrato works as normal.
Wikipedia said that the Electric Piano 2 slot is often an FM piano patch, so I went in and tried to make something with a similar vibe:
This one ended up being really simple:
...but there's a couple tricks to using it in a way that feels violin-y.
First, you have to think about what exactly the violinist is doing at any given moment in order to navigate the notes they're being asked to play. For those who do not know violin performance well: the way a violin produces sound during normal play is by using a tensioned stick with hair coated in rosin attached to it - the aforementioned bow - to scrape along a string, imparting energy to the string that then causes it to vibrate and make sound. And, crucially, the bow is only so long, and can only be moved so slowly across the string ... so, as the violinist plays, they regularly have to stop and change direction.
Plus, the way a violin creates a specific note is not, as with a piano, by pressing a key, but by pressing a finger on a string to hold it against a fingerboard - there are no frets, and to change a note, the violinist has to move their finger to a new position.
So, in my demo of it:
...I use a lot of glides to represent places where a single stroke of the bow is being used to play multiple notes, and at the part at the end of the loop where the notes jump around a bunch, I chop off (sorta) the ends of the notes to give the impression of the gaps between notes from when the violinist had to move quickly.
Oh, and the second trick to it.
This SFX has built into it a point where the violinist runs out of bow and has to do another downstroke. (This is something I copied from the VS Chamber Orchestra sample I referenced when designing the note - it's not included in soundfonts like FluidR3.) If you're holding a note for a long time - 341 ticks, 2.83 seconds - the volume will drop off and there will be a moment like at the start of the SFX where the texture of the note roughens ... because the fictional violinist playing the note ran out of bow and had to do a second stroke. If you don't want that, you can change the loop points to stop before the repeat; if you do want that, you can adjust things to make it happen at the right tempo for your specific piece of music.
Steps to reproduce:
-
Create a custom SFX instrument.
-
Create an SFX using this instrument.
-
Add the latter SFX (but not the former) to a music pattern.
-
Select the pattern and copy.
- In a new PICO-8 cart, select a pattern and paste.
Expected behavior:
All necessary data to reproduce the original pattern should be transferred. (Notably, this occurs when pasting into the BBS.)
Observed behavior:
The SFX instrument is not copied, and only the SFX specifically included in the pattern are copied.
I'm gonna be honest: did this one next because I remembered my opening a soundfont in LMMS for the first time, browsing around, and going "wait, did that say Celeste?!"
(It did, but it's a case of shared etymology - it means the heavens. Or the sky.)
In keeping with the real-world version, this is a transposing instrument - plays an octave above the note entered. There is some artifacting on D#6, however.
This is a duplicate of this earlier piano SFX as far as the midilib project is concerned, but I wanted to share my attempt at replicating ... I think the sample I was referencing was an upright piano? As best as I could.
As with the others, this is free to use, although credit is appreciated; the manual entry on custom SFX instruments should explain how to use it.
No cart preview right now, but posting the SFX so people can use it: my latest best shot at a xylophone sound:
Free to use, credit appreciated; manual section on SFX instruments is here if it's not something you're familiar with.
So, PICO-8's built-in tracker has a startling amount of customization, but it can be kinda tricky actually making a custom SFX instrument when you want one - so a few of us on the Discord, me and @jo560hs and @bikibird, were thinking it might be interesting to look at the list of General Midi 1 instruments as a shopping list and see how many we can knock off.
And as a bonus, if we can complete the list, @jo560hs was talking about possibly making an sf2 soundfont for folks who like playing with those.
So, if you wanna jump in and add stuff to the catalog, the guidelines we decided on for convenience of people hunting down instruments afterwards are these:
- tag the post with
midilib
- use a subject line of the format
midi [number] [name]
- (ideally, each instrument should be posted in its own thread, so specific ones can be found more easily)
- embed your SFX there so people can hear it and copy it
- let folks know if you have any special requirements (I generally assume something akin to CC-BY, where people can use them freely if they credit you, but let us know!)
As people create more instruments, we'll try to look in the midilib tag and update everyone on what people have been doing, so folks who feel like doing whatever can see what's missing.
I've made a text file with a list of all the GM-1 instruments and their numbers - feel free to ask questions, promote your threads, and so on here.
Clarifying note about duplicates
Quick heads-up, because it seems to have been the source of a little confusion: yes, we do want to complete the list of SFX ... but even when people have already made SFX for a particular MIDI patch, please share your versions! I can tell you right now: I have eight different pianos downloaded to my hard drive that I can use as instruments in LMMS, plus four more in each of the two big sf2 soundfonts I downloaded, plus a bunch of presets for LMMS's built-in synths, plus all the other soundfonts I have ... and I have zero regrets. Just as much as we want this project to create a PICO-8 sf2 soundfont for producers to play with, we want this project to create a library of sounds for PICO-8 composers to play with. And variety is great because it lets people choose the perfect sound for their tracks.
So, please, post duplicates when you have them. Having more options is terrific.
Instruments as of 2023-03-16
For anyone who wants it, an SFX imitating an electric guitar with overdrive:
Free to use, credit appreciated.
(If you are not already familiar, the manual has a brief explanation of how custom SFX instruments work.)
A group of us on the Discord were talking about how it'd be useful it'd be to have a big library of SFX instruments, so here's one I made a while ago to act as a ragtime piano:
Free to use, credit appreciated.
(If you are not already familiar, the manual has a brief explanation of how custom SFX instruments work.)
So, I'm working on a toy musical keyboard program, and I want to use SDL scancodes to detect which keys are being held - but I know that PICO-8 will pause if you hit the "P" key (whatever key that happens to be in the user's keyboard layout). So I want to detect when a "P" input is being received and stop it...
...but my current code:
--interrupt pause on P while stat(30) do if stat(31)=="p" or "◆" then --suppress pause poke(0x5f30,1) end end |
only works for the initial press - when the key starts repeating, stat(30) doesn't detect the input but PICO-8 pauses anyway.
Any suggestions? I'd rather not interrupt all pause inputs - that makes things difficult for Splore users.
Edit: Apologies to @dw817, whose explanations I apparently completely failed to parse: in the changelog for 0.2.2b it is noted that holding the pause button will always bring up the hardware pause menu, even when pause would otherwise be suppressed. This rules out any solution that involves the player holding down P that I can implement as cart programmer. (Shoutout to @cubee's description of a related bug which cued me in.)
I was updating a cart I was working on to use stat 46-56 instead of 16-26 and noticed that new bugs were introduced in the change. It looks like stat(16) updates immediately when a music() command is called, but stat(46) will sometimes show an erroneous value (e.g. -1) on the frame of the update.
View Older Posts