Custom Font

[yougotwill]

I started messing around with the theme options (awesome work btw) and I thought it would be cool if we could use a custom font for the UI across the app.

I'm aiming to make a https://poolside.fm theme for Aural. Having a custom font option would make it perfect 👌

[kartik-venugopal]

Haha, dude, I think you have extrasensory-perception or something 👍 coz you read my mind ! BTW, glad you liked the custom color scheming. This is the first piece of feedback confirming that that feature actually works :) Thank you.

EDIT - I'd be happy to include your new Poolside theme in the next release.

The idea of custom fonts has been in and out of my mind for quite a while now ... the other thing is customizable keyboard shortcuts. Clearly, power users like their personalized shortcuts !!!

What has stopped me from implementing custom fonts so far is only 1 thing ... when I changed the app-wide font (in v2.0) from "Gill Sans" to "Player", I realized that, because each font's individual character dimensions are different, and plus, the user is allowed 3 different preset font sizes, it requires a lot of testing to ensure that all the different windows / panels / labels, etc look good with a new (untested) font and in all its preset sizes.

I suppose that if we let users choose their own fonts, it'd be up to them to ensure that all the interfaces look ok with the font. Another option is to limit which windows / dialogs use the new font, keeping the others (like Preferences window) using the standard font and unmodified by the custom font. Thoughts ?

---

BTW, I haven't really put this out there, but I am working on version 3.0 in the new branch "rich-ui". If you want a sneak peek of it, you can clone the branch and run the app, but of course it's under heavy ongoing development, so keep in mind bugs and incomplete features.

Here's a screenshot of an idea of what's to come ...

---

Before I forget, can I ask you 1 - which macOS version and 2 - what kind of hardware (Macbook or iMac) you are using ? During coding, I have run into some new APIs that are only available >= HighSierra or Mojave. It is not an urgent thing, but I am considering using newer APIs for some stuff at some point (for ex, the playback scheduler till Sierra requires some really ugly code to detect end of file), which would require me dropping support for Sierra.

Also, if I had a better idea of what kind of hardware (particularly CPU cores) my users use, I could optimize the code better. Some of the code is heavily multi-threaded, so knowing this kind of thing about the target machine would help. Ideally, I'd like to collect hardware and macOS version info from all users (letting them know, of course). But, if I could just collect one piece of data, that'd still help. Thanks in advance if you can provide me this info !

EDIT Also, if you could share 3 - what file formats do you use most ? MP3, AAC (as .m4a), FLAC, WMA, etc. This would also help. Aural Player v3.0 will be able to decode pretty much every known audio format (thanks to ffmpeg).

[yougotwill]

Hey man, great minds think alike I guess ;) The colorscheme system is great! I started with a simple theme because I was too lazy to go through all the options but the work is impressive!

It would be awesome if you included the Poolside theme in the next release it's super simple actually I just used the "White blight" colorscheme and changed the background to the Poolside color! I also think customisable keyboard shortcuts would be great but it's not the biggest priority for me so no pressure!

Regarding fonts, your problem makes a lot of sense. My thoughts are this.

1. Currently the theming doesn't seem to affect the preferences window or dialog windows (assuming not a bug)? I think custom fonts can stay in that same domain as I think most users only care about the front-facing UI (hope that makes sense).

2. I don't think it's necessary for you to have to account for all fonts. I think maybe you should offer a few fonts that you have checked before hand that can appeal to various users. For example the current font, a more programmer like font, a more wavy (hand writing font), etc. The user can then toggle between them.

On top of that if possible give the user the option to load their own custom font but warn them that things may break. With that in mind I would have a dialog that appears that asks them if they wish to revert the font immediately after changing it just in case the damage makes navigation difficult (hope that makes sense again sorry!).

Next, the rich-ui system looks slick! I do hope it is keeping the Winamp like modular approach though, it's a cool aspect of your app!

Regarding my mac, I'm running macOS 10.14.6 (18G6020) and have no plans to upgrade to Catalina any time soon! My hardware is:

