The MIDI transcriber kind of fizzled.  It felt like the lion kingdom spent all of Nov & Dec charging hard on it, motivated by the peanuts xmas song.  Once xmas was over, the motivation went away again.  There was never a lot of motivation to transcribe music.  The only other desired transcription was the Contact theme music.

The mane remaneing features are page navigation & rendering bitmaps suitable for the reader program.  It would just screencap the X11 output.  

The big need is a forensic audio player, which lions are assured there is no existing app for.  Progress being what it is, loading a complete sound file into RAM & drawing the waveform from RAM isn't the herculean task requiring temporary files it used to be.  For transcribing, a spectrogram is probably a better deal than a waveform.  It would require storing multiple zoom levels in RAM, developing load & save dialogs, storing a persistent state.

----------------------------------------------------------------------------------------------------------------------------------------

Despite writing many hacky phone utilities, lions have been kind of turned off from developing anything more substantial on a phone because every phone app, framework, or example code lions have ever downloaded is a crippled, ad spewing, bug ridden, steaming pile of dog turd.  It's the kind of software once described as written by script kiddies.

Then, simple operations in android have proven incredibly difficult compared to bare metal C.  Doing the simplest thing on a phone requires crazy complexity, many frameworks, permissions, factories, persistent state routines.  It's in no way compatible with the minimalist apps being developed on it.

It might be smarter to upgrade the whole thing to a 4k monitor on a single raspberry pi instead of expanding the nest of phone apps.  But a phone app could also be grown into a longer term need for a decent music player.  The big needs are recursive playlists & soft gain.

---------------------------------------------------------------------------------------------------------------------------------

https://hackaday.io/project/162944/log/200787-tracking-robot-evolution

Lions previously used ffmpegkit to try to stream realtime H.265 video from a raspberry pi to the phone.  There was an acute need for it to be realtime, but ffmpeg would always delay it, no matter what.  This led to degrading the codec to jpeg & eventually abandoning ffmpeg for android.

https://hackaday.io/project/162944/log/200560-death-of-ir-remotes-return-of-wireless-guis

That was quite a journey, experimenting with the VideoView widget & RTSP.  The manual steps in setting up the tracking camera required lower latency.

Since then, ffmpegkit has been replaced by Android's own MediaExtractor class.

--------------------------------------------------------------------------------

https://github.com/heroineworshiper/soundinspector

The sound inspector program went together eventually & lions forgot about it.

 The mane feature was a spectrogram of a complete sound file which you can pan & zoom around, play repeatedly from a precise starting point.  The mane problem was decoding & converting the file in a reasonable amount of time.  The decoding goes really fast.  The calculation of the spectrogram goes in parallel on all the cores, asynchronous of the user input.  It manages to go really fast despite being pure Java.

The complete spectrum in the highest resolution goes in a texture.  For a 4 minute file, it's 11MB if the FFT window size is 4096, 1024 frequencies are shown, & 32 bits per pixel.

 A spectrum is simpler than a waveform, in that you're not mipmapping the complete file or reading the original audio data for every navigation event.  The spectrum allows seeing changes in areas of constant loudness, like compressed audio. Pondered how useful it would be in a video editor & what kind of temporary file it would be stored in.  Temporary files can be quite large compared to 30 years ago.  4MB was a large temporary file then.  Now, it might be 64MB.