Improved Banondorf Jukebox(Update)

Have a suggestion for the forum or chat? Post it here!
Post Reply
xnamkcor
Posts: 19
Joined: Mon Jul 23, 2012 10:07 pm
Location: Mesa, AZ
Contact:

Improved Banondorf Jukebox(Update)

Post by xnamkcor » Tue Jul 24, 2012 7:20 am

Store a 10 song deep history at all times of the recently played songs.
Let people favourite a song by using its ID Number
Have separate commands for queuing up a song and interrupting the current song.
Give banondorf a database in which he could play a song based on a keyword.
Allow people to unfavourite a song.
Allow people to PM or /msg banondorf to ask for things like DP amounts so it doesn't fill up the chat.

Update:
Make Banondorf play 3AM at 3 AM every day.
Last edited by xnamkcor on Thu Jul 26, 2012 4:28 am, edited 1 time in total.
User avatar
empressdonna
Posts: 166
Joined: Thu Aug 05, 2010 5:42 pm
Location: Glasgow, UK
Contact:

Re: Improved Banondorf Jukebox

Post by empressdonna » Tue Jul 24, 2012 7:30 am

Going to respond to these in order :D

Store a 10 song deep history at all times of the recently played songs.

I am not sure how to respond to this one, I mean itunes does have a recently played section but it may be more hassle than it is worth (Fox may be able to correct me on this)

Let people favourite a song by using its ID Number

I can see why this would be a good thing if you missed favouriting the song by a few minutes/seconds and someone did a 'what song is this' command.

Have separate commands for queuing up a song and interrupting the current song.

I'm not too sure what you mean here, as the list is random. Yes, sometimes someone will put up the command to change a song to x number, but it takes a while for the song to load (so I have found).

Maybe I'm still too sleepy to make sense of this though XD

Give banondorf a database in which he could play a song based on a keyword.

Banon already has something like this implemented, it's the "Banondorf, please play some (song keywords)" command

Allow people to unfavourite a song.

I've already said my personal opinion of this in the chatroom. I don't think this command is needed but like MeNo brought up in chat, you may get bored of a song and wish to remove it from your playlist.

Allow people to PM or /msg banondorf to ask for things like DP amounts so it doesn't fill up the chat.

I agree with you partially on this, but if it's during the day when no stream is on.. it's not as much of a hassle. It's a bigger hassle when the chat is active.
Image

Image
please PM me before adding me to any messenger

http://dragcave.net/user/empressdonna
User avatar
KreamCheese
Posts: 124
Joined: Thu Jan 06, 2011 2:27 am
Location: Fort Wayne, Indiana
Contact:

Re: Improved Banondorf Jukebox

Post by KreamCheese » Tue Jul 24, 2012 11:12 am

My quick 2 cents worth for this is about the 'unfavouriting songs'. I've had times where I go to favorite something, and either the song had just ended and I end up favoriting the next song that's about to play, or I go to favorite something and someone changes the song milliseconds before I favorite it, so i end up favoriting that song instead. It's happened quite a few times, actually. Also, we actually have a command for that... 'please remove song number (number)' ...but last I tried to use it, i think it either didn't work, or I didn't have permission or something to use it. Either way I wasn't able to delete any songs.

Eh, screw it, I'll talk about some all of the other things as well xD
empressdonna wrote:
xnamkcor wrote:Let people favourite a song by using its ID Number
I can see why this would be a good thing if you missed favouriting the song by a few minutes/seconds and someone did a 'what song is this' command.
Actually, when you use the 'what song is this' command you don't find out the id number of the song, that's the 'what is this songs number' command. (just technical things) :o)

My take on this? I think it would be useful, but I also think that people will be blindly favoriting things and then wanting to unfavorite it after saying, "It's not what I thought it was, I don't want it now." In which case brings us back to 'unfavoriting of songs'.
xnamkcor wrote:Allow people to PM or /msg banondorf to ask for things like DP amounts so it doesn't fill up the chat.
I've actually asked this myself in the past (to no avail as it hasn't happened yet). I would like the ability to PM Banon to do things like check dp, notd, qotd, cotd, etc... along with also being able to favorite a song and check a song number would be nice to be able to PM to him. Tom (admin of site) has had some feedback on this (of which I don't quite remember right off hand).
xnamkcor wrote:Store a 10 song deep history at all times of the recently played songs.
As for this, it could be useful. But if it were to be used, then we'd have to set it so you can favorite a song by it's number, which brings us back to 'favorite a song by it's id number' and then even more back to 'unfavoriting a song'.
xnamkcor wrote:Have separate commands for queuing up a song and interrupting the current song.
As for this... I'm a bit confused as well xD Do you mean when someone uses the 'play song number (number)' command that instead there be two different commands: to play the requested song right then, interrupting the current song (like it's set up to already), and/or to have it go on queue to be played after the current song it finished, as to not interrupt? This is what I'm taking this out to be. If that's the case, I like that idea. There's been plenty of times where someone used the 'play song number (number)' command to change the song, even though I was liking the current song and wanted to listen to it all the way through. So, yeah, like I said, if that's what you ment, then I like the idea. And if that wasn't what you ment, then I still like my idea xD but explain what you meant, if you could.
Last edited by KreamCheese on Tue Jul 24, 2012 11:24 am, edited 1 time in total.
~Dance Kirby Dance~
<(^.^<) <(^.^)> (>^.^)>
User avatar
yuki_fox_demon
Posts: 214
Joined: Mon Jul 26, 2010 7:56 pm
Location: in his heart.