MacBook Pro (15-inch, 2018) Processor Name: Intel Core i7 Processor Speed: 2,6 GHz Number of Processors: 1 Total Number of Cores: 6 Memory: 16 GB

(Whew, still going) Last but not least the file formats I used are mainly MP3, AAC, FLAC and AIFF (but I can't remember if I have played that filetype in Aural yet).

Finally, regarding getting user device info... Personally I would prefer if you had an option where we can choose to send it to you anonymously (think bug report) instead of opting in to something that happens automatically and out of my control behind the scenes.

That should be everything I think! Let me know if I can be of any more help!

[kartik-venugopal]

Awesome, thanks for all the suggestions and system/usage info ! 👍

Your approach to solving the custom fonts problem sounds perfect to me - offer a few "tested" font options that are guaranteed to look good, and allow the user to use their own with the caveat that they need to check how it fits in the UI, with the option to revert it. And yes, this would only affect the main app windows, not the auxiliary ones. This is now on my TODO list.

---

About the new release, here's my dilemma, and I hope you can share your valuable opinion on this ...

I had initially envisioned that v3.0 "Rich UI" (which I am working very hard on, as we speak) would replace the old Winamp-style UI and be more "modern", similar to Apple's own Music app or Dopamine on Windows, i.e. the classic player would stay at v2.2, and the new player would kick off with v3.0." The obvious downside is that the classic UI would no longer benefit from new feature updates / bug fixes.

The other option is to have 2 separate branches (or even repositories) and release new features from both, ... the new player would be v1.0 of "Aural Player Plus" or something like that, but that seems like a LOT of maintenance work. 😢 Frankly, I don't know if I can do it. This is coding, commenting, documenting, testing, maintaining, bug fixing, etc.

I strongly prefer the first option - keeping everything in the same repo. That way, all the issues, all the history, etc. will stay in one place, and I don't have to duplicate a lot of back-end work.

Now, I understand that people love the Winamp modular style approach (me too) and that is why I developed it that way in the first place. So, my question to you is - how important is the modular structure to you ? Would the new player's views (listed below) be a good enough compromise, so that you still have some control over window layout ?

That said, the new UI would offer a few different views ...

1 - The default "unified" view that I showed you a screenshot of, earlier.

2 - A thin floating "player bar" view that would extend horizontally and just show the player controls and current track (i.e. the topmost section of the default view), which you could for instance place at the bottom of your screen and have something else on top like whatever work you're doing or a web browser, so that you could control Aural easily while doing your work. (See image below)

3 - A "compact" view that would somewhat resemble the current Winamp-style layout but only contain player controls, current track info, and the play queue (see Apple Music screenshot below).

So, would this ^ be good enough for you ? Or would you strongly prefer the Winamp-style UI ?

[kartik-venugopal]

BTW, I was just thinking - there is also a 3rd approach to solving the problem mentioned ^ above.

Like you and I, I'm sure many others would love to keep the modular layout, so I might be able to find a way to keep both layouts in v3.0 and allow the user to toggle between the modular and other layouts. It will require more work, but might be worth it and please more potential users.

Of course, the modular layout's display of tracks would now be slightly different, because the new player's data model will now also consist of a "library" (plus a play queue, plus several potential user-created playlists), whereas the old player only had one "playlist" from which tracks were played.

In short, I will think of a way to keep the old Winamp-style layout in the same new player, with slight modifications to how tracks are displayed. The simplicity of drag-drop-play will remain, of course (in either case), as it is the motto of this player.

[yougotwill]

Hey sorry for the delay.

Your approach to solving the custom fonts problem sounds perfect to me - offer a few "tested" font options that are guaranteed to look good, and allow the user to use their own with the caveat that they need to check how it fits in the UI, with the option to revert it. And yes, this would only affect the main app windows, not the auxiliary ones. This is now on my TODO list.

This is great news!

I had initially envisioned that v3.0 "Rich UI" (which I am working very hard on, as we speak) would replace the old Winamp-style UI and be more "modern", similar to Apple's own Music app or Dopamine on Windows, i.e. the classic player would stay at v2.2, and the new player would kick off with v3.0." The obvious downside is that the classic UI would no longer benefit from new feature updates / bug fixes.

The other option is to have 2 separate branches (or even repositories) and release new features from both, ... the new player would be v1.0 of "Aural Player Plus" or something like that, but that seems like a LOT of maintenance work. 😢 Frankly, I don't know if I can do it. This is coding, commenting, documenting, testing, maintaining, bug fixing, etc.

I strongly prefer the first option - keeping everything in the same repo. That way, all the issues, all the history, etc. will stay in one place, and I don't have to duplicate a lot of back-end work.

Now, I understand that people love the Winamp modular style approach (me too) and that is why I developed it that way in the first place. So, my question to you is - how important is the modular structure to you ? Would the new player's views (listed below) be a good enough compromise, so that you still have some control over window layout ?

To give you my personal opinion the modular UI of your app is one of it's big selling points to me as a user. If you dropped the modular stuff and just kept the rich UI then there isn't much that differs from me using Iina as my music player for example. I would also then be more strict when comparing the performace of Aural to other music players. The modular UI makes me more forgiving ;)

