Sunday, February 18, 2018

3.0 Work in Progress 15: Playlists View

Here is a look at the new playlists UI.  Like most of the other views it has some sort options (playlist list only so far.. not when editing the actual playlist) and the ability to be a regular list or a card list.  Also notice in the screen shot below how I threw all the views together as tabs.  The default UI will only contain the library type views as tabs but I designed things in a way where its only a single line of code to just throw whatever view in as a tab.  Also note in these screenshots and the video the album art in the mini player is a bit messed up.  I'll work that out before the first alpha release. 


The context menu right how has the standard play, play next, and enqueue.  At some point I will add an edit option as well (which would allow an option to play the playlist on item selection instead of having to use the context menu)


When selecting a playlist it will open up the edit view which supports the drag and drop like the queue.  Right now its still press and hold to drag items around but there will also be an option to add a handle instead (similar to 2.x).


The playlist will auto save when backing out of the edit view, but I would like to make this optional down the line.  With auto save off there would be a manual save and revert menu option.  One of the reasons I have been hesitant on adding sorting options when viewing the playlist contents is specifically because of the auto save.  I felt that users would be annoyed if they went to sort their playlist to help look for a song, only to find they completely lost their song order.

One minute addition I made is the ability to save wpl playlists.  In 2.x when a user would edit a wpl playlist, it would be replaced with an m3u.  Now it will just modify the original wpl file.

Finally here is a video of the playlist ui.


The playlist UI only took a day or 2 to finish, so I've already started on the next task of implementing all the remaining context menus and list item press actions (I had previously only done a few for demo purposes).  I have also been leveraging RxJava2 to move almost all the actual work for the UI (like grabbing all the songs of an album from the database before playing) off of the UI thread (which would help with responsiveness and prevent freezes). 

Wednesday, February 7, 2018

3.0 Work in Progress 14: Equalizer and Effects UI

Before I get into the new UIs, I want to mention some of the behind the scenes work that has been done since the WIP update.  I mentioned in the last blog post that I completely rewrote the DSP / Effects backend (everything besides whats in the audioengine).  Since then I also ended up replacing the theme engine with a library called Aesthetic.  It was pretty similar to the custom theme engine I had written before, but I felt it was better written and had other users maintaining it which is always a plus.  It also was backed by RxJava2 which is something I've been using throughout the 3.0 rewrite and it makes changing theme colors on the fly much easier than my custom theme engine.  I did a massive cleanup and restructuring of the gmmp project.  I removed all the legacy code that has been rewritten and have split up the project into 4 main modules (this is done for much faster compile times): common, data, playback, ui/main.

When I look at the breakdown of languages used on my gitlab we see these numbers

Java 67.93 %
Kotlin 31.72 %
RenderScript 0.35 %

So despite all the stuff I have rewritten, about 2/3rd of the non audioengine code has still not been touched (all the 3.0 work was done in kotlin).  I dont have any plans to rewrite everything but it just shows how large the project has become over the last 7 years


I decided to split the equalizer into its own view and have the other effects on a separate tab.  I did get a lot of complaints about having to go through a lot of steps just to get to the equalizer.  It is much more accessible now.  Also on the effects UI, I added switches for each effect and sliders for anything that can be adjusted.  Previously some things like bass boost strength, and limiter attack/release were hidden away in the preferences.


I still have a bit of testing to do to make sure all the effects actually are being applied correctly, but from the UI standpoint things are pretty much where i want them to be.




Next up will be the playlist file UI which should be pretty straight forward

Wednesday, January 10, 2018

2018 Plans

Now that the holidays are over I thought I would share my plans for this year and discuss the current state of 3.0.  For those not aware, I track all my active development, future development, and feature requests on trello here: https://trello.com/b/JCyp2kas/gonemad-music-player-development  To see my current progress on 3.0, the ones you want to look at are "3.0 - Alpha 1", "3.0 - In Progress", and "3.0 Complete".

Anyway I just finished up rewriting all the Dsp / Audio Effect management code (essentially everything dsp/eq related that was NOT in the audio engine).  There have been some long standing bugs like the equalizer not applying on startup or the bass boost not being applied until you toggled it off and on that I really hope will not be present in this rewrite.  My original intent with 3.0 was to just rewrite the UI, but I ended up rewriting a lot of the backend in the process.  Tons of the old code was written 6-7 years ago back when gingerbread was present so it had a lot of unnecessary and/or deprecated code in it.  I am also a much better engineer than I was back then so being able to completely redo entire systems has led to a much more efficient and easier to maintain baseline.  The downside is that its taking much more time than I originally planned.

