hypermodules / hyperamp Goto Github PK

Using https://github.com/electron/electron/blob/master/docs/api/dialog.md

The user should be able to control playback via keyboard shortcuts.

Basic defaults:

• space : play/pause
• → / ← : skip to next or last
• ↑ / ↓ : move highlighted selection in media list

These can be attached to menu items so that we can use the menu/keyboard shortcut mapping methods provided by electron.

• When the main process has a playlist, repopulate the renderer with that info instead of doing a full refresh.

Here are some things that might be useful

• https://github.com/shama/csv-viewer
• https://github.com/shama/view-list
• https://github.com/editdata/data-grid
• https://github.com/yoshuawuyts/base-elements
• https://clusterize.js.org
• datatables.net/extensions/ + https://datatables.net/extensions/scroller/

We should start thinking about how we want to persist the library to disk so that its ready when you launch.

Here are some points I wanted to hit:

• We need to come up with a metadata model that tracks the state of watched folders, kind of like what we are doing now.
• We need to persist this data between app launches so that the user doesn't have to wait for full folder + metadata scan to see their music.
• Folder scans should begin when the app starts, manually, and optionally when changes are detected. (Know a good module to do that? The node api is a little rough I hear.)
• Figure out the type of DB we want to use. It should be embedded so either SQLite or Leveldb. LevelDB is more in line with the P2P libs we want to use, but iTunes was interesting because it was SQLite with a nice interface. Maybe eventually use both with the SQLite as a disposable index use for performance and sorting/query features?
• Watch folder should be scanned for new content to be added/staged to the library.
• Library metadata should get a full scan to discover the state of the blobs living on the FS.

This is obviously a ton of work, but thinking about it should help us understand what we need to develop from the perspective of the UI at least.

Before we implement a media library, we should implement playlist. A playlist is an array of objects that represent playable tracks, that we can render a table that represents the playlist.

Lets start with one playlist for now, and build out from there:

• Show you the list of songs that have been added to hyperamp. Our existing table provides a base layout for now. Think the winamp playlist pane:
  
• Users can add songs to the playlist by dragging files and folders onto the window. This will trigger a 'task' that does a folder walk if necessary, scan metadata, and add the found data to the playlist.
• Clicking on a song will start playing it.
• We should have a way to remove songs from the list as well.
• We should persist this to disk somehow.

Everything else you would expect from a playlist we can add after we get these items done.

• Replace settings button with add button that pop opens a multi-file select window
• Populate using existing code from selected dirs and files.
• Add a file drop target. Can we support multi-file and dirs?
  - [ ] Investigate unmanaged internal components in choo
  - [ ] Investigate view-controller for table for component recycling.

Been eyeing https://github.com/rtsao/csjs and it seems like it would be a better fit for our use case. No required transpiration step! Real template string variables! Looks nice and mature! No unnecessary build steps.

Anyway, sheetify has already shown to have some hairy yacks involved that have taken a lot of my time, so I'm thinking I'll swap the required dependency and move forward with csjs if some initial experiments work out.

After thinking about all the things we are trying to accomplish in this project, and realizing I haven't even ever tried to build a music library/player before, we should probably work on some simpler goals before we reach too high.

Here is what I propose:

• Build Hyperamp as an electron/node based music library.
• Build Hypertorrent: an electron based torrent client that bundles together hyperdrive and bittorrent/webtorrent into a unified client.

Hyperamp will lay the groundwork for a music library app, let us mess around with music metadata and file indexing, familiarize us with choo better, and get us set up to build and distribute a desktop application.

Hypertorrent will be a nice complementary project to things like the dat and webtorrent desktop. I imagine this as a traditional utorrent/transmission style torrent client. In addition to handing torrents via webtorrent as a way to get the application off the ground and back up a user interface, this should also allow for a traditional torrent client style experience with hyperdrive. The important thing here is that we establish how to work with hyperdrive effectively, and experiment with some of its advanced features like signed feeds, self signed feeds, extracting unsigned feeds from signed feeds, feed updates, and feed history.

Once we get these done, we should be pretty well set to start combining the two, and experimenting with synced libraries via hyperdrive.

What do you think @ungoldman ?

There is a super stupid content addressable image cache that was just merged. Probably pull this out into a module, but the goal is to avoid large arrays of image data in state, and instead use hash pointers.

