Good evening.
I pretend to add to Iberia MUD the functionality of playing a soundtrack while a player is logged on. I am aware I have the option of having a bunch of MP3 and randomly play one of them using MSP/MXP (which implies their download beforehand), but as I already have a sound stream engine, I wish to keep using it (all players tunning to that stream will listen to the same "synchronized" soundtrack).
Currently the access to that stream is only via website: players click in a link that points to a pls file, that "forces" the standard sound player to open a connection to the stream.
I want players to connect to that stream by MUD client connection only. I guess the best shot is to use MSP or MXP sound/music elements. The problem I am having in this approach is that it downloads the .pls file (testing with ZMud) but doesn't attempt to play it…

What eventually I am doing wrong for client doesn't force standard sound player to play the .pls file? What other options/approaches do I have (don't want to consider a custom client)? Eventually MSDP with snippet to play it in some way (not aware of most of this protocol potential)?

Thanks in advance.

Not sure about ZMud functionality, but I'm going to assume that it doesn't play files by opening other software, but rather plays them itself (as MUSHClient does, although it sounds like MUSHClient invokes DirectSound somehow, which is the sound equivalent of DirectX). This means that it probably supports a minimal ability to play files and in fact may not be able to play .mp3 files at all, much less work with a playlist. I think VLC can play those files (https://wiki.videolan.org/PLS/). You might be able to write a MUSHClient plugin using Lua? that could invoke VLC from the command line and pass it the location of the playlist file.

Not aware of ZMud ability regarding extensability, but I guess I can also eventually try to script it there too. Thought could be easier and using current known protocols, so such option could be client independent. I could make the address to playlist a clickable MXP tag; can I then automatically emulate a click on it in any way? :)

http://www.zuggsoft.com/zmud/mxp.htm

Not sure. ZMud is a windows client, so it might be sufficient to make up some protocol handler name and then use it with MXP and hope that windows can figure that out and launch the appropriate program?

Don't want to stick to a client, but guess plugins are my best shot then.
Thanks for your inputs!

That's understandable, but plugins/scripts (or whatever they call them) are the closest you can get to a custom client without having to actually make one. I'm not sure there's any client out there with full support for everything – though some come closer than others. If you're going to be looking at making adjustments to clients, you might look at Mudlet too while you're at it. I think they're somewhat active in development and it's a fairly new mud client by comparison, so it might have more flex and be less limited/tied down in what it supports/can support.

MUSHClient

If you're going with a plugin for MUSHClient, aside from scripting the launch of an external program, you might be able to code up some kind of mini audioplayer plugin/gui/box/widget within the program that can handle out-of-band (OOB) communications. I.e. write a little audio client/player that grabs or is sent any MSP messages and stores both a playlist and cached information about where the music is. It could interpret by checking the filetype sent that you are sending a playlist and store that so that it knows what to download and if you hand it a url with the MSP U parameter then it could figure out where to get the files from. I'm assuming that if that scripting language has it's own socket libraries (Python, Lua?) that it might be able to open a socket to somewhere and get the files. Alternatively some use of the UDP scripting functions noted below might be usable to code a file downloader. Not as pretty as full streaming, but it might suffice.

If you're really concerned about synchronizing, you might "extend" the MSP protocol (not the best idea, but what can you do – might be a benefit of using MDSP, in that it's more flexible in format) to include information about when to start playing. You may be able to emulate some aspects of streaming by sending a reference time (server clock and timezone) and asking it to start playing music a certain amount of time after that and each client would check against it's local time and determine when to start playing the music. Some aspect of this might also might be extendable to playing music in step with others by asking it to play the music at low or no volume and setting it to continue playing even if you send the message again, and then send the request again at a new (audible) volume. That would mean a bit of a delay dependent on the music initially and any time a major synchronization was needed, though. If you have a long piece of music, you might make it a little more repetitive and add some bridges ( http://en.wikipedia.org/wiki/Bridge_(mus... ) or empty space in it to accommodate for this so there's a little musical variation from the main that's long enough the other players' clients to start playing the music from the start and thus be at a musically equivalent point.

Also, and this is far out and wild speculation which I can't confirm the workings of in the slightest, but there are UDP script functions (http://www.gammon.com.au/scripts/functio...)

UdpListen Listens for incoming packets using the UDP protocol
UdpPortList Returns an array of all the UDP ports in use by this world
UdpSend Sends a packet over the network using the UDP protocol

