Show HN: Nighthawk: A stealthy, simple, unobtrusive music player
github.com
github.com
As a user, I simply won’t accept it. Platform integration is suboptimal at best and resource usage is preposterous.
If this is the future of desktop software, and it seems like it is, we have got to find a better solution.
There has to be a way to share the rendering engine and Node process among the many Electron apps that are proliferating on the user’s machine.
I prefer it when one app crashes it doesn't kill a bunch of others.
For the more common solutions I think computers already have enough memory to handle this. The boot time is a bit too long but if each app uses 200-300 MB does not mean _that_ much when the computers have 8 GB or more.
Have you tried using 3 Electron apps simultaneously on 8GB machine?
I have done this, and it worked fine. In fact, I had three instances of vscode, slack, gitkraken, Spotify and headset all running concurrently on a windows machine and it didn't melt. I'm tired of this myth that electron takes 1gb per app
I rest my case.
But if you think a 5X RAM usage increase is fine I really have nothing to add.
Actually this functionality has existed on windows for about 15 years or more.
https://msdn.microsoft.com/en-us/library/ms536496(v=vs.85).a...
HTAs, or HTML applications, almost forgotten, have been available as far back as xp and possibly windows 98. They still work in windows 10, though they only support html4 and very limited JavaScript, and obviously aren't cross platform like electron.
Microsoft saw the potential in html for building apps way back in the late 90s. You used to be able to use html as a wallpaper back in windows 98, something I dearly miss.
It's also worth pointing out that uwp / windows store apps can be built in html/js, which are very small to distribute and use a global rendering engine
If they exposed Webkit and JavaScriptCore in a friendlier way, things could be different.
electron good - IDEs, markdown editors, visual git clients, things that are front and center
electron bad - music players, tray notifiers, app launchers, things that work in the background
On windows and mac I use foobar for music and greenshot for screen grabs because they use minimal resources.
The basics are simple, but if you want to do styling tweaks or anything approaching a "custom" UI, you need to start hacking away at an obscure C++ SDK or an even weirder mishmash of GDI+ and old JavaScript.
If there was a modern and easily customizable frontend to foobar2000's core audio and media library engine, I'd be in love. Something like Zeit's Hyper, but for music. I'd be willing to trade off Electron resource usage if it meant I could set up the UI just how I like it.
I am listening to full albums most of the time and don't like shuffle play at all. So I am looking over all artists / albums every time I want to listen to something different. A big plus for me is a beautiful list with all the album covers.
Same goes for desktop environment "ricing".
And none of the native solutions allow me to shape and design the UI like I want to without compromises.
Electron may not the best in every aspect. But it was the only sensible and feasible choice for what I wanted my app to behave like.
For me, a small performance hit is justified for being able to make exactly what I want.
But for windows, which i primarily use, it is better that what .Net gives me. And it apparently works flawlessly on mac.
I was quite surprised by the CPU and memory usage though. Surprisingly lean. I ran a bunch of music players along side it and it averaged the same memory and CPU as colibri, vlc, foobar, and swinsian. Clementine stood out from the pack as an absolute hog, burning up my desk with 33% cpu usage, where nighthawk and the others stayed below 1% most of the time.
That's pretty impressive performance.
Between that and xld I don’t feel like I’m missing foobar too much.
(Need 1: Player must remind me of WinAMP)
I often think the issue isn’t cross platform though: it’s that there is a cohort of developers who know a toolchain (JS+web), and use frameworks that let them live in that instead of investing the time and effort to learn how to write an app well using a toolchain not built for those focused on web/browser models of programming.
That said, if foobar2000 had been made cross-platform initially, it may never have been very good. Who can say.
It seems to be this Qt thing which appears to have it's own tradeoffs (which are?) and then...is that it? So is it going to be a case of not having any cross platform desktop apps or having something that uses 2-300mb of RAM that developers won't give you street cred for?
Maybe the focus should be on making electron more performant. Sounds like MS has found a way to do it with VS Code so doesn't that sound like a better alternative than to not have any cross platform apps?
edit: missed a word
This player: http://gqmpeg.sourceforge.net/mpeg-over.html
With a library of 5,011 songs.
Consumes 18 mb.
Since it uses the CLI mpg123 binary to actually play the songs, when playing the child mpg123 process uses up another 3 mb.
So take your pick, 18 mb or 21 mb. Much lower resource usage either way.
Certainly can't be any less efficient than that. Or can it..?
The desktop Electron app may be a bit of a pig, but on the other hand it runs on Windows, mac OS and Linux with very few issues, so I'll accept that trade-off.
The app works pretty fine, but is absolutely slow on my (old and quite underpowered) living room PC. But on the other hand it is just a media player...
The quality was the deciding factor for me to use the Spotify app.
Oh it can be. I get 100-110 mb at the most. I really don't think that you will be able to push it beyond 250 mb.
> can't be any less efficient than that
"can't be more inefficient than that"
Virtual memory is close to 5 Gb, perhaps OP was looking at that.
However, I found out that for me tui is where it's at for music players. Using cmus combined with a drop down terminal such as tilda or a tiling windows manager is the most comfortable i've been with music players.
Oh, and unobtrusive is for the fact that the player stays completely in the background without a single notification or interruption to your work.
edit:
I think from the Foobar2000 sdk alone, you'd see how advanced that thing is.. I mean, extension points everywhere, dsp plugin support, built-in query & library management, codecs, gapless processing, all of that written in a scalable & native architecture.
It truly lacks a proper UI toolkit though. The current options are quite outdated that I'd rather fall back to the default Win32 UI.
So, Electron frontend + C/S communication with Foobar2000? I'd totally buy into it.
Extensions and query and library management can be coded in JS easily, like VSCode, Hyper and others do.
Electron frontend communicating with foobar2000 sdk for every little interaction will lead to a huge mess of performance and latency issues. It's better to rebuild the whole thing in electron instead.
not quite true. for example, the ZXTune plugin brings support for a dozen of chiptune formats which is obviously out of scope of ffmpeg. It'll be possible to incorporate webaudio api for codec but that's a resource hog. Also if you're doing decoding work and the GC jitters, you're going to run out of audio buffer (stuttering). If we take one step back and rely on some audio playback API, then gapless play and other issues would be difficult to deal with.
> The web audio api allows for writing all sorts of equalizers and audio processing effects.
maybe, but that's reinventing the wheel. foobar2000 supports VST plugins, the professional tools used in the audio production industry. there are a few dsp components for webaudio but that's far from satisfactory.
> Extensions and query and library management can be coded in JS easily, like VSCode, Hyper and others do.
Yes I agree. That way we can make a neat package manager for an audio system. Some Digital Audio Workstations(DAW) have already begun to move this way (Bitwig Studio etc.)
> for every little interaction will lead to a huge mess of performance and latency issues.
Not quite sure.. Think about how NeoVim is built. But my concern is that, foobar2000 is not built for tightly interacting with a frontend, so yeah, better rebuild a native audio core, and use a modern communication protocol (msgpack maybe?) to do the roundtripping. But again, that protocol could be implemented as a foobar2000 plugin...
The downside of using foobar2000 is also obvious. It's close sourced and Win32 dependent. So I'd think about this:
```
Electron frontend <-- msgpack --> Native audio core <--> JackAudio, RtAudio or alike, whatever that bypasses the middleware and directly access the hardware audio buffer
```
It's a good occasion to change the "Hello world" window title.
Will definitely check if the new versions of electron support it. If it does support flac, I'll get it working on the next release.
Well besides eating half your RAM and melting down your battery.