See https://github.com/hypermodules/hyperamp/blob/df9ec8ffb8d65a4a2727c7a1d1022fb7b0f3b15f/renderer/lib/artwork.js

Might be addressed by #118 but maybe not.

Right now next and prev are couple to the play action. What happens when the player is paused and you click next? We need to decouple the play/pause action from some queuing.

we gotta persist it

We now have CI packaging infra set up, next up is:

https://github.com/electron-userland/electron-builder/wiki/Auto-Update

Refer to that page when completing this issue.

• http://id3.org
• https://en.wikipedia.org/wiki/ID3

Layout in isolation with shadow dom?

Use something like https://www.npmjs.com/package/sheetify ?

I'm going to try to port over button group styles today.

While we focus on Winamp 2.0 features, like an interface, playback, playlists and stuff, maybe it would be more informative to call this hypoamp instead of hyper amp.

We do this stuff manually now. Would be nice to clean it up with:

• https://github.com/carter-thaxton/electron-default-menu
  - [ ] https://github.com/jprichardson/electron-window nah for now maybe later.

@ungoldman if you did css for hyperamp all on your own, how would you do the CSS? We kinda talked about this in person. Would it be worth while to change how we do things once again, if it represents your ideals? I'd be open to whatever you want to do here.

Before we can work on syncing library metadata between devices, we need to figure out what the library will look like.

Here is one idea I had:

Your typical bittorrent app smooshed together with iTunes 6. The UI is similar to iTunes, but instead of managing collections of loose music files and cross your fingers, the library manages hyperdrive feed files that represent a collection of related media files and metadata.

