▲

[Pike84]

If I thought I had been unfairly treated on this board, or I wished to respond directly to those who may have "unrightfully critizised (my) beloved media library", have no published e-mail address in their member profile.

Well, I have my e-mail published, ok. But I didn't mean, that you should privately contact me, or anyone. Just that you would more clearly state, who you think have mistreated you or degraded the media library system, or whatever - not to just say, that this thread has dismissed a polling option, or so.

This thread, or this topic, played out recently in another thread and the outcome remains consistent. It's a shame that a concept, an idea, a poll referendum item, can raise such a fuss with those whom have chosen to discard it.

Yeah, a shame indeed. Unfortunately I can't help but name the culprit behind the fuss your way. Besides, you must admit, that in the end, it wasn't just the idea/consept/poll referendum item. A good example of this, is your post at  07.06.03 at 22:54:23.

Also, I suggest you reply to those quoted statements separately. Overall, it seems that you don't very much like to answer straightly to statements directed at you.

My point exactly.  No problems here

A pretty naive view, I would say - the problem Tsorovan was referring to, was obviously the explorer slowdown.

[DanaPaul]

Also, I suggest you reply to those quoted statements separately. Overall, it seems that you don't very much like to answer straightly to statements directed at you.

My appologies, I didn't understand that membership requires repeated responses to address closed minded points of view.

The Explorer "slowdown" statement was in regard to very large folders, folders that contain many files.  As well as the fact that two applications (or more) must interact to (action) accomplish (primitive) media tasks.

I feel that I have offered sufficient reasoning behind the media library concept for Ian, the developers of XMPLay, and anyone with an open mind.  However, at the risk of repeating myself...

Volumn leveling (complete library), Automatic disk sub folder and file naming organization, display sorting and media property viewing, database speed and statistcal support (played most often, etc), auto play list generation (genre, artist, played most often, etc), and random play (complete library) to name a few off the top of my head.

Are we ready to move on yet?

[Pike84]

My appologies, I didn't understand that membership requires repeated responses to address closed minded points of view.

It was only a suggestion.. and what do you mean by repeated responses? You have made a fine overall view of your ideas and so on, but you have scarcely responded to single statements.

As for the rest of your post: I have well understood your point in supporting the media library, and also learned something new about it. This debate (if you can call it that), however, has had fairly little content about that - we're actually quite a long way on the side-track .

[Torkell]

Actually, I was referring to the plain vanilla concept, Explorer as a viable alternative to a media library aware application.  This point of view has been played out, and I think that the posters in this thread understood.

I think we understood that Explorer is a viable alternative to a media library, given certain conditions (e.g. suitable plugin).

I'll try to refrain from helping people resolve their problems when they're not asking for it in the future.

My point exactly.  No problems here

Tsorovan was actually attempting to help you with your problem with Explorer (i.e. it slowing down all the time). It's taken for granted that when someone is trying to be helpful and gets a bloody nose in return, they will not be happy.

A couple of Kynes' statements that you quoted were actually questions that have gone unanswered. It was a perfectly resonable thing to ask for, and did not deserve your response.

The Explorer "slowdown" statement was in regard to very large folders, folders that contain many files.  As well as the fact that two applications (or more) must interact to (action) accomplish (primitive) media tasks.

Explorer is a file manager first and media player through extensions and JavaScript. It's perfectly reasonable (and the core principle behind COM) for multiple applications to interact.

I feel that I have offered sufficient reasoning behind the media library concept for Ian, the developers of XMPLay, and anyone with an open mind.  However, at the risk of repeating myself...

Volumn leveling (complete library), Automatic disk sub folder and file naming organization, display sorting and media property viewing, database speed and statistcal support (played most often, etc), auto play list generation (genre, artist, played most often, etc), and random play (complete library) to name a few off the top of my head.

In order: Nice idea but not really needed - anyway per track settings come close, already partially implemented and it would be nice to expand it, already there, should be added if media library is chosen, again major part of media library, already part of XMPlay.

I'll give you a bit of information: my playlist system is actually based around a 560+ master playlist, and seperate playlists for every 'album' which are added to the master playlist. Two features I use a lot are track queueing (sp?) and random play order.

As it is there is only one vote for the media library, compared to 2 for multiple playlists and about 8 who want to stick with the current system.

[DanaPaul]

It's taken for granted that when someone is trying to be helpful and gets a bloody nose in return, they will not be happy.

I'm sad that anyone may be unhappy.  But I venture to predict in hindsight that a nose or two might have been bloodied in the last thread that played out this hissy fit.

