Maybe my filter is lame. With respect to the left channel in the schematic above, I only use surface mount decoupling caps (104's) for C4 and C5, and I use 180R instead of 750R for R20. Although I think there's a lot of variability on what values can be used, maybe my values and the cap type(s) are not ideal. Then again, it is mono and the speaker is small (though the beeps can be quite loud).

Maybe my filter is lame. With respect to the left channel in the schematic above, I only use surface mount decoupling caps (104's) for C4 and C5, and I use 180R instead of 750R for R20. Although I think there's a lot of variability on what values can be used, maybe my values and the cap type(s) are not ideal. Then again, it is mono and the speaker is small (though the beeps can be quite loud).

Your sound circuit works fine for the beeps it was intended for. I was probably silly to try to use it for this music software.

Hmm, I've been thinking about how to crunch the song data even smaller. Some people think about philosophy and the meaning of life while they're in the shower, I think about PASM....
The actual note data is already extremely dense, but the pattern sequences are not only quite large, but also aren't very flexible.
As far as I can tell, at the max tempo, the music routine is called 16 times per step - twice per channel, first to step through the patterns, second to load a new pattern from the sequence. If the max tempo was halved (still plenty fast at 64kHz), there would be four calls per step. There's the one for the pattern, but now we can interpret up to three sequence commands that can be 16 bit each. I haven't tested it yet, but I think replacing patternHandler with this would work:

There definitely are ways to improve Retronitus data format and make it more flexible etc. It will be interesting to see what you will come up with. P1 Retronitus is "abandoned" for now, so feel free to pick it apart, improve upon it or change it to suit your needs. I will look in here from time to time when I am not spending time in the P2 forum. In the future I will take what I have learned from Retronitus and make an improved version for the P2.

I noticed this while messing around: The square and triangle channels have twice the amplitude of the saw and noise channels. The square channels in particular divide their volume by 8 and then add or subtract that to/from the output, leading to a max. peak-to-peak volume of $1FFFFFFF (whereas to avoid overflow, it should be $0FFFFFFF)
Is there any particular reason for this?

So here's another one of those things I've been sitting on for a while: Some Retronitus fork I call Retronitus DX.

It's all a bit rough around the edges and unfinished and shit, but I'll link it here anyways, because why not.

- blastershot.rb (get the pun?) can generate customized Retronitus DX cog images. It's super rough, there's no user interface at all, you'll need to manually invoke the gimme_retronitus function through IRB.
- retrosnd.cpp/retrosnd.hpp are a C++ implementation of Retronitus DX. It's reasonably fast and should(tm) be bit-accurate.
- retrosnd_env.hpp contains all the definitions one needs to slot the implementation into an environment of choice
- build_dll.sh will build you a libretronitus.dll library. It should(tm) also work out on non-Windows OSes
- rsndplay.rb can play a Retronitus DX song given on the command line. (This requires ffmpeg and ffplay to be installed and libretronitus.dll to have been built)
- Alice.binary is a slightly improved version of that tune (obviously converted to the new data format, too). The source for this can be found here.

It's been a while, but these are the changes I think I made compared to regular Retronitus:
- Instrument instruction format changed: Now allows modifying previously internal-only registers (such as the phase accumulator). Jumps have been generalized as a regular register ADD (yes, there can also be absolute jumps now).
- New 16 bit pattseq format - slightly more compact. I think it's the same as I proposed in this thread before.
- Probably more, I don't remember.

Oh, I did some more work recently. First off, it all actually works now! Maybe. I hope.
(Previously, I committed the wrong versions of some files... oof)(EDIT: I did it again! If you looked at the repo in the last 6 minutes, it wasn't updated yet....)

Also, I did some more muckery:
- TRG_x now jumps behind the normal instrument entry point. This makes most instruments that use TRG_x one instruction (= 8 bytes) shorter (obviously, this is a breaking change)
- Tuned notes to 440Hz (hopefully? I can't tell the difference TBH. I just noticed while debugging another issue.)
- Fixed some bugs in the C++ implementation
- Source code for Alice.binary is now actually in the repository...

I've also been working on some more stuff. I've attached some preview thing of an original composition of mine. Well, it's not particularly "original", is it? Not entirely happy with the percussion patches yet.

Attached to this post, you may find the source code for a couple songs:
- Alice_main.spin for a slightly updated version of the Alice in Wonderland cover from a while back
- Fierce_main.spin for the aforementioned original composition, Gipfelarena ~ Fierce battle (oscilloscope visualization coming soon?)
- Bent_main.spin for another original composition, titled Bent into a neat shape (oscilloscope visualization coming soon?)

I've also done some stuff with the tooling. There's now a format for embedding metadata into a Spin file, such as song title, author, comment and channel setup.

Additionally, I've developed a tool called beepbox2spin that converts the JSON data exported by BeepBox, a beginner friendly browser-based open source sequencer, into a Spin file for Retronitus DX. You still need to do quite a lot of manual editing, but it takes care of the basics well enough.
What it does:
- Converts all used patterns
- Converts pattern sequences (optimizes some (but not all) unnecessary instrument/note set commands)
- Creates placeholders for all used instruments
- Arpeggio-type chords (uses lots of memory...)
- Harmony-type chords
- Non-"unit" instrument interval settings will duplicate notes onto a second channel (and in case of "fifth" and "octave",shift up the suplicate notes)

Cool More tooling like this can only make it easier for someone with the creativity to get a great Prop-based game going. The ability to play the songs on the host machine is nice, too - don't know how I missed that before? It works well...
Between your game engine, the others before it, and all the synths that exist there are some great choices for writing a game on the Prop... I wish I had an idea for or the talent for writing one lol. I hope to see yours one day...dunno if it's that Zelda-esque looking one I saw earlier, but it's something to look forward to!

I hope to see yours one day...dunno if it's that Zelda-esque looking one I saw earlier, but it's something to look forward to!

Yeah, that is mine.
I actually recorded some more videos of it that I didn't post here... Altough the last one is already a month old (altough I didn't do much since then. Where did that time go? EDIT: oh, the enemies can actually die now, so I guess that's what I did since then, lol)

So I've been working on things again. For one, I've successfully integrated Retronitus DX into The Game(TM) (well, the P1 version. PC version is still TODO, but should be no problem), which required a few changes - SEQ_INIT now has to come before INS_INIT in a song file (this way, the parameters used to initialize Retronitus can stay the same regardless of how many instruments are present) and all channels must have a valid pattern sequence (to simplify init code). All this isn't committed yet, but will be soon(TM), when I'm done with the other thing.

That other thing being sound effects. To facilitate them, I've developed a new channel type. It implements an LFSR, similar to the noise channel on many soundchips, except you can freely select which bits to tap. By tapping just bit0, you can also play a 32-step 1-bit waveform of your choosing (including a square wave). By tapping bits 17 and 18, you can emulate the NES APU's noise channel. The possibilities are great.

Now the problem is creating sound effects that sound good. I really liked the sound editor in @macca 's GUI tool, but IDK if I have the nerve to deal with setting that up, fixing all the bugs and adapting for DX's slightly different SPU instruction format. So I'll probably have to come up with something significantly less slick.

In addition to the changes mentioned above, this introduces some tooling to deal with a new file format called RSX. An RSX file contains up to 255 songs*1 and 254 sound effects*2 in an easy-to-use format. I don't really have a good example for using RSX files, but I have a pretty good description of the format in README.MD. so I guess that's something.

*1 (each up to 6K, although songs that are not marked as no_sfx will be limited to 5.5K (this is an artifact of how my game dual-purposes the last 512 bytes of the audio buffer. Should probably be optional...))

*2 (each up to 512 bytes in size, but the first long is reserved for metadata, so 63 instructions will fit)

Here's another simple tune. I've been sitting on this one for ages. Today I opened it up and figured it was basically done. Quickly ported it into Retronitus DX, slapped on an edgy title and uploaded it now...