Building for Raspberry Pi using Github Actions

While Raspberry Pi SBCs have gotten significantly more powerful over the years, they are still pretty limited compared to a PC when it come to compiling. Building a complicated project on a Pi4 or even a Pi5 can be slow, and it is easy to run out of memory when compiling on the smaller (ie: 1-2GB) versions.

I wanted to provide release binaries for Raspberry Pi for several of my GitHub projects, and didn't want to do a manual build and upload. Fortunately, with a bit of digging, I found and was able to use Pieter Pas'  docker-arm-cross-toolchain to build for Raspberry Pi using GitHub actions.

Here is an example snippet for setting up a Pi4/Pi5 build matrix in a Github action:

name: Raspberry Pi Build

on:
  workflow_dispatch:
  
jobs:
  build-rpi:
    name: Build Raspberry Pi
    strategy:
      matrix:
        native_arch: [rpi4, rpi5]
    runs-on: ubuntu-latest
    container: 
      image: ghcr.io/tttapa/docker-arm-cross-toolchain:aarch64-rpi3-linux-gnu-gcc12
    steps:
      ...do something

Note the "gcc12" at the end of the docker image path. This ensures that your RPi build will work on RPi OS versions going back to Bookworm.

When you get to building, assuming that you are using CMake, you can specify the build tools by using:

-DCMAKE_TOOLCHAIN_FILE=/home/develop/opt/x-tools/aarch64-rpi3-linux-gnu/aarch64-${{ matrix.native_arch }}-linux-gnu.toolchain.cmake

You can see this at work in myneural-amp-modeler-lv2 and NeuralAudio GitHub repositories. Have a look at the "release" GitHub actions.

State of NAM on Raspberry Pi

It's been almost two years now since I first posted a video of Neural Amp Modeler captures running on my Raspberry Pi 4.

A lot has changed since then.

Originally, the NAM playback code was extremely expensive. So much so that a Raspberry Pi 4 could only manage to run "feather" models.

Because I wanted to run more accurate models, NAM  optimization became a bit of a pet project. With some optimizations to the NAM Core codebase, we were able to increase performance by more than 2x. That, combined with more widespread availability of a 64bit OS for the Pi, made "standard" NAM captures possible - with plenty of headroom left for a cabinet IR and some light effects.

More recently, I have been working on my own implementation of WaveNet and LSTM models, with a focus on performance. The result of which, you can see running in the image above in my Stompbox app.

Note the numbers in the bottom left - that is the realtime CPU usage as reported by Jack. This is running a "standard" NAM capture. Audio buffer size is 96 samples. CPU usage of "standard" models is now low enough that I can easily run two models at once, with plenty of CPU left over for IR and effects. I can even (just barely) run three models at once.

This Boss SD-1 Pedal Does Not Exist

 

I've been messing around lately with combining Neural Amp Modeler with another open source project I've contributed to in the past - LiveSPICE.

LiveSPICE allows you to simulate audio circuits in real-time, which is very cool. The disadvantage it has is that it is very CPU-heavy. It's CPU usage is also not super consistent, but can be spiky, which makes it hard to use in a live, low-latency environments without getting audio dropouts.

It *is* however, very easy to use it to generate training data for Neural Amp Modeler. So that's what I did.

Because it uses a simulation of the pedal circuit, the generated training audio has none of the added noise that is difficult to fully avoid when capturing actual pedals. This "idealized" version of the pedal should be even easier for the neural net model to learn.

And indeed, it is. Here is the ESR of a "feather" model (the smallest, least CPU-intensive default NAM model type).

It shows 0.000, but it was actually around 0.0001.

You can get the resulting .nam model here on ToneHunt.

Neural Amp Modeler (NAM) running on Raspberry Pi

Recently I've been messing around with, and contributing to the Neural Amp Modeler project. It uses machine learning (more specifically the WaveNet model) to create captures of amplifiers and distortion pedals.

It has been gaining a lot of traction recently, with lots of people modeling their equipment. The resulting models are very good.

I've now got it integrated into my Raspberry Pi pedalboard. The audio for the above video was recorded on a Raspberry Pi 4.

The hardware on the pedalboard consists of:

- Raspberry Pi 4

- Hotone Jogg audio interface

- Hotone Ampero Control MIDI Controller

- Wio Terminal (used for a serial-based display)

My pedalboard is using a custom app on top of Jack audio, but I have also made a Neural Amp Modeler LV2 plugin available.

