Now I'm starting to like to player :)
Would be nice if the player save your last path when quiting the program or if there was possible to set default path to open in tooltype or settings.
The close button does not work. Either in the player or in settings window.
In Settings window there is this button "Hide Settings" to close it. At least it should be called "Close settings"
I would prefer if it where removed and the close window worked as normal.

Thank you for your work on this.

edit: tomorrow I go almost 2 weeks vacation to Greece. I'm looking forward to test more when I get back.

Here is the latest Alpha release (0.24). Before the next release I will be working on refactoring the code:

http://trilabs.one/arosamp_alpha_0.24.tar.gz

Feedback is, as always, appreciated :)

Thank you Mithrandir for all your information and for your efforts ;)

Yes, the Playlist is currently using NList for its implementation. It does however support adding multiple files in the filerequester (hold shift while selecting the files you want to add to your playlist). Haven't had time to look into the implementation of drag & drop support in the ZUNE classes (When AROSAmp was originally made, the Drag & Drop support, as far as I remember, was limited to 'in-app' activities, not between apps), but if there are functions to add support for this in the libraries, I will certainly look into adding them.

As for skinnable playlist/equalizer, these need a bit more research and thought regarding the current themed setup.

AROSAmp, right now, uses its own modular skinning system, where the theme designer can choose 'everything' regarding player size, placement of every button, the counter, font design, and so on. You make the design as described in the themes included, and make your own theme.sd file in the theme folder that includes all the X,Y information required for AROSAmp to render the theme (look at theme.sd.example in the standard skin for more information regarding how to tell AROSAmp your design preferences). Beyond the basic theme image of whatever skin you design, every item from a pressed button, to the counting numbers are seperate graphical files, and you can make it look like AmigaAMP, or design your very own MP3 player with totally different placement of everything. This makes it very 'theme friendly' and modular.

It does however, due to the nature of this modular design, not import WinAMP/XMMS/Audacious/AmigaAMP skins directly (these are usually made up of a single large image that always has the same basic layout and placement of every item which standardizes the size of every item as well). You can, of course, simply modify the attached basic skin to match whatever AmigaAMP skin you prefer with minor tweaks, and you're set to go, but AROSAmp supports a much wider variety of skins in this regard.

The question is, do we want a modular design for AROSAmp which can be tweaked into whatever music player design you want, or do we go the route of 'static player', such as the classic AmigaAMP, Audacious for linux, etc.

Regarding skinnable playist, if we want to implement this into the 'themed' skin, it would have to mimic Nlistview while using BltBitMapRastPort for output (drawing every object in X/Y sequences), and also be scrollable in a quick and easy fashion. I hope to find a way to optimize the redraws already being done, since, as commented in this thread earlier, some people are noticing slowdowns (sluggish) response due to the redraws AROSAmp requires.
Once I've figured out what's actually causing these slowdowns in the current design, and cleaned up the code, this could be a good project in itself. Current tests of improving speed often ends up in AROS crashing horribly due to 'Wait for disk activity to finish' in BltBitMapRastPort function. Still pushing forward though :)

For a skinnable EQ, the graphical design would be simpler to create than the playlist, especially if we make such a screen a static size (like the ones in named players above) considering most of the code for this is pretty much already done with the volume/balance bars in the current skin, but I haven't looked into the AHI code for this at the current time. It will have to wait for now.

Going through, and refactoring the code is a much higher priority now, before I start looking into any of these features further.

Refactoring the code is necessary to add efficiency and stability when adding new features like the ones you mention, while having the 'core' setup stable (not crashing the stuff that works when adding new features). This step is also necessary for adding support for filetypes like FLAC, since the 'arrayplay' function right now includes both the mpeg.library calls and AHI parts of playing the file. Lastly refactoring will not only allow me to release the code so that anyone who wants to jump in and add features may do so, but hopefully make my life much easier in terms of not 'breaking' stuff that works because I, without knowing, changed something that I had a good reason for making all those years ago. :)

Looking forward, I will probably release a new alpha later tonight/tomorrow morning which includes the fixes for the 'close on exit' bug, and also auto-play on opening files or playlists. I've been testing and tweaking for a few hours now and it seems stable here :)

Thank you Mithrandir, Also missing are the Skins for the Playlist and Equalizer, moreover the Playlist should load more mp3s at a time maybe dragging the icons individualmente.

As an example I enclose my video of AmigaAMP on OS3/AFA_OS
https://www.youtube.com/watch?v=fYRCzVcipGE

Great suggestions. Added auto play on open, and opening the last used directory while the program is active. Still trying to look into how to make the reloading gui function faster (BltBitMapRastPort seems to become very unstable when you push it).

Crash on exit here too using AspireOS or latest night build native.
When selecting song it should play automatic. The player should also remember the last path to where you selected song.
I think the player feels kind of sticky if you know what I mean pressing buttons or opening files. Not so responsive as I would like.

I've been able to remove the 'crash on exit' bug by adding a sleep(1); to the exit functions. This causes a slight delay upon exit, but ensures that the termination of the process that is running when playing a song/playlist cleans up properly before the application quits.

Having trouble recreating the 'sluggish' behaviour mentioned above. Going to continue testing various things to see if I can make it appear here. Paolone, are you running Icaros Native on 'real' hardware or under qemu/vmware?

I've been able to remove the 'crash on exit' bug by adding a sleep(1); to the exit functions. This causes a slight delay upon exit, but ensures that the termination of the process that's created when playing a song/playlist properly cleans up before the application quits.

Having trouble recreating the 'sluggish' behaviour mentioned above. Going to continue testing various things to see if I can make it appear here. Paolone, are you running Icaros Native on 'real' hardware or under qemu/vmware?

I'll try to see if I can reproduce the sluggish behaviour as well. The play process is set to terminate every time you stop playing a song. It cleans up AHI and terminates mpega.library before closing the process. Maybe there's something in this cleanup routine that's not terminating properly? Will do some tests later today.