I'm thinking that maybe, just maybe, you could text encode your binary packet data (the sound) using a method like that done for BinHex (http://en.wikipedia.org/wiki/BinHex) and then cook up a sound file from that data somehow and then use that as the next "sound file" to play and assuming a fairly small gap space between playing separate files you'd have continuous sound. Depending on whether the scripting is powerful enough to edit files and if the sound system loads the whole sound file to play from memory you might actually be able to ask it to play the file in a loop (i.e. repeat it endlessly), but modify the actual file to contain the next chunk of music while the current data loaded from it is playing.
—

You should read this -> http://www.zuggsoft.com/zmud/msp.htm for information on what I guess is the official/pseudo official spec for MSP. It's good to have a sense for what you can generally expect an MSP implementation or "hack" to handle correctly.

It may be of some help, in the case of MUSHClient to check out existing "plugins" (http://mushclient.com/mushclient/plugins...) like the one that makes MSP work (http://www.mushclient.com/plugins/msp.xm...).

I'll tell you what I would like and think should be done: main clients starting to accept other music formats in MSP, like MP3 and playlist files. In 2013 seems a normal expectation for a theoretical MSP. Workarounds on this are odd… a sound protocol already exists.
Anyway, you pointed some somewhat detailed options. This is not the first item on my todo list, but when I start to dig deeper about it, then I expect to present a wider solution for whole community. I feel that's not the way (reinventing the wheel!), but enjoyed the encode sound in text and send it OOB:)
Thank you once more.

Urgh, lost my nice long post. :( I guess I'll try to summarize:

It's probably a reasonable "expectation" for 2013, but that's unlikely to happen for reasons. :(

Such reasons include the patchwork of supporting servers and clients. Not every server uses MSP and not every client supports it. Then there's lowest common denominator issues where the difficulty of reaching agreement on an improved standard means that anyone extending MSP is probably going it alone and can't expect to have ANY client support their version.

In the case of clients there is a big issue when it comes to MP3 decoding. First, there have been legal issues in other contexts because MP3 is patented and, secondly, free/open source decoders like FFmpeg potentially saddle you, your code, and your userbase with license issues/restrictions. Further in the case of MUSHClient, which uses the DirectSound api, according to the internet "raw" DirectSound does not support MP3. That you means the client has to handle the decoding itself somehow and then massage the decoded audio into
something DirectSound can handle.

I'm glad you enjoyed the idea, although I was being at least partially serious. I was suggesting a way to accomplish some of what you wanted in the immediate now without needing a entire custom client. As a side note, if you actually wanted to do that, you probably need make your sound engine an mp3->wav conversion up front. Not good for low bandwidth probably, but easier than modifying MUSHclient to do decoding.

My guess is there's a reason why MSP is side-lined. I've yet to meet a MUD player who is at all interested in sound.

That said, at some point I'll probably add an HTML5 media player to the portal app, just because it's fairly easy.

If you want to have players listening to the same stream, you may want to look into an Internet radio streaming app. From what I recall, there are some very good free ones. The streaming URL may be something you can pass to a client via MSP (you may have to fake the extension).

Indeed in the MUD portal seems fairly easy: with the media player your are planning to add and MUD admins being able to define their settings, seems it can be plain easy to point default music to an existant stream.

Also, plamzi, I already have the stream - players can reach it via website. I would like, though, to make it tunnable by players right when they login using whatever client they wish (I would be really happy if the only client prerequisite for this is a client that deals MSP).



MSP, at least in ZMud, already does his work by downloading the .pls file from the URL (via !!music) I send from server. What I wish is that ZMud/client with MSP to "order" OS to execute that file using the standard music player, which is not happening.

Nathan, I guess those MP3 license problems are not a problem at all if what the protocol does is just force winamp/vlc/whatever play the file with the given extension. I can identify that sounds in muds should work with very short delays (I use some sound triggers to warn me when I am attacked PvP in one of the muds I play, so when I am working in another window I can still be warned by the sound alarm) and forcing third programs to open and execute do not accomplish that with efficiency. Anyway, I wouldn't see it wrong to accept all known music extensions and use client sound player only for .wav or .mid files and redirect all others to the standard player. Also, in my understanding a minimum delay in !!sound is critical to have and less critical in !!music…

As I am writing this, I just confirmed this in ZMud MSP specification page about !!music command:



Here, .pls files open directly in Windows Media Player, so seems clients are not not behaving properly considering the specification. Not a surprise, though :)

I suppose that wouldn't be an issue with that kind of redirect, but my point was that it might scare away people from implementing it directly in the client. Just having the client handle it all is ideal for fixed length music and sounds that don't need to be perfectly synced as it keeps you from needing other programs just to have some sound. You say they open with WMP from zMUD? That's interesting. It's possible that the behavior in the specification is too vaguely specified. Although, I think that's not a specification so much as a statement about client support. In any case, MUSHclient invokes the DirectSound API to play .wav (.mid?) files. So it is technically sending it "directly to the operating system".

As far as the internet indicates DirectSound simply doesn't support MP3s (you'd need to convert to wav or use DirectShow?). So that counts at some level as a lack of OS support for other files.

Frankly, the specification probably should be revised or clarified to define some things more closely, like how other file types should be handled, other than just silently dropping the request. Maybe the client should send an inline message or an alert to the user indicating an unsupported file type?

@plamzi
I'd like sound (one of the things I really like about MMOs is background music and weather), but I can't think of any game that has it that I've ever looked at their site or anything. It may just be distracting to some people. Mind you that I don't play a ton, I've tried a couple muds but very few make me want to keep playing. Either their interface is a bit obtuse or there isn't enough guidance to get me started (a full-on MMO style tutorial is a bit of a stretch, but a couple specific things to do and an initial quest or two for games with quest/quest-like systems would be nice – p.s. Epitaph is nice in that regard.).

I've stated what I suspect to be some of the reasons behind not having/not using it, at least in clients. That though does derive somewhat from real usage of it, if it isn't used much then few consider it when writing clients or servers.

Of course, how many mud clients/servers support true, proper telnet and option negotiation…? My code sure doesn't… (frankly it took me a bit just get it to a point where it could deal with being sent a character at a time) If they don't have a way (e.g. telnet neg.) to talk to the client and confirm the use of MSP then they probably wouldn't bother since they'd have to either record player preference or require them to turn it on each time. Really, I think you'd want a client with MSP support that could play intro music. It seems like a no-sound intro (i.e. login screen) would be a turnoff for someone who wants sound.

Hmm… MSP is a client-server protocol, and if a client supports it, it is expected to play music/sounds. Apparently zmud implementation is plain straight: sound "sent" to OS to play it. Other clients supporting MSP should assure they can play sound/music, be it hardcoded on client or not. Other than this, then prolly clients shouldnt announce support to this protocol.

The real issue is that known clients dont fully follow protocols. Ironically, even the client from the "creator" of the protocol.

I wanted to say that in my PC, WMP opens pls files directly; this means that zmud should be able to order my OS to open/play it, which is not happening.

Sound is a big deal for visually impaired mudders. Check out the Alter Aeon sound pack or the forum at audiogames.net.

The VI players I've interacted with so far were interested in screen readers and speech-to-text, not "game sound" in the conventional sense. But, I haven't met everyone :)