If you look on trello, the 3.0 lists show about 15 remaining tasks before I can release the first alpha.  I will try to estimate how long I think they will take so you guys can get an idea when the first alpha might be released.  Keep in mind my estimates are most likely the best case scenario..  I only get around 12-20 hrs a week (depending on how I spend my weekends) to do android dev, so the odds of this taking longer than I estimate is pretty high.  Sometimes I miss the early days of GMMP when I was able to get 40-50 hrs in a week.

Remaining tasks for Alpha 1 (summarized):

  • Equalizer / Effects UI - Most of the hard work was already done with my recent dsp management refactoring so this task is just pure UI development.  ~ 2 weeks
  • Playlists UI - I already rewrote the playlist file handling 2 months ago and the playlists UI is pretty straight forward in general. ~ 1-1.5 weeks
  • Navigation - Nothing has really been done yet with the side navigation drawer and to efficiently handle swapping back and forth between the different views.  I anticipate this being a pretty large task.  ~ 3-4 weeks
  • Landscape Support - Most of the UIs are pretty usable already in landscape, so this will probably be just designing the landscape version of now playing (for alpha 1.. i definitely plan on optimizing all UIs for landscape/tablets before the final release).  ~ 2 weeks
  • Preferences UI - Will be pretty simple to start (will go into more detail on preferences later) ~ 1-2 weeks
  • Action hookup - A lot of the menu options / gestures / etc are not completely set up.  I finished the frameworks and implemented a few actions for demonstration, but thats it.  ~ 1-2 weeks
  • Bug fixes / Testing before release ~ 3 weeks

Remember this is a best case scenario and if I get emails or questions asking for an ETA, my response is going to be "when its done" (this is my typical response anyway since estimating time is very hard to do.. a single bug can consume weeks before finding a resolution).  If we add up my estimates and look at the current date I would guess the first alpha release will be sometime in April.  As mentioned before the Alpha will be ran through a separate google+ community from the beta.  A lot of people in the beta do not actually frequent the g+ page, so I do not want to push an update to the beta channel until I have restored all the features / customizations from 2.x (or well.. all the ones i plan on restoring).

GMMP will most likely be in alpha for awhile.  There are still a huge list of capabilities to readd and new ones I want to add (check trello).  For customizations I think I will be taking a different approach this time around and not just load everything up in the preferences UI.  Almost all the UI based customizations will be accessible from the toolbar menu in the actual UI.  This should make customizing the UI much faster and easier.


Betas will come once all the features and customizations are complete.  It will be strictly for bug fixes and minor tweaks, so depending on how good of a developer I am.. this period may be short.. or long depending on how many bugs pop up. 

In summary, the 3.0 final release is still a long way off, but I think a usable alpha version will be available in a few months.  Also keep in mind that 3.0 isnt just a pure rewrite.  I have been adding new capabilities as well (multi genre / artist support, new loudness enhancer audio effect, grid view, bookmark ui, improved shuffle, and permissions) and more are planned (auto dj mode, true album shuffle mode, artist images, app shortcuts, song details view, and year view).

Wednesday, December 20, 2017

3.0 Work in Progress 13: Cuesheet improvements

Most of the work I've done since the last post has been behind the scenes so there is not too much to show.  I rewrote the audioengine management piece (what handles the interaction with gonemads audioengine, android media player, and chromecast), rewrote the crossfade code, and cuesheet handling.

Cuesheets are something that the majority of gmmp's user base probably does not use https://en.wikipedia.org/wiki/Cue_sheet_(computing), but they are a nice feature.  For those who do not know, a cue sheet allows you to listen to a single large audio file as if it was split up into tracks for each song.  GMMP has always had decent support for CUE files (they would appear as individual tracks in the library views), however in the folder browser they would just appear as a .cue file and the single mp3 / audio file. 

In 3.0, the folder browser will actually extract and list the individual tracks in a CUE instead of the single file.

Below is what the actual folder on disk looks like.  This example is a single cuesheet with 5 separate hour long mp3 files (its a electronic/trance mix i believe).

Folder view from solid explorer

This is how it will now appear in GMMP 3.0



Cuesheets can also be embedded into the tags of files.  GMMP supports that as well