Chord data for jazz standards

I recently started playing jazz on bass guitar. So naturally, I also recently started writing software for facilitating jazz practice.

As a basis for a number of my projects, I needed access to chord data from a corpus of jazz standards. The best source I found was the database of user-submitted scores for the IReal mobile app: https://www.irealpro.com/main-playlists

I've been converting these to an easy-to parse json format. The current database of songs can be found here:

https://github.com/mikeoliphant/JazzStandards

Here is an example score:   

  

  {
  "Title": "Alone Together",
  "Composer": "Schwartz Arthur",
  "Key": "D-",
  "Rhythm": "Medium Swing",
  "Sections": [
    {
      "Label": "A",
      "MainSegment": {
        "Chords": "Dm6|Em7b5,A7b9|Dm6|Em7b5,A7b9|Dm6|Am7b5,D7b9|Gm7|Gm7|Bm7,E7|Gm7,C7|Fmaj7|Em7b5,A7b9"
      },
      "Endings": [
        {
          "Chords": "Dmaj7|D(Em7b5),(A7b9)"
        },
        {
          "Chords": "Dmaj7|Dmaj7"
        }
      ]
    },
    {
      "Label": "B",
      "MainSegment": {
        "Chords": "Am7b5|D7b9|Gm6|Gm6|Gm7b5|C7b9|Fmaj7|Em7b5,A7b9"
      },
      "Endings": []
    },
    {
      "Label": "A",
      "MainSegment": {
        "Chords": "Dm6|Em7b5,A7b9|Dm6|Em7b5,A7b9|Dm6,Bm7b5|Bb7,A7b9|Dm6|Em7b5,A7b9"
      },
      "Endings": []
    }
  ]
}

Arduino sketch for TFT display rendering using serial commands

I've been using a Seeed Studio Wio Terminal as an external display for a Raspberry Pi. I initially wrote an Arduino sketch that took high level, application-specific commands over serial and rendered appropriate display elements. This has the disadvantage that adding UI features required updating the Arduino code, which is more of a pain and slower to iterate on.

Instead, I'm now planning on sending rendering commands over the serial interface - turning the microcontroller into a general purpose rendering device.

I've thrown my initial code up on GitHub here:

github.com/mikeoliphant/SerialTFT

It currently only supports a small set of commands for rendering rectangles and text. I'll be adding more features as I need them.

Speeding up Arduino TFT (TFT_eSPI) writes

 I've been recently playing around with "Arduino" microcontroller stuff - specifically a Seeed Studio Wio Terminal.

Playing around with the TFT display, I noticed that drawing to it was pretty slow. After doing some research, I found out that direct TFT writes are indeed quite slow. But there is an easy way around it.

The TFT_eSPI graphics library, a modified version of which is used by the Wio Terminal, provides a Sprite class that can be used to do quick TFT writes. If you have enough memory (which the Wio Terminal *just* barely does), you can create a full screen-sized sprite.

The Sprite class supports the same drawing API as the main TFT class, so it is pretty easy to convert code that is writing directly to the TFT to use a Sprite instead.

To initialize it, do this:

TFT_eSPI tft = TFT_eSPI();

TFT_eSprite screen = TFT_eSprite(&tft);

In your setup(), after initializing the TFT, do this:

screen.createSprite(tft.width(), tft.height());

Then, use "screen" instead of "tft" for all of your drawing calls. When you want to update the TFT with the current state of your sprite, do this:

 screen.pushSprite(0, 0);

That's it! The result is a display that will update *much* faster.

One caveat is that this method uses up the vast majority of the Wio Terminal's RAM. It works fine for me, since my application is not otherwise particularly memory hungry. More complicated applications (using WiFi, for example) may run into problems. If that happens, a good (if more complicated) solution would be to use a smaller screen area sprite and do targeted writes to sub-areas of the screen.

Fixing Hotone Jogg ASIO "No devices connected" issue

I recently ordered a Hotone Jogg guitar audio interface pedal and had trouble getting the Windows 10 ASIO drivers to work. Turns out that ASIO support was added with a firmware update, and the pedal I got had the old firmware.

If you are having this problem, you need to get the updated firmware from here:

https://www.hotoneaudio.com/support/2

Scroll down until you see "Jogg firmware with Hotone ASIO driver support" and click on the link to download the firmware.

Follow the included instructions (you have to open up the unit to flip a dip switch, which is not very user friendly) and you should soon be good to go.