Re: Improved Banondorf Jukebox

Post by yuki_fox_demon » Tue Jul 24, 2012 11:19 am

on the PM banondorf thing (since that's really the only thing really have any input on), the reason we dont do that is because it can very, VERY easily cause a lag with banon, especially if four or five people try to PM him at once. it happens all the time when we vote on the stream committee, and lag can break banon. not to mention it spam's tom's logs. it's not SUPPOSED to be spammed in the chat anyway :P
Image
User avatar
Foxtrot200
Posts: 131
Joined: Sun Jul 25, 2010 9:04 pm

Re: Improved Banondorf Jukebox

Post by Foxtrot200 » Tue Jul 24, 2012 2:31 pm

Your requests are certainly not impossible, but some would be more difficult or too much of a hassle, really, to be practical. I'll just address them one by one:
xnamkcor wrote:Store a 10 song deep history at all times of the recently played songs.
Completely possible! All we'd need to do is make some sort of FILO table out of mIRC's hash tables and we can keep track of the most recently played tracks. This would require Banondorf to check the song every few seconds, though, and I'm unsure what effect that would have on him and iTunes. (If he doesn't already)
xnamkcor wrote:Let people favourite a song by using its ID Number.
This is possible, but the result would be an entry in the favorites without tag data because Banon is unable to pull information for any song unless it's currently playing. This would require a database which I will address below.
xnamkcor wrote:Have separate commands for queuing up a song and interrupting the current song.
Queuing would be possible, as well, but again, this would require Banon to check the song every few seconds to see when it's done as AMIP, the plugin Banon uses to communicate with iTunes, doesn't have any queuing commands. This wouldn't really end up solving cutoff as the next song to play, before the queued song, would likely get cut off.
xnamkcor wrote:Give banondorf a database in which he could play a song based on a keyword.
Possible, but not necessarily practical. This would require Banon to record every song that goes through iTunes to a database meaning that he would only be able to play songs he has "heard" before. Also, our previous experience with mIRC and databases is bad. The functions are overcomplicated and end up making the code sloppy and convoluted.
xnamkcor wrote:Allow people to unfavourite a song.
This is a planned feature. It will be implemented as soon as we work out safely removing the favorite line from the favorites list file. mIRC has terrible file handling functions in comparison with other languages.
xnamkcor wrote:Allow people to PM or /msg banondorf to ask for things like DP amounts so it doesn't fill up the chat.
Definitely possible. We'll have to look into it.

So, as you can see, the question isn't about whether or not we can do it, but whether or not it'd really be worth it in the end. I think a database of tags would just confuse people, creating more harm than good. Song queuing would require extra processing for not just Banon, but iTunes and AMIP. Considering iTunes is already a resource hog as it is, this wouldn't be ideal.

Did this clear anything up for you?
Image
xnamkcor
Posts: 19
Joined: Mon Jul 23, 2012 10:07 pm
Location: Mesa, AZ
Contact:

Re: Improved Banondorf Jukebox

Post by xnamkcor » Tue Jul 24, 2012 4:32 pm

Foxtrot200 wrote:Your requests are certainly not impossible, but some would be more difficult or too much of a hassle, really, to be practical. I'll just address them one by one:
xnamkcor wrote:Store a 10 song deep history at all times of the recently played songs.
Completely possible! All we'd need to do is make some sort of FILO table out of mIRC's hash tables and we can keep track of the most recently played tracks. This would require Banondorf to check the song every few seconds, though, and I'm unsure what effect that would have on him and iTunes. (If he doesn't already)
xnamkcor wrote:Let people favourite a song by using its ID Number.
This is possible, but the result would be an entry in the favorites without tag data because Banon is unable to pull information for any song unless it's currently playing. This would require a database which I will address below.
xnamkcor wrote:Have separate commands for queuing up a song and interrupting the current song.
Queuing would be possible, as well, but again, this would require Banon to check the song every few seconds to see when it's done as AMIP, the plugin Banon uses to communicate with iTunes, doesn't have any queuing commands. This wouldn't really end up solving cutoff as the next song to play, before the queued song, would likely get cut off.
xnamkcor wrote:Give banondorf a database in which he could play a song based on a keyword.
Possible, but not necessarily practical. This would require Banon to record every song that goes through iTunes to a database meaning that he would only be able to play songs he has "heard" before. Also, our previous experience with mIRC and databases is bad. The functions are overcomplicated and end up making the code sloppy and convoluted.
xnamkcor wrote:Allow people to unfavourite a song.
This is a planned feature. It will be implemented as soon as we work out safely removing the favorite line from the favorites list file. mIRC has terrible file handling functions in comparison with other languages.
xnamkcor wrote:Allow people to PM or /msg banondorf to ask for things like DP amounts so it doesn't fill up the chat.
Definitely possible. We'll have to look into it.

So, as you can see, the question isn't about whether or not we can do it, but whether or not it'd really be worth it in the end. I think a database of tags would just confuse people, creating more harm than good. Song queuing would require extra processing for not just Banon, but iTunes and AMIP. Considering iTunes is already a resource hog as it is, this wouldn't be ideal.

Did this clear anything up for you?
Most is as I suspected, and these were suggestions. It's up to you to decide what is worth it.
Post Reply

Return to “Forum/Chat Suggestions”