A hyperamp library consists of a collection/directory of hyperdrive 'feeds'/archives, probably taking the form of a SLEEP file (these are similar to a .torrent file, however some will be signed feeds which are mutable.

Each feed file will typically represent some kind of media collection, like an album release, EP or single. The feed file contains the cryptographic blueprint for the binary blobs/files and directory/file structure that the feed represents. Like any other archive format (like zip/tar/torrents), you can't guarantee the folder structure inside the feed will be exactly what you want.

A separate folder will hold the binary blobs described in the feeds from the feed library. Some kind of managed folder structure (similar to how iTunes can reorganize its music folder) will likely be needed to keep this storage folder in order. This folder should be routinely scanned for organization and garbage collection.

Since SLEEP files and hyperdrive is an emerging spec, we will need to implement a reliable importing from loose files. Here are the strategies I have in mind:

1. Scanning of an existing consolidated, and 'reorganized' iTunes library. This scan should create the basis to generate 'feeds' and metadata to store into the feed library. The granularity of the feeds should try to target 'album' level collections. Eg, feeds for all second level directory in a sorted iTunes library. The feed library can then be indexed, and used to manage and garbage collect the folder structure of the the blob storage (the former iTunes music library folder).
2. Importing of loose files from a folder. This is like your standard, drop files into iTunes, and have them imported strategy. The difference is that we should have a staging mode. This way, when you add a collection of loose media, you get a chance to edit the discovered metadata before finalizing the feed file that will be the new canonical representation of the collection. This would also be a good time to enforce a standard directory structure and file naming convention potentially, or even re-edit ID3 tags.

Using https://github.com/sindresorhus/electron-config, lets try to persist preferences to disk.

Quick thought here: no other electron app uses the OS X style, and instead diverges into something kind of endogenous between all the OSs.

For now, I'm going to try to stick to the photon UI style, but I'm thinking of ways to maybe make things easier in the long run.

As work progresses to re-implement some of the UI elements to meet our needs (e.g. https://github.com/hypermodules/flex-table) maybe we should start considering something less specific to OS X. It might make CSS easier, and buy is a look that works on Linux and Windows.

Examples:

Tha table implementation is an interesting example in BTSync

We need to implement a now playing info panel that shows the currently playing song, scrubber and time etc.

Hyperamp needs an app icon!

Here's an example of how to set it up:

• https://github.com/feross/webtorrent-desktop/tree/master/static
• https://github.com/feross/webtorrent-desktop/blob/master/src/config.js#L28
• https://github.com/feross/webtorrent-desktop/blob/master/bin/package.js#L136

Right now artwork only shows on queue. We should trigger this when the app initializes too.

Out with the old, in with the new. Why use kebab case for css class names just because people in the aughts did it that way. Lets just use camel case property names to keep selector syntax simple.

https://github.com/bengourley/choo-resume

https://github.com/stackcss/sheetify-postcss +
https://github.com/jelmerdemaat/postcss-base64

Damn, this is going to cost about $200 :(

https://twitter.com/electronjs/status/798964709076516864

The user should be able to skip to both the next and previous song in the current list (or search context).

https://github.com/TooTallNate/node-lame
https://github.com/TooTallNate/node-vorbis

for some reason, Choo's router isn't routing. I think it has to do with the fact we are serving from a file. I'll experiment.

We need to do sticky table headers, so you can adjust the sort column and direction when you are at any scroll position.

Ideally, we could just use something like Sticky Positioning, but it doesn't work on thead elements, and it doesn't work in chrome webkit! 😭

There are a bunch of hacks that you can do to get it to sort of work with the table elements, but they are all pretty gross and don't perform great.

The third options I was thinking of is dropping the table component all together and using flex'd div's with overflow: auto set on the table row container. We are going to have to port over/redo table styles, but will ultimately set us to up to do fun/complicated table rows without having to fight the limitations of the archaic table element. e.g.

I just introduced a bug where the audio process tried to pass a message to the player process via main. When player is closes, we get those crappy main process error windows that screw things up real bad.

Easy fix, but I have to go to bed now. Basically, check if the window is open or not though before sending messages.

http://hypermodul.es/hyperamp > http://hypermodul.es?

this is a cool project!!!

I've fooled around with musicmedata and fs-walk a bit but don't have anything concrete yet. @bcomnes let me know if you want to take a crack at this.

Do this https://github.com/yoshuawuyts/tiny-guide-to-non-fancy-node

So, drop ES6: things like const, restructuring and arrow functions for the most part. Too many foot guns and we have the knowledge to not use them. This is a bit of a yak shave but it is labor I would be interested in doing.

@ungoldman thoughts?

like com.hyperamp.config.json

so we don't collide with other random electron configs when developing

https://github.com/electron/electron/blob/master/docs/tutorial/testing-on-headless-ci.md

Lets turn on the app, then turn it off and make sure it exits with a 0.

I think we should work on moving the audio component to a worker process like we discussed a while back. Webtorrent Desktop did this fairly well (even had a keyboard shortcut for exposing the hidden renderer process for debugging I think).

The implementation has grown a somewhat unnecessarily complex (see main/windows/webtorrent.js and renderer/webtorrent.js) and they decided to port the entire project to React for some reason (😢) but I think we can draw a lot from the basic parts of the method used there.

Whenever you change the volume, you end up re-rendering everything over and over. This is super wasteful and starts to creak under load.

Components affected by this:

• Table
• Album Art

Worse case scenario is that we have to manage large data sets outside of state and use pointers in state. But lets experiment with that first.

We should implement a proper state machine API on the audio process. Eventually we can swap it out with a real audio library, but for now the hidden window thing works, and we experiment with an API.

A few requirements:

• It has to live in its own process that persists for the lifetime of the app. Closing the main window should not stop playback.
• When playback finishes, it should start playing the next track in the playlist.
• Playback state should be communicated to the main window if open.

It would be cool if we could plan out a state machine design, but if thats too much of a distraction, do whatever.

We need a place to set preferences. Should we make a new browser window? or use something like chop's app.router to make a single window app (like slack or whatever).

Basically, package up http://www.entypo.com as a module with its own prepublish build script. Some labor involved, but everything is laid out, and the npm name is available.

The module should ship the raw svgs, and a sprite sheet with an en- prefix or something. Model it off https://github.com/Kriesse/dat-icons. I think I love this pattern.

This was another sheet-router bug I was running into. Basically, refreshing the app should work everywhere, but after you navigate around, you lose the base url so subsequent refreshes fail. The gif shows 1 working refresh (initial state) and one failed refresh at the end. I need to open an issue upstream. Going to 🛏 goodnight 🌖

The user should be able to seek through a song as it's playing.

Once we have real paths to music files (#11) we need to actually play some music.

See discussion 08dfa82

• Song Name
• Album
• Artist
• Album Artist
• Album Art
• Composer
• Genre
• Year
• Track
• Disk number
• Play Count
• Format
• Date Added