Next up will be the new equalizer / effects UI.  I will most likely also rewrite a lot of the underlying DSP/EQ code as well. 

Friday, December 1, 2017

3.0 Work in Progress 12: File Browser UI

Next up on the new UI list is the file/folder browser.  I also rewrote the file/playlist handling on the backend to be much more streamlined.  A lot used to go on when playing folders and i've greatly simplified that.  As always, the file browser will show anything on the file system and does not care if its in the database or not.  This is great for navigating, but caused a lot of issues when a user went to play a file or folder.  I am sure some were familiar with the issue where songs would "disappear" from the queue after reloading GMMP.  This was because the user played a file that was not scanned into the database.  GMMP would play the file fine in the queue, but when the queue was persisted to the database those files were lost.  In 2.x GMMP would try its best to get everything scanned in by running silent scans of folders as you navigate into them.  While being pretty inefficient, it worked for the most part.  The big issue happened when a user would select a folder to be played and that folders contents were not scanned it.  GMMP did a bunch of stuff to account for this, but in the end it was very hacky/ugly and really bloated the codebase.

This time around for 3.0 I came up with a much better approach.  The new UI / data backend has some nice capabilities like auto updating when its backing data in the database changes.  Now when a file is played, GMMP will look to see if its in the db, if not it creates a placeholder on the spot.  The placeholder just contains the filename and a track id which is all that is needed for putting a song in the queue.  If any placeholders were created, gmmp will then run a scan to populate all the placeholders with the information from the tags.  Any UI that was displaying the placeholder will auto refresh and show the tag metadata.  So now there should never be a case where files are lost from the queue on restart.

New UI (I switched up the theme colors just to add some variety to the screenshots)


At the top is the QuickNav which is scrollable horizontally and each folder is clickable to instantly jump back up a few folders (the video below will show this).  Like every other list item, the metadata shown is customizable.  In this screenshot below the first item is a playlist which is just displaying its filename and the items below that are showing the song name and duration.



I plan on adding the ability to highlight the currently playing track (i also think i can add that ability to the library views. I know this is requested often).


Sunday, November 19, 2017

3.0 Work in Progress 11: Bookmarks, Chrome OS, and Permissions

I recently picked up one of the new Google Pixelbooks and I will say it a pretty awesome development device.  It runs Chrome OS, Android, and Linux all at the same time and has pretty good specs (i5 cpu, 8 gb ram, 128 gb ssd) for running Android Studio.  I am able to code and deploy GMMP right on the same device which makes development really convenient when not at home.   Android apps also run in their own window which can be resized which makes UI testing on different size screens super easy.

Ignore the artifacts around the window containing GMMP.  It is a side effect of taking a screenshot i guess (it appears fine on the device)
In order to support the free form resizing of the app window, I updated the target SDK level to 27 (android 8.1).  GMMP 2.x was still on 21 (android 5.0).  The target SDK update should see some performance improvement in newer devices (although i do not know by how much).  I also added support for the android permission system they added back in 5.1.  GMMP should only ask for storage permission and possibly phone state permission (if you want to use the auto resume after a phone call finishes feature).


Anyway, the main focus of WIP 11 is bookmarks.  In the process of refactoring / rewriting the MusicService, I rewrote the Bookmarker and added a UI to show existing bookmarks.  All of the previous work I spent on creating common, reusable UI components is really paying off.  Adding a functional bookmark list UI only took roughly 15 to 30 minutes.  Similarly the Artist and Genre details UIs I showed in WIP 10 took about the same amount of time.  Since its so quick to add these UIs, I can see myself adding a bunch of optional views for some other fields like year or composer (and making 2 separate UIs for artist / album artist if the user wants to have both easily accessible)


The bookmark list will show all the currently bookmarked tracks and let you play them directly from the list (or delete them).  Like every other view i've shown in 3.0 so far, the metadata will be customizable.  For this post I just had the list items show song name and bookmarked time.  For the video below I set it up to just auto bookmark everything, but the previous bookmark settings will still be there in 3.0 (auto bookmark based of song length, m4b extension, or by folder). The video will show the song auto bookmarking when changing tracks, and then resuming at the same position when returning to the song.  It also shows the manual bookmarking and unbookmarking of the currently playing song.


My focus next will be creating a folder UI.  The folder UI is a bit more complex than the other UIs (besides maybe now playing) so I imagine its going to take awhile