That said, the new UI would offer a few different views ...

1 - The default "unified" view that I showed you a screenshot of, earlier.

2 - A thin floating "player bar" view that would extend horizontally and just show the player controls and current track (i.e. the topmost section of the default view), which you could for instance place at the bottom of your screen and have something else on top like whatever work you're doing or a web browser, so that you could control Aural easily while doing your work. (See image below)

3 - A "compact" view that would somewhat resemble the current Winamp-style layout but only contain player controls, current track info, and the play queue (see Apple Music screenshot below).

So, would this ^ be good enough for you ? Or would you strongly prefer the Winamp-style UI ? I would prefer the Winamp-style UI but I understand why you are moving towards the rich UI. Ultimately I think it's up to you to decide the direction you want the app to go. Mac users certainly need an alternative to iTunes / Mustic.app and having just the rich ui makes the project more maintable.

I don't know if it's possible at this point but could you make the rich ui components out of the modular system and then just lock them in place? Alternatively as you suggested keep both UI options available? But I think that would be a lot of effort with little return.

Let me know if my answers are unclear or need clarification.

Finally, I just wanted to say that the rich UI looks beautiful and is very slick! So I appreicate the hard work! It's just that the winamp nostalgia is so powerful lol.

[kartik-venugopal]

It's honest opinions like these ^ that I wish I had more of. I have been developing this app almost totally blind so far, restricted by the limited hardware/software platform(s) at my disposal, not knowing what others think or how they experience the app once they download it.

Anyway, you've made it very clear for me ... I will keep the modular layout and offer the rich UI as a new feature.

Just wanted to clarify one thing you said ...

could you make the rich ui components out of the modular system and then just lock them in place?

Do you mean separating the rich UI to an (external) app module ? Also, what did you mean by locking in place ?

If you mean create a separate module, I have something similar in mind. Only, I won't separate the UI, I'll "factor out" the back end so that it can cater to both UIs in an agnostic way, not only for the 2 current UIs but potentially any new view added in the future.

Last but not least, I feel like GitHub issues are a very limited channel of communication. It is unrealistic to have an issue filed for more informal / frequent discussions.

I wanted to ask you if you'd be open to communicating through a different channel (email or messenger), about this app ... if and when I have a question for you or want your opinion or perspective on something ? Like if I wanted to get your feedback on some new feature I'm developing, I could leave you an email/message and you could reply at your own leisure ? Github issues aren't really suitable for this kind of communication. You can still file Github issues when needed, of course.

If you'd rather not ^, I totally understand and no worries.

Thanks again !

[yougotwill]

It's honest opinions like these ^ that I wish I had more of. I have been developing this app almost totally blind so far, restricted by the limited hardware/software platform(s) at my disposal, not knowing what others think or how they experience the app once they download it.