Hotone Jogg audio interface pedal works in Linux

 After posting a number of previous posts about guitar audio interfaces that did not work out of the box, I am pleased to report that the Hotone Jogg works right out of the box in Linux. Pleasant surprise!

I couldn't find any information on using this device with Linux, so I thought I'd do this brief post for any future people that may be looking.

NUX MG-300 Guitar Processor under Linux and Android

 

I picked up a NUX MG-300 guitar effects unit with high hopes that it would work under Linux, since it is supposed to be a class-compliant USB audio device.

Unfortunately, it did not work out of the box. After some back and forth with the maintainer of the Linux kernel sound subsystem, we managed to get audio capture working, but never managed to get playback working. Everything seems to be operating correctly, but the device produces no audio output over USB.

I have admitted defeat and will be returning the device.

The discussion on the alsa-devel mailing list can be found here:

https://mailman.alsa-project.org/pipermail/alsa-devel/2021-January/179348.html

It at least resulted in a kernel patch to enable audio capture.

I also had no success getting it to work with Android - even with some of the apps that have their own custom USB audio implementation.

If anyone has more luck with this interface down the road, please let me know.

Update: As a last ditch effort, I gave the interface a try with the aforementioned kernel patch on my Raspberry Pi 4, which was running about a year old kernel version. And it worked. Sort of. It initially worked perfectly, but I found after more testing that it is sporadic. Sometimes it worked fine, sometimes only playback worked, and sometimes only capture worked. Not sure what needs to be done to get the interface working reliably.

Guitar amplifier and pedal simulation

I've been spending a lot of time lately playing guitar, and working on my own software for simulating guitar amplifiers and pedals. It is coming along nicely, and I have most of the important stuff covered.

I run it as a VST under Windows, but I also have a Linux version that I run on a Raspberry Pi 4. Coupled with a USB audio interface, a PA speaker, and a remote control app on my phone, it makes for a nice little portable rig.

Here is a little video of it in action (running as a VST in Reaper):

Starting JACK automatically when a USB audio device is connected

I have a Raspberry Pi that I'm using headless for audio, and I wanted to automatically start jackd when I connected my USB audio device.

There are a lot of ways to try to do this - after a few false starts, I ended up with this method. It took me long enough to sort out the details that I figured I'd write up a little how-to.

This solution is composed of two parts: 1) set up jackd as a systemd service, and 2) use a udev rule to start the service when the sound card is connected.

First the service. Create a file called '/etc/systemd/system/jackd.service' with the following:

[Unit]
Description=JACK audio
After=network.target

[Service]
ExecStart=/usr/bin/jackd <your jack commandline arguments here>
WorkingDirectory=/usr/local/bin
StandardOutput=inherit
StandardError=inherit
Restart=always
User=root

[Install]
WantedBy=multi-user.target