Explorer is a file manager first and media player through extensions and JavaScript.

Explorer is a shell that launches (seperate) applications.  To encompass all applications as one under the shell is a stretch.

It's perfectly reasonable (and the core principle behind COM) for multiple applications to interact.

The Common Object Model (COM) principle defines common objects that are embedded into a single application. Not seperate processes that must work within limited cooperative functionality.

In order: Nice idea but not really needed - anyway per track settings come close, already partially implemented and it would be nice to expand it, already there, should be added if media library is chosen, again major part of media library, already part of XMPlay.

Per track volumn leveling is appreciated.  But again I remind you that a media library aware application doesn't require per file actions.

As it is there is only one vote for the media library, compared to 2 for multiple playlists and about 8 who want to stick with the current system.

I never expected this poll to affect immediate results  even if the outcome was in favor of a media library.  This is a major decision for the developers and one that probably would not be decided, in whole, based on a snapshot poll.

[Zarggg]

I've been mostly ignoring this thread, but I now think third-party moderation is necessary.

With all due respect, DanaPaul, the only person flaming here (what you call a 'hissy fit') is you. The membership of this forum are attempting to explain why they believe (which is their opinion; you are still entitled to yours) what you suggest is not needed.

They are not telling you 'no'. They are telling you what they think. You can either choose to use their input to make your idea better, or simply tune it out. In the end, it is neither you nor them who decides what goes into XMPlay; it is Ian.

That brings me to another point: Your tone. It seems to me that you are telling Ian that he must implement this. Forgive me and educate me if I am misreading this.

[DanaPaul]

That brings me to another point: Your tone. It seems to me that you are telling Ian that he must implement this. Forgive me and educate me if I am misreading this.

Quite to the contrary.  Yes, I believe that a media library aware application is a useful tool.  In that vein, I would suggest that anything less than a full suite of media library options would/could dissapoint some folks if this were to become tomorrows direction.  XMPlay has a very useful purpose as it stands today because of its current capabilities.  It would be a shame to see that which it already posseses suffer in any way to become a one size fits all application.

On the other hand, I feel that multiple play lists are a no brainer. However, development may have their own reasons for this designed behaviour.  But I also feel that two or more playlist functionality is closer to a single playlist application than a media library aware application.

Thank you for asking

[Zarggg]

Thank you for asking

Thank you for responding. I merely wanted to point out the dangerous direction this thread was taking. I wanted to (hopefully) calm it down a little before it got out of hand. We're all among friends of similar interest. Alienation is anathema here.

[DanaPaul]

I wanted to (hopefully) calm it down a little before it got out of hand. We're all among friends of similar interest. Alienation is anathema here.

My behaviour has been deplorable in this thread.  My posts lack understanding, humlity, and compassion.  All of the same reasons why I chose to obstain from the last thread.  There is no excuse for my own behaviour.

My heart felt appologies go to Tsorovan for being unfairly singled out.  His/her loyalty and unwavering willingness to help is second to none.  A trust between members was violated and I am truly sorry for that. I wish to share that bloodied towel with you if will toss it this way.

[Keltic Danor]

Personally I was never fond of the multiple playlist idea (not in the style of winamp3 anyway) it just seems overly complicated that although might seem simple to the experience user, would confuse a beginner.

(ok ok so it confused me too )

I am however in favor of the MusicMatch style, think I remember suggesting that when the extended playlist was being put into the info panel. Even drew a piccy to show what I meant.

I'm not sure what musicmatch is like now (stopped even looking at it when it past 10 Mb, I don't care what it does, thats too big.) All I see that could come in handy is one playlist that contains the library, just a simple list, songs can be previewed from it etc. While there was the main playlist that songs could be added to by double clicking on them from the database and so on.

Thats the simplest way I think would work. Its not that a big pseudo explorer tree view layout of the music library would'nt work (ala WMP9) just that its overkill.

Maybe I'm being overly simplistic but I like apps that do few things, but do them *really* well. Thats what XMPlay does now, and I would'nt be too worried if it was left the same, or even a basic music library (MM) was implemented. I would however start to worry when it gets to the point that you need to think how to get your music playing instead of it just coming to you naturally how it all works.

(Here is where I say what all I said before does'nt matter)

However on more than a few occasion Ian has put in something that would of made any other player big slow and clunky, and did add them with no drawbacks whatsoever. Negligible size increase and no effect on speed.

So no matter what is finally decided, no matter what style of playlist is implemented, I know its going to be far more than any implementation before it