Glad to be of help! Tbh if I had apple dev knowledge I probably would have made some PRs by now. Sadly I'm mainly web dev.

Just wanted to clarify one thing you said ...

Sorry I didn't word that very well. Basically I was suggesting breaking up the components of the new rich ui into modules. Then when you toggle the rich UI option in the settings it lays out the components on your screen like how it is shown in your screenshots. This could use the existing components that you have made or the new ones based on the rich-ui branch as suggested.

Also, what did you mean by locking in place ?

I meant making the UI look seamless (as it looks in the screenshots) instead of the current UI where you can see each module has a little margin around it.

If you mean create a separate module, I have something similar in mind. Only, I won't separate the UI, I'll "factor out" the back end so that it can cater to both UIs in an agnostic way, not only for the 2 current UIs but potentially any new view added in the future.

If you could do this that would be amazing! My ideas (nonsense) above is a worse solution but was intended to minimize how much work you would need to do in the future.

I wanted to ask you if you'd be open to communicating through a different channel (email or messenger),

Feel free to email me at yougotwill94@gmail.com, it's my public email on my GitHub profile. Happy to talk about things!

P.S. Looking at the rich-ui, I do hope you can use a table like layout for the tracklists because that makes filtering/finding songs a lot easier. Having single cells with all the track information makes filter and searching difficult IMO.

[kartik-venugopal]

Thanks for sharing your email. I'll drop you a line when I have questions only an avid user can answer :)

The Rich UI is very much in its infancy. It will no doubt undergo revisions as requirements and constraints become clearer. I will definitely ensure that all views make it easy to filter / search / sort tracks.

table like layout for the tracklists because that makes filtering/finding songs a lot easier.. Having single cells with all the track information makes filter and searching difficult IMO.

^ Do you mean the user scanning manually with his eyes or the app searching table rows ? Each cell has a backing Track object, so even if the info appears clumped into one cell, filtering / searching will be easy for the app. If you're talking about the user doing a scan with his eyes, then yes, having the info clumped together may make it more challenging for a user to parse out info quickly with his eyes.

In any case, like I said, the UI is very much a quick n dirty prototype at this stage. I threw together something that I thought looked good. That is something that will no doubt be a priority when developing the "Unified" interface aka Rich UI - looks / aesthetics.

[yougotwill]

Sorry again for my wording. Yes I do mean for scanning with your eyes. Basically like in iTunes where you have title, artist, album, genre, etc and if you click on the heading it sorts it accordingly.

It terms of making it 'look good' there may be better solutions out there that I am unaware of. I look forward to seeing your progress on it!

In the mean time, back to the main topic of this issue... custom fonts would be great when you get the chance! Thanks :)

[kartik-venugopal]

Yes, I have definitely noted down custom fonts and will get it done. I will keep this issue open till the feature is released.

Just keep in mind that because there is already such a huge backlog of work for the 3.0 release ... i.e. everything we discussed, plus all the testing ... custom fonts may not make it out in v3.0. But if not, then certainly v3.1 or 3.2 which will shortly follow. (I try to keep each release manageable in terms of testing).

[kartik-venugopal]

Hi @yougotwill,

I was able to squeeze in some time to work on Aural, after a long break. And, I thought you might be interested in seeing the following 4 images, representing the "Standard", "Programmer", "Novelist", and "Gothic" fonts, i.e. the work you wanted done has begun ... I don't know when or if it will be finished, but at least it has begun :) This is the absolute infancy stage ... nothing firm yet. So this is just a sneak peek of what is possible.

On a more personal note, hope you are staying healthy and safe and prosperous through this challenging time.

Standard

Programmer

Novelist

Gothic

[kartik-venugopal]

The requested feature has now been released: Download from here.

This issue is now closed.

[yougotwill]

Thank you so much for your work on this @maculateConception !

[kartik-venugopal]

You're welcome. BTW, I even did some research and determined that the font used in your Poolside.fm scheme is called "Chicago". I put together a Poolside.fm scheme on my end, but didn't release it .... I was actually debating whether to add another complementary feature "themes" which would combine a font scheme + color scheme into one theme.

