Monthly Archives: February 2011

DaTuner Roadmap

Please note that DaTuner has been sold to Prometheus Interactive, so contact them for any support requests.

Here is a quick list of things that I want to add to DaTuner, either because I think they’d be good ideas, or because they have been specifically requested.  Some of these may only be in a paid or ad-supported version (base version would stay free and ad free)

  1. Pitch pipe.  I have had lots of requests for this and I have my own ideas for how to implement it that I don’t think anyone else has done.
  2. Update color scheme: make the point at which you are “close enough” for color change configurable via the menu.  Also give sharp and flat different colors, if set in the menu.
  3. Add +/- cents to the “error” display.
  4. Configurable bandwidth on min/max detected frequency.  The algorithm I am using ends up with heavier “likely” ratings on lower frequencies so to avoid always detecting 50/60Hz hum I have added a “minimum” in the algorithm that cuts out some calculations that would produce frequency measurements less than 70Hz.  If you are a bass guitar player, you probably would want a bit more hum detection as long as you can also detect the fundamental note on your bass guitar.
  5. Alternate tunings / Updated “note” display.  I have had requests for many changes to the note display. Taken individually, they would be relatively simple.  However, I have a job and family, and programming them all into DaTuner, which is supposed to be generic would take me a lifetime of working a few minutes a day, I figure I can perhaps do it via community supported spreadsheets that can be imported into DaTuner.
    1. Alternate tunings (ie drop-D tuning or allowing certain notes to be set at +/- a few cents)
    2. Display of “do, me, ri” instead of “c,d,e”
    3. Display flat symbol instead of sharp symbol
    4. etc…

If you are reading this and are using DaTuner and would like to suggest an improvement or vote on a change above, let me know!


Google Crash Reporting

A nice feature of Google Crash Reporting for Android 2.2+ is the fact that it exists.

A not so nice feature is that the “headline” number of crashes that a developer sees does not actually reflect the number of crashes reported.

This is why a crash that I thought I had fixed two weeks ago (array index out of bounds) still exists in the latest version.

After that bug “fix” my “headline” crash report number was consistently 6, and since it wasn’t increasing from day to day I assumed that the bug was, in fact, fixed. However, clicking on the link showed that there were many more crashes than 6.

Google, how hard is it to retrieve a number from one part of your server and place it in another part? Really?