Now (or at least after you reboot, or do 'sudo systemctl daemon-reload', you can start and stop jackd with 'sudo systemctl start jackd.service' and 'sudo systemctl stop jackd.service'. I'm running the service as root - if you want to use a different user, change the "User=" line.

We want this to happen automatically, though, so it is time to use udev - the system for managing Linux device events.

First, you need to know some information about your USB audio device. Plug it in, and run 'lsusb'. You should see something like this:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0582:01d6 Roland Corp.
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Look for your sound card device in the list (mine is showing as "Roland Corp."), and note the two hex numbers after ID. They are the USB Vender and Product IDs for your device.

Create a file called something like '/etc/udev/rules.d/80-local.rules' with the following in it:

ACTION=="add", ATTR{idVendor}=="0582", ATTR{idProduct}=="01d6", TAG+="systemd", ENV{SYSTEMD_WANTS}="jackd.service"

Where the values for 'ATTR{idVendor}' and 'ATTR{idProduct}' are the Vendor and Product IDs you got from lsusb.

After your next reboot, or after running 'sudo udevadm control --reload', you new rule should be ready. When you plug in your sound card, the udev rule will fire and request your service, which will then start jackd.

Using the Mod Devices guitar effects interface on Raspberry Pi 4

My last post was about getting my Boss GT-1 guitar effects floorboard to work in Linux. The reason I wanted to do this was to couple it with a Raspberry Pi to create a more configurable effect chain using LV2 plugins.

Once I had audio working, I installed Guitarix, an open-source guitar effects stack for Linux, and I was quickly off to the races. Guitarix works really well, but the interface is designed for desktop use - not ideal for my needs.

I had been aware of Mod Devices for a while, with their Mod Duo multi-effects hardware pedals built on top of Linux. They have added a slick, web-based pedalboard interface running on top of LV2 plugins. It is primarily designed for their hardware devices, but the project is open source.

The folks over at blokas.io have a project called MODEP, which provides a custom Raspberry Pi image for running the Mod Devices interface. Unfortunately, it currently does not work on Raspberry Pi 4, which is what I have.

So, I went straight to the Mod Devices GitHub and built it myself. It turned out to be pretty straightforward, and I was up and running after about a half an hour of tinkering. I'm going to try to outline what I did here in case anyone else wants to give it a try:

Get Jack running with audio capture and playback - there is plenty of information out there on this

Get the Mod software from GitHub:

  git clone --depth 1 https://github.com/moddevices/mod-host
  git clone --depth 1 https://github.com/moddevices/mod-ui

Install the tools you need to build the mod software. You'll need at least:

sudo apt-get install virtualenv python3-pip python3-dev git build-essential libasound2-dev libjack-jackd2-dev liblilv-dev libjpeg-dev zlib1g-dev

Build mod-host from the mod-host directory:

make
sudo make install
cd mod-ui
make
sudo make install

Make sure Jack is running, and start mod-host:

mod-host -n -p 5555 -f 5556

In another shell, build mod-ui from the mod-ui directory:

virtualenv modui-env
source modui-env/bin/activate
pip3 install -r requirements.txt
make -C utils

Run mod-ui from the mod-ui directory (you will also need to do "source modui-env/bin/activate" first if you did not just do it in the above build step):

export MOD_DEV_HOST=0
export MOD_DEV_ENVIRONMENT=1
export MOD_APP=1
export MOD_LIVE_ISO=1
python3 ./server.py

The mod-ui web server should now be running on port 8888. To access it, find out the IP address of your Raspberry Pi, and go to:

http://YOUR-PI-IP:8888/

You should see the Mod pedalboard interface. It should load whatever LV2 plugins you have in /usr/lib/lv2 with a generic look. In my case, I had Guitarix installed and all of its plugins were there and ready to be used.

The Mod folks have custom UI overlays for most popular plugins. You can grab them here:

git clone --depth 1 https://github.com/moddevices/mod-lv2-data

Look in the "plugins" and "plugins-fixed" sub-folders for your plugins. If you copy a plugin folder over your existing plugin in /usr/lib/lv2, you will install the custom UI for the plugin.

My Pi 4 has no trouble at all running a decently complex guitar effect stack, complete with multiple pedals and pre-amp and cabinet simulation, all at very low latency.

Getting the Boss GT-1 effects processor to work in Linux

---

** Latest Update: The Boss GT-1 should be working out of the box as of Linux kernel v5.14.

---

I recently picked up a Boss GT-1 guitar digital effects floorboard to use directly, and also to play with connecting it up to the Raspberry Pi.

A month later, I have everything working well. As is often the case with niche gear and Linux, though, it was a bumpy road to get there. I'm going to document the process here, in case it is helpful for anyone with a similar issue.

I booted up my Pi, connected the GT-1 via USB, ran lsusb to list the available USB devices, and there it was. Great - that was easy!

Next, I tried playing a .wav file with aplay. No go. No audio at all. Not so great.

Time to start scouring the internet. After a while, I came across this thread on linuxmusicians.com:

https://linuxmusicians.com/viewtopic.php?f=6&t=17180

It had a fix for another Boss device. It also turned out to work for Boss Katana Amplifiers, which have a software setup that is very similar to my GT-1 device.

I grabbed the kernel source code, applied the fix (with a tweak for my device), and soon I had working audio! Well, kind of working. I was getting pops and crackles every second or so - enough to make things unusable.

To understand this fix, and why it wasn't quite working requires a bit of explanation on how USB audio works. There are a number of methods that devices use to synchronize audio timing. The one used by the Boss GT-1 (and many similar devices) is called "implicit feedback". In simple terms, what this does is, on devices that have both a capture and playback that are controlled by the same clock, the capture source is used to determine the output data rate. Essentially, the host is in a USB feedback loop - outputting the same number of samples it receives - generally after doing some processing.

The fix that got my interface working basically disables the implicit feedback mechanism. This got audio moving through the system, but because there was no timing feedback it was slightly off - resulting in the pops and crackles I was experiencing.

A while later, I came across this post in the Line 6 forums about getting the Helix (another guitar processing device) working in Linux:

https://line6.com/support/topic/4426-line-6-with-linux/?tab=comments#comment-240302

The additional fix here was to hack the sample rate slightly to try to match the real timing of the device. I gave it a try, and it turned out that if I nudged the sample rate to 44105 (instead of 44100), my pops and crackles mostly went away - happening every few minutes instead of constantly.

This fix was obviously a hack, and not perfect, but it at least made my interface usable. The core problem still existed - the device should be operating using implicit feedback, but when this was enabled it didn't work at all.

I had posted about these issues on the alsa-devel mailing list, and a while later I got a helpful email suggesting that some Roland devices waited to send capture data until they had received some playback data. The kernel implicit feedback code, on the other hand, was waiting for some capture data before it send any playback data. The result was a standoff - with nothing getting sent either way.

Simply disabling the code that caused playback to wait on capture resulted in working audio with implicit feedback enabled, and a perfectly solid audio stream with no pops or crackles!

I outlined this fix on the alsa-devel mailing list here:

https://mailman.alsa-project.org/pipermail/alsa-devel/2020-January/161951.html

I hope to get a patch for this into the kernel eventually - right now I am doing some poking around to see if I can find out what other similar devices this fix might work for.

** UPDATE **

A series of patches to implicit feedback handling made it into the kernel (5.11) a while back. I had thought that these changes were fully working on the BOSS GT-1, but it turns out that I just hadn't tested well enough.

Audio playback and capture works, but with periodic dropouts. I get the exact same behavior as I did with the quirk to completely disable implicit feedback.

Changing the GT-1 playback feedback handling from IMPLICIT_FB_SKIP_DEV(0x0582, 0x01d6)  to IMPLICIT_FB_GENERIC_DEV(0x0582, 0x01d6) and applying the endpoint.c patch outlined earlier in this post results in perfect playback and capture for me.

Here is my post on the alsa-devel mailing list about this:

https://mailman.alsa-project.org/pipermail/alsa-devel/2021-April/183274.html

** UPDATE 4/14/2021 **

A version of the above fix has now been submitted as a patch and should eventually get into the mainline kernel. The fix is also being applied to other BOSS devices, such as the rest of the GT family, and the BOSS Katana. Here is the patch:

https://github.com/tiwai/sound/commit/ebe8dc5afb3912e2d4f5c62cf7c492a13143a77a

** LATEST UPDATE **

The above fix was released with Linux kernel v5.14.

Coming soon to Nintendo 3DS

We've been hard at work this year to bring support for our games and applications to the Nintendo 3DS. The recent support of the 3DS platform by the Unity engine (which we use for targeting most of our other platforms) made this possible.

PixelMaker will be our first release on Nintendo 3DS. It works great on the 3DS handset - using the bottom screen to draw, while having an overview of the entire scene on the upper screen. We even leveraged our drawing layer feature to provide support for the stereoscopic 3D display. The effect is really quite fun, and we are looking forward to see how people use it.

Even though Unity is primarily targeted at the New Nintendo 3DS, we worked hard to make PixelMaker run on the original 3DS as well. This wasn't easy, given the memory and CPU limitations of the original device, but we are very happy with the result we were able to achieve. I believe we will be the first Unity 3DS release to run on the original 3DS.

We plan to bring our voxel editor VoxelMaker, as well as at least some of our games, to the 3DS soon.

PixelMaker - a pixel art and sprite drawing program

I've been thinking about making a sprite editor for a while now. Drawing sprites is a big part of what we do when making our games. We have been using GIMP as our primary drawing tool, and while it works pretty well, it doesn't mesh perfectly with our workflow.

So, a few months ago I finally pulled the trigger and started working on PixelMaker. In order to justify making a polished program (instead of a rough-and-ready developer tool), we plan to release it on various platforms - initially on Wii U (the GamePad and stylus are great for drawing) and then later on mobile/PC.

I'm pretty happy with how it is turning out. It loads instantly, unlike programs like Gimp and Photoshop, and is fast and lean - with the features you need for drawing pixel-y stuff, uncluttered by features you don't need (at least *we* think so - we'll see once we have more customers...)

Our initial feature set for release targets drawing individual pixel art pieces, but future planning includes frame-based animation.

On a more dev-centric note, I recently bolted on a project structure interface for us to manage the art assets for a game - designed to integrate with the custom sprite scaling/shadowing/sheet-packing pipeline we currently use:



We plan to get back to working on our already-well-in-progress next game soon, now switching over to using PixelMaker as our core art creation and management tool.

What next game is that? Well, stay tuned for more on that soon!

Fractopia - fractal rendering with the GPU on PlayStation Vita

The above video shows Fractopia, my GPU-powered fractal explorer for PlayStation Vita and PlayStation Mobile certified Android devices. Sorry about the poor focus - it's hard to film yourself playing something on the Vita!

I had the idea to try GPU-accelerated fractal rendering on the Vita a while back, but I didn't get around to actually messing with it until a few weeks ago. My initial experiments turned out quite well, so I took the time to make it into a full-fledged application.

As you can see in the video, Fractopia allows smooth panning and zooming of fractal imagery. It allows you to navigate the Mandlebrot and Julia fractals, and lets you change the Julia seed in real time to create a huge variety of interesting "fractalscapes" to explore.

Fractopia has passed PS Mobile certification, so it should come out on PSN in the next few weeks.

Vacation Vexation - a new "Quiet, Please!" adventure

I've been hard at work recently on a new "Quiet, Please!" adventure. The current likely name is "Vacation Vexation", and it features the same style of gameplay as the original.



This time the setting is a family vacation in a seaside town. You just want to relax on the beach and read a book, but of course circumstances conspire against you...



In addition to the puzzle-solving gameplay, there is an arcade that features playable mini-games:



There are a couple of  knock-offs of arcade classics, and one that people who have played my other games might recognize...



With this new game, I'm going for roughly 2-3 times the amount of content that was in the original "Quiet, Please!". This isn't because "Quiet, Please!" was too short. Some people complained about the length, but most found it worth the dollar and it is my best selling game to date. I want to try to get away from selling games for $.99, though, and that requires more content.

While there are a number of reasons I want to target a higher price point, probably the most important one is that it allows me to put a game on sale. If a game is already at the lowest price point for an app store, you can't put it on sale without making it completely free. Consumers really like "free" as a price point, but from a seller's perspective it has obvious disadvantages...

I figure I'm roughly two thirds of the way through development on "Vacation Vexation". I hope to release it on all of the platforms I support (which is most of them) in the next few months.

Ascent of Kings Review Round-up

Some reviews of Ascent of Kings have popped up around the internet over the past week. You can check out what they had to say from the links below:

Chet & Jon
Indie Gamer Chick
IndieGames.com
CGR Undertow
gameding

Working on Playstation Mobile

Yep, that's my game intro screen running on the Vita. I have spent the past couple of days porting my 2D game engine to PlayStation Mobile.

The PSM platform is C# based, so it was a really good match for me. Even though PlayStation Mobile uses MonoDevelop and I use Visual Studio, the two environments are assembly-compatible and I can still do the bulk of my work in Visual Studio and mostly just use MonoDevelop as a means for final deployment.

The hardest part of the process was getting the drawing code working. PSM provides a pretty low-level graphics interface, so it took me a while before I had my first triangle onscreen. When working with a new graphics api, the first triangle is always the hardest. There are a million different reasons (matrix transforms, shader issues, culling, bad vertices, bad indices, etc.) why your triangle won't render. Once you can see something, you can fix what is wrong. When you can't see anything you don't have much to go on.

After getting my first rendering working, the next step was sprite batching. PlayStation Mobile provides a batching implementation, but it is integrated with a higher-level scene interface. That is a great help to people who are doing new game development, but for someone like me who already has a game engine that I'm trying to put on top of PSM it doesn't work. Fortunately, I've written sprite batching systems before, so it wasn't too much of an obstacle.

Then it was off to the races. Input was easy. I've already integrated with multiple touch systems, so PSM touch input went in smoothly. I haven't done buttons/thumbsticks yet, but I don't anticipate too much of a challenge. Sound was easy - the PSM audio interface is clean and exactly what you look for.

I started working with PSM yesterday, and I had my first game (my ubiquitous test game "Sokoban for Beginners") running in the simulator this afternoon. With that validation, I pulled the trigger on a PlayStation Mobile publishing license. After a few hours and a bit of messing about with publishing and application keys, I had a game running perfectly on my Vita.

Look for some "Ascent of Kings", "Quiet, Please!", "Kung Fu FIGHT!" - and just maybe a bit of "Tunescape" and more speculatively some "Block Zombies" on a PlayStation Mobile device near you.