P. S.
At some point, very early on, I added trigger-able sound effects to the MUDMaster iOS app, basically with VI players in mind. No-one has ever mentioned using those. Maybe they do, silently!

https://www.google.com/search?q=alter+ae...

Figured out only Zugg clients deal natively MSP, after checking on ZMud and CMud, Mushclient, Wintin and Mudlet. Both ZMud and CMud download the .pls file with the !!MUSIC directive, but none are able to make it play.

I didn't get a clear sense if you already tried faking an extension.

If you're using MSP to pass a URL and filename, the only way for a client to know whether to try to open a file in an external program is by what it sees as the extension. Now, a shoutcast stream such as:

http://149.255.33.76:8096/;&topspeed...

will work just fine if you access it as:

http://149.255.33.76:8096/;&topspeed...

This may fool clients into thinking this is the URL to an mp3 file that needs to be opened in an external mp3 player program.

Sorry for not clearing that earlier. Yes, shoutcast can be accessed with an address like that ending with mp3, but the behaviour of ZMud is first trying to download the mp3 file, then play it. As it is a stream, will permanently be downloading and never playing.
I guess the pls, m3u or other playlist files were needed exactly to avoid those kind of problems…

What?

So, an MSP client ignores the normal web protocol of using the context type header and passing the (completed) download to whatever external program matches the MIME type, often letting the OS make that decision?

EDIT: Hint… it should be doing a HEAD request to obtain that information, so downloading a stream doesn't sit there forever.

You're misunderstanding my point. What I was trying to convey is that if I was writing a client that doesn't play MP3 internally, and I get a filename with an .MP3 extension, I would be very tempted to just hand it off to the default MP3 player rather than go on to detect if the remote file is *really* an MP3. So, it was a viable idea for Viriato to try and give the file an extension that these clients would just pass on.

Obviously, if my client *is supposed* to support a file type, I would go to the lengths required.