Jump to content


Approved Members
  • Posts

  • Joined

  • Last visited

Johnny2shoes's Achievements


Newbie (1/3)

  1. I understand and acknowledge what you're saying about the initial design philosophy re the enqueue feature. But end-users and the audience of a design product have different ways of using and perceiving products and as a designer myself I realise that sometimes my design intention can evolve through user interpretation and that being fed back to the designers for future designs. It's a bit like how I unconventionally use my music DB on Windows which is not how it was intended but makes for a very efficient use of the genre field to generate multiple autoplaylists for individual tracks with a semicolon separator - this of course is not available on apple products and products designed with a similar design philosophy of 1 genre per track. This method allows a person to add multiple genres to a single track and thus see all playlists a track is allocated to by looking at the track's genre field and adjustments can be made as such. As apple products amongst others don't allow for multiple entries in a single field (turning them into 'genreA/genreB' entry) I then have to set up an autoplaylist m3u for each from the genre fields, for them to work in devices and apps that aren't designed with that Many other end-users evolve the original design intention (doing the above or similar) through clever usage and interpretation - and these forums are the platforms for feeding back these preferences and suggestion for future design development as feature requests. So though I acknowledge the original design intention of the queue feature, I do respectfully reject that it should not be perceived as a 'now playing' list as well, as it does and has functioned as such in v2 and now with this setting adjustment, thankfully in v3. And within this forum for end-user suggestion and feedback, I respectfully ask that the designers acknowledge that some users would like it to be perceived that way too as it currently can function in such capacity - as well as the way you suggested (as it also works as a temp interruption) both being cool ideas and this player currently does both. My suggestion now that I know it has both is to keep it that way in future designs. I think, in a feature request forum, being told "we don't intend for a feature to be used the way you want or suggest - there are other ways to achieve this", though actually trying to be helpful, as in this case it was, is also contrary to the concept of the forum being a platform for user preference suggestion and feedback. Again I thank you for your help. The queue works fine to my satisfaction now as it did when I purchased v2 and acknowledge I am using it outside its original design intention, but with great satisfaction at how it works as a now playing list.
  2. @ Andrewilley Actually I think changing the queue repeat setting (as you advised earlier) has returned the queue to the operation I described as per v2, where it doesn't clear the queue when adding new tracks even if these tracks have already played. It basically resolved my first suggestion completely - just tested it 😃 So again thanks for that. Very helpful 😃
  3. Thanks Andre. I understand the above and it makes sense in the light of how you've describe this feature and how it currently operates. I've always seen it as a queue to "now playing" or current listening list which when set to repeat the list should not erase when adding more tunes. Maybe now that I've changed the setting as you recommended earlier this erasure of previously played tunes may stop happening. Haven't tried it yet. I believe it used to work by adding continuously in v2 but maybe I'm mistaking it for winamp or even my old Toshiba gigabeat or ipods operation before I switched to using this amp on my phone more or less exclusively. In any case my preference and suggestion for such, is to have the queue function as an add to "now playing" list that if set to repeat keeps played tunes rather than clearing them (as I've experienced) when new tracks are added to queue esp if set to repeat. For now I have been using a playlist to achieve this more stably (as you also suggested) but since this for the current rotation of tracks I'm listening to on loop, is only temporary and made up of selections from other more organised playlist I'd rather not save it as such, which I see as a more permanent list not just my current track list on rotation with the occasional addition or subtraction... If that makes sense. I've done this in the past with possibly with other players but I was pretty sure that's how v2 functioned. Thank-you for the polite manner in your explanation in your reply.
  4. I'm not really seeing your point bluabar beyond trying to put someone down and be smug about it presuming they're stupid when really you've missed the point... Your comment isn't very helpful if not rude and obnoxious. I'm sorry if you felt the need to defend the queue mechanism's honour in my blatant disregard for the exceptional mechanism's feelings by having a differing opinion on how it should operate based on my experiences of music playing apps/database programs. I understand how queue works and the various incarnations the queue has taken in many different music players, quicklist, now playing and the like. I understand an M3U playlist txt file and it's list of track file locations within said playlist relative to the root if the storage medium or relative to the folder the M3U txt file is stored. I've seen and have used the add to queue which adds to a "now playing" list which doesn't clear with the addition of new tracks even after they have played esp when on repeat as they are my current editable listening rotation, without wanting to save in a more permanent way such as playlist. This is my preference and I believe this is how it worked previously in v2 of PAmp as well as many other players and this is my preference for its operation. Bluebar if you aren't going to be helpful, take your elistist rudeness elsewhere.
  5. Thanks for the setting advice. I'll check that out shortly. However the queue button has in every instance I've used it cleared the queue and started a new queue if there has been any seemingly significant time since the previous use of this button. I.e. I added a new song to the list this morning to have the previous 8 tunes removed... then I had to re-add the previous 8 to have my song list. It does what you have described "add to queue" as well as what I've described "start new queue" at its own discretion. In v2 there was a queue button which you could hold like the repeat and shuffle with itemised options. That has been removed and I would like it back for clear and consistent results. My context is working in a band, we make a list and then add and remove songs to learn.. I can do this with a playlist but rather the queue while the song list is still in flux. Again, thanks for the setting advice 😃
  6. 1. Queue options and bug 2. Lockscreen 3.UI suggestion regarding the already present option of pro button and scrobble seek UI simultaneously. Firstly I generally like v3 PAmp but I've noticed what I think is a bug possibly. Repeat from the queue goes to a new list at the end of the last queue song instead of repeating the queue list - I got around it by making a new playlist of the queue but don't want to have to do this everytime. Also adding to queue has bee removed and replaced with a generic "queue" option which sometimes adds to queue and sometimes clears the previous queue list and starts again - quite annoying if I just want to add another tune and have to start again because PAmp has decided for me which I want. Bring back the ( biff) "add to queue" option like v2 - add to queue, clear q, new q etc. The lockscreen - v2 had the player and an unlock button at the bottom. No access to eq and accidental in the pocket changes to other features, eq and playlist etc. Now I can get lost in navigation from lock screen. The limitation of a lockscreen is meant to be.. It's locked to a playscreen with limited features and for major changes you should need to unlock. V3 has complete access from lockscreen which is a silly design idea in practice. The v2 lockscreen was better - a v3 update could allow for different lockscreen hierarchy if you're going for providing end-user customisability. This is a small UI suggestion as I like having the pro buttons and I like th scrobble seek per track - visually separate the 2. As it is grabbing the scrobble sometimes activates the pro buttons and vice versa. I want both on as I use both frequently but having the scrobble seek smaller and below might help functionality when a user has selected to have both in the UI. Thanks for reading 😃
  • Create New...