Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
FIrst of all congrats for this version 2.0, wich is really doing it for me,
despite the 400+ MB of RAM (large collection). Still, it's working really
fast, like nothing I've tried so far.
Some features I'd like to see implemented:
-Spacebar controls playback (DAW habit)
-Search function needs to be revised, the search "navigator", "navigation pane" and "playlist" is a bit limiting for very large collections; instead I would propose these filters: search "all", "artist", "title", "comment", "album ", "year", "genre" and "advanced" where any combination of search fields could be selected, much like when creating intelligent playlists but without that need
- Either review the search function like suggested before, or simply add those navigation panes ( "all", "artist", "title", "comment", "album ", "year", "genre" and "advanced") and keep search as simple as it is
- Inclusion of a Playlist tab in the navigator, to store any user defined playlist (including smart playlists) without the visual clutter of the playlist pane.
- Ability to run the software even without having mounted the media with the music repository
That's it so far,
Keep it up!
400MB of memory is a lot, what's the size of your collection?.
About your requests:
- There is an option to search using the attributes you say, it's in Tools -> Search. There you can create complex queries with different attributes.
- About playlist tab, that feature is already planned and I think we'll include it soon.
- I didn't understand your last request. Can you explain it a little more?.
Hey, even if this post is very old - i did some memory analysis with aTunes
26k songs took 32mb repository and 7mb disc cache, this size grows linear so
with ~300mb repo (100 for all the rest) i guess the lib contains ~250k songs?
Maybe we should think about outsourcing the storage to sqlite or smth.
database alike. This could save much memory and it's not really slower than
inmemory hashmaps. What do you think?