That never materialized ... but now you can definitely create your Poolside.fm scheme in 2 easy steps :)

If you're still interested in the Poolside.fm scheme ... perhaps you can help me determine the exact colors (background color, sliders color, text color) ... since you're a web developer, you can express the scheme as hex colors. I can release it in 2 parts: a font scheme and a color scheme.

[yougotwill]

Funny you say that. I did the same thing! Loaded Chicago manually on my side. I think adding themes would be great! Alternatively you could add something to the GitHub wiki as an example.

I can send you my theme file with the correct colours if you like? On 06 Apr 2021, 14:28 +0200, maculateConception @.***>, wrote:

You're welcome. BTW, I even did some research and determined that the font used in your Poolside.fm scheme is called "Chicago". I put together a Poolside.fm scheme on my end, but didn't release it .... I was actually debating whether to add another complementary feature "themes" which would combine a font scheme + color scheme into one theme. That never materialized ... but now you can definitely create your Poolside.fm scheme in 2 easy steps :) If you're still interested in the Poolside.fm scheme ... perhaps you can help me determine the exact colors (background color, sliders color, text color) ... since you're a web developer, you can express the scheme as hex colors. I can release it in 2 parts: a font scheme and a color scheme. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[kartik-venugopal]

Cool. So, assuming you have already created your Poolside color scheme and font scheme (using the "Customize ..." option which brings up the editor dialog), just quit the app (if running), and send me your app's persisted state file from the following path:

If using v2.2.0 or older, /Users/(YourUsername)/Documents/aural/state.json If using v2.3.0 or newer: /Users/(YourUsername)/Music/aural/state.json

You can open this file to see what info it contains ... it's basically all your Aural Player app state (playlist tracks, color schemes, font schemes, window layouts, etc.). There won't be any private / identifying data in it. If you want, you can just send me the "fontSchemes" and "colorSchemes" elements from the file ... or the whole file if you're satisfied that there is no data you don't wish to share.

(That said, it would actually be quite insightful if you sent me the entire file ... because the settings values in there will give me a lot of insight into how my baby is being used by a real user :D )

This ^ will be the best way for me to go about creating your Poolside theme (both the fonts and colors) ... including the font sizes for the various elements and playlist row centering offsets, etc. Your font scheme encapsulates all this stuff.

Thanks dude ! So, I am currently working hard on v2.10.0 (an unrelated feature - Audio Units plug-ins support), but themes will be v2.11.0, with Poolside.fm being the demo theme. Sound good ?

[yougotwill]

Sounds good to me! I have emailed the state.json file.

[kartik-venugopal]

Hi @yougotwill,

I implemented your Poolside.fm theme, and there are a few minor issues with the colors you selected, but nothing that cannot be overcome. I just wanted your opinion on which solution you would prefer (perhaps the one that deviates the least from your original theme).

The problem is that there is no contrast between 1 - the color of the icons displayed in certain playlist rows and 2 - the playlist row selection box color, i.e. they are all black. So, when the user selects either a group (any group) or the currently playing track, those icons are completely eclipsed by the row selection box which is also black. See images below:

PS - Ignore the font (I haven't applied the Chicago font in these pictures ... that will be done for the theme.)

So, there are 2 obvious solutions to the problem, and I wanted to ask you which one you'd prefer:

• Change the color of the selection box from black to a lighter color
• Change the color of the various icons (playing track indicator, group, disclosure triangle) to a lighter color

Until I hear back from you, I'm going to go with the 2nd solution (changing icon colors) because that deviates least from your intended theme, leaving the selection box black.

This is what the solution I've opted for looks like:

Let me know what you prefer. Thanks !

[yougotwill]

Hi @maculateConception I prefer the second option! Hopefully that doesn't break anything for the other themes. In additional if it's possible setting an "icon" color for icons across the theme would probably be the best solution. The default being the second solution above :)

[kartik-venugopal]

Thanks, will go with the 2nd option.

No, the other themes will be fine. The way the themes I designed work is that if you look at White Blight, the row selection box (gray) is of an intermediate color between the window background (almost white) and icons (almost black). That avoids this kind of problem. The row selection box offers contrast with both the window background at one extreme of the spectrum and the icons at the other extreme. But, it's not a big deal ... I actually like your choice of black for the selection box color ... looks great against the pink background.

if it's possible setting an "icon" color for icons across the theme would probably be the best solution.

By this, do you mean giving the user an option to change just one color and apply it to all the icons, as opposed to having to select the same (or similar) color multiple times for the different icon color settings ... I assume for the sake of convenience ? Keep in mind that there is a color clipboard in the editor dialog that facilitates copying / pasting the same color and applying it to multiple settings.

That said, if you clarify what you mean, I can go ahead and implement it if it's feasible.

PS - I really appreciate your time in helping me work through all these issues and providing valuable feedback. I don't take it for granted.

[yougotwill]

No, the other themes will be fine. The way the themes I designed work is that if you look at White Blight, the row selection box (gray) is of an intermediate color between the window background (almost white) and icons (almost black). That avoids this kind of problem. The row selection box offers contrast with both the window background at one extreme of the spectrum and the icons at the other extreme. But, it's not a big deal ... I actually like your choice of black for the selection box color ... looks great against the pink background.

I see. Wish I could take credit but that is straight from Poolsides design.

By this, do you mean giving the user an option to change just one color and apply it to all the icons, as opposed to having to select the same (or similar) color multiple times for the different icon color settings ... I assume for the sake of convenience ? Keep in mind that there is a color clipboard in the editor dialog that facilitates copying / pasting the same color and applying it to multiple settings.

Yes, that is what I meant and it was for convenience. Tbh Aural already has so many settings going on it can feel overwhelming at times. Possibly future fix would be to have a toggle for "advanced settings" just to clean things up a bit across the app.

PS - I really appreciate your time in helping me work through all these issues and providing valuable feedback. I don't take it for granted.

All good! I appreciate this project and your hard work. Also ... I have a little too much free time on my hands 😅

[kartik-venugopal]

Yes, that is what I meant and it was for convenience. Tbh Aural already has so many settings going on it can feel overwhelming at times.

Wow, ok, this is good to know ... I didn't think of it before, but I see what you mean. The app settings have gotten complex over time as more and more functionality has been added.

Can you point to specific examples of which settings feel overwhelming ? Sorry, I'm asking a lot of questions ... but since this is feedback from a user, it needs to be taken seriously. I would like to know some details so that I can come up with a concrete solution in the future. EDIT - This is not urgent (will need some time to design / implement), so you can answer this at a later time whenever you have some time.

Possibly future fix would be to have a toggle for "advanced settings" just to clean things up a bit across the app.

I was actually thinking of doing something similar just for Color Scheme settings ... having 2 tabs in the editor dialog: Easy mode, which will ask the user for only a few colors, and construct an entire scheme from those few colors. And an Advanced Mode which currently exists. Just like you suggested. I will note this down for the future.

I feel that to give the user maximum control is one of the philosophies of the app (i.e. "customizable"), but thanks for the feedback. I will definitely consider dividing the settings into Easy / Advanced modes.

As for the color scheme icon colors, I want to wait before rushing into a quick fix ... in fact, now that you've given me feedback about the settings, perhaps the icon colors change should be part of a larger more overall change in how settings input is collected from the user, to make it less cumbersome / overwhelming ... and that change needs to be well thought out and designed.

Thanks again !

[kartik-venugopal]

@yougotwill

Released !!! https://github.com/maculateConception/aural-player/releases/tag/2.11.0

BTW, I gave you a little honorable mention on the release page and on the main README page for all your contributions to the project. Hope that's ok ?

https://github.com/maculateConception/aural-player#contributor-attributions

[yougotwill]

I'm honored. Thank you very much! And congrats on the new release 🚀