*COMPLETED* MapTool b89 with Streaming Sound Functionality

[jfrazierjr]

Well IF any repos like Dropbox also works, I think it's an overcome-able pain for non techies. Then again me being part über human might suffer the same affliction as you just pointed out. Overall, I guess the best solution is when sound files can be added and accessed as tokens. Eg image:door with the equivalent sound:door as its then accessible throughout the campaign file. But me guessing it's not a trivial implementationion.

Well.. it could be for the simple case. There are a few people I have seen who have added sounds to their own personal build at a very basic level.

As for dropbox, I am actually wondering if that DOES work. For Dropbox, each file has a URL that is NOT the same name as filename, so I can't see how setting up a repository in dropbox would work.

Jz, I was thinking more about this. In theory, MT knows about all files in a "repository", correct? Although a asset/token is generally not in "scope" until you drag it on a map. But I should be able to code a reference via md5 to any asset in a repository right? Although, you would have a "naming" problem I guess. In a macro you would have to reference it by name, not md5 and there could be the same name twice. Or am I way off base with how MT cache's assets?

Just thinking, if we could solve that, then you would just upload a "mt repository" of sound files like any other asset, which is standard practice more or less, and could then use drop box... I suppose if it were easy, it would be easy to fix/add the asset search function to search all folders which is another thing I'd love to have. But this is probably a big bite to take...

Sorry for the hijack, back to your patch. If I get anything solid with assets, I'll pass it along and you can use parts of it or not. More options are sometimes good (sometimes not).

heh.. see my post above!

[JamzTheMan]

Hmmm, ya, there are definitely some room for improvements for the repository and cache. (And ya, any changes to MT 1.3 I try to keep in bite size, no reason to reinvent the wheel, leave that for MT.next, which I like as a name btw haha)

Although online servers are rare among users, Dropbox, Google Drive, etc online storage is so popular now and free and large enough to host pretty large repositories, it should be considered. Probably great candidates for plug-ins. Considering they already act like repositories in one way, eg, a unique id to a file that never changes regardless of location. You could access Assets from MT using these URL's without needing to store them in a campaign.

Imagine, you create your campaign with all images and sounds from a google drive account. The campaign would only store references to those assets via url and would/should be a very small file. When players connect, assets are cached/downloaded. Of course you could also have a "save local" option as well in case you need to go offline.

Sorry L.A, but you have a hot topic which just spurs ideas!

[Lord.Ashes]

you didn't answer my question. You reassured the fact that the sound needs to be retrieved from a 'common' server (aka repository), which confirms my idea that you can use dropbox for that (the public directory). So... is it or isn't it (usable as a repository for this function)?

Sorry I focused on the other part of your question...

The External Repository is not part of the implementation...it is up to the user to choose one. It should work with any repository that can be access via Internet (or even a local one although this would make it inaccessible to other players if it is not exposed) and the streaming type is supported by the Java Clip function (since the implementation is based on Java Clip functions). As I said, I used XAMPP Portable which is a Free Apache based server for my testing but there is a good chance that DropBox would work equally well. I tend to prefer a repository that I host myself so that I can better control who and when people have access to it but that is just a personal preference.

If someone wants to try it with DropBox, please leave comments indicating if it worked or not...so that other can benefit.

[Lord.Ashes]

Hmmm, ya, there are definitely some room for improvements for the repository and cache. (And ya, any changes to MT 1.3 I try to keep in bite size, no reason to reinvent the wheel, leave that for MT.next, which I like as a name btw haha)

Although online servers are rare among users, Dropbox, Google Drive, etc online storage is so popular now and free and large enough to host pretty large repositories, it should be considered. Probably great candidates for plug-ins. Considering they already act like repositories in one way, eg, a unique id to a file that never changes regardless of location. You could access Assets from MT using these URL's without needing to store them in a campaign.

Imagine, you create your campaign with all images and sounds from a google drive account. The campaign would only store references to those assets via url and would/should be a very small file. When players connect, assets are cached/downloaded. Of course you could also have a "save local" option as well in case you need to go offline.

Sorry L.A, but you have a hot topic which just spurs ideas!

No need to be sorry...Spurring ideas is what we are all here for, right? As long as the posts are for spurring new ideas as opposed to trying to convert my implementation into something else

[Lord.Ashes]

Attention Please:

For discussing Sound stuff or Repositories or other great ideas please uses the following Thread:

http://forums.rptools.net/viewtopic.php?f=3&t=24045

Please keep this Thread only for comments directly related to my implementation (such as bugs).

I know my implementation is not for everyone but please don't post your opinions on how it should be done in this Thread.

I am happy to hear other solution and implementations but please do that in the other thread.

Thanks.

[Lord.Ashes]

I really am not trying to be negative or denigrate your efforts, just trying to point out some things that you may not have thought of. Being a technical person myself(developer), I often find that things I find painfully obvious are totally missed on "normal"(subhuman..heh... ) people.

If anyone needs help setting up a Web Server for this purpose I am happy to help. I did not include one for a few reasons:

1. Distributing something like XAMPP Portable is probably against the license agreement
2. Generally different people have different preferences

I like to host my own stuff because I feel it gives me more control over the hosting. This is why my choice is XAMPP or similar. Others don't want to host their own stuff so they immediately suggested other possibilities such as DropBox.

The point is my implementation is the MapTool side of things which allows any repository that is supported by Java's Clip functions. This means you have a choice.

However, if people would like me to post instructions for installing XAMPP, I am happy to include them...

1. Download XAMPP Portable (google it to get a download site)
2. Extract/Unzip the downloaded file. No actual "installation" is necessary.
I usually unzip it into the root of my drive (e.g. C:\ or D:\) so that the XAMPP directory is directly off the root.
3. Under the XAMPP directory you will find an "htdocs" sub-directory
4. Copy your sounds files (PCM encoded WAV files) into this directory or, if you prefer, a sub-directory like "Sounds".
5. In the XAMPP directory there should be a file called something like XAMPP-Control.exe, run it
6. On the resulting XMAPP Control application, press the Start button besides Apache

You are now hosting your own repository. You may need to press Config on Apache, before starting it and modify the LISTEN setting to allow other computers to connect to your server remotely (most of the time this setting is set to local hosting only).

As I said, I have not tried it with DropBox but assuming it is compatible, you should be able to put your files to DropBox and then point the repository to the folder containing your sound files....However, I gave not tried this yet.

[Lord.Ashes]

Kudos for taking a big step in the right direction!

I think having the Audio Server option is a really nice option to have and I am happy to see someone creating a working sound option, but I will wait until an asset method is integrated (either on a lib token or a table.)

In addition to this implementation introducing a technical hurdle to overcome (and I'm sure it's not all that difficult to setup XAMPP), it sounds like the streaming method doesn't cache repeated use of sounds. This could be taxing to some connections and I'd prefer to use the model currently used in MT where the client caches assets and calls them locally on repeated use.

Further, I'd like to see something like this submitted as a patch to the core MT software rather than see it as a custom build. I hope this build ultimately leads to an official patch/update.

Thanks for taking this on.

As I said the token approach is desired by a lot of people but it isn't my implementation...if you want to discuss alternate approaches please do it in the other Thread...I'd like to keep this thread for actual bugs for my implementation.

My implementation does not actively cache the sounds so unless the OS does some caching, they will not be cached.

Please note that I posted both a modified JAR file (for those that don't want to build their own modified MapTool) built on the core b89 MapTool version but I also did post the Eclipse Patch for anyone who wants to implement the patch to MapTool source code (i.e. build their own). However, it is not an official MapTool patch.

I doubt that it will even become part of the core MapTool because most people seem to favor the asset implementation as opposed to an external repository. However, I made this mostly for my own use (and I prefer the external repository) so that is why it is implemented the way it is...I am just sharing with others for those that share my view. Those that don't are free to ignore my implementation.

However, please post any comments related to other implementations and/or solutions in the other Thread so that we can keep this for Bug Issues directly related to my implementation. This is actually why I opened a separate Thread for this implementation solution.

[Lord.Ashes]

Well IF any repos like Dropbox also works, I think it's an overcome-able pain for non techies. Then again me being part über human might suffer the same affliction as you just pointed out. Overall, I guess the best solution is when sound files can be added and accessed as tokens. Eg image:door with the equivalent sound:door as its then accessible throughout the campaign file. But me guessing it's not a trivial implementationion.

Wolf, if you want to play around with how that would work, it is actually in my version p jar. Just add any .mp3 to a repository and it'll show up as an asset. The macro command is playAudio([token id]) and can be played remotely via [macrolink("screamer","playAudio@lib:PlayAudio","all", "argsHere", id)]

Lord.Ashes is much farther along though in functionality. I'm going to take a look at his and see if I can merge our efforts a little. I still have more work on the asset classes as if you change the image to a sound asset right now, it'll break it. If I were to do this for 2.0 I would treat this as a different sort of "asset", not a typical token. In fact, it probably shouldn't even be required as a token, just a list of sounds files globally available to a campaign?

On one side, I see the appeal of Lord.Ashes "sound server" so you don't have to repackage common sounds in a campaign over and over. But on the other hand, if you have a sound unique to a campaign, say a npc speech or such, the user should have an "easy" way to include it without needing a server setup.

Thank you for your positive comments. I am happy to see that at least someone sees the value in my implementation and if it leads to a merging so that we implement an asset version, I will be all the more happier. I think, ideally, maybe both options would be good. Allow playing sounds off assets or an external repository. That way we get the best of both worlds and it will be up to the Campaign designer to choose which solution is appropriate for that particular Campaign.

I would love to see your work too because currently I am using Java's Clip functions which seem very much limited in what they can play (i.e. PCM WAV). I would like to eventually expand my solution to support MP3s.

[Lord.Ashes]

Okay here is the 411 on DropBox...

Yes, my implementation can technically be used with DropBox. However, it is not as easy as just dropping the files into DropBox because DropBox obfuscates the real download URL and it is this real URL that you need in order to reference the audio file.

First: As it was pointed out (and I confirmed it) that DropBox uses individual URLs for each shared file. Thus it is not possible to share a folder and then access files in that folder directly. For example, if the link to the shared folder is https://www.dropbox.com/sh/rdpwtej777thkb3/snnkkzl1OH and inside that folder is a file called success.wav, one can not access the DropBox file using https://www.dropbox.com/sh/rdpwtej777th ... uccess.wav. This means that each file must be shared individually.

Second: If you share the sound file it will give you a link such as https://www.dropbox.com/s/e9pwoq6ke5cas6b/success.wav. However this is not the URL to the actual sound file, it is a URL to page on DropBox where the sound file is being hosted. You will notice if you use this link that it takes you to a page with a download button. If you click download you will see that the file is actually being downloaded from https://dl.dropboxusercontent.com. If you do a View Source you will discover that the true URL of the file is https://dl.dropboxusercontent.com/s/e9p ... uccess.wav.

Third: Since each sound file path will be different, you need to set the AudioRepository to the common root. In this case https://dl.dropboxusercontent.com. Then you will need to specify the rest of the URL as the audio file. For example:

Code: Select all

     [audioRepository("https://dl.dropboxusercontent.com")]
     [playSound("s/e9pwoq6ke5cas6b/success")]

Since the implementation automatically adds a slash between the Audio Repository Location and the Audio Content the slash should be removed from the playSound command. Similarly because the implementation automatically appends the ".wav" extension, it should be omitted.

In conclusion: It is possible to use DropBox with my implementation but it is not very practical. In my opinion, it is much easier to set up XAMPP and host your own repository than to try to extract the real URLs from DropBox.

I have tried a similar process with MediaFire but I can not get it to stream the audio at all.

[wolph42]

thanks for the heads up. weird though, cause in the past DB has been used as repos and it was not as difficult as you described it. Whats possible is that they changed their protocols since then.

edit: weird, I just checked a couple of my public shares and
1. the links are direct (so you immediately access the file, not by some webpage)
2. the directories and naming are consistent. Here an example:
http://dl.dropboxusercontent.com/u/9052 ... icks.rptok
http://dl.dropboxusercontent.com/u/9052 ... Tokens.zip

edit2: I figured out whats going on:
if you share a link from the website then you get what lord.a reported.
if you share a link by right-click / copy public link : you get the above. So to figure out the ACTUAL repository address, you'll need to right-click/copy link in your windows directory (no clue how this works with other OS's) and NOT through the dropbox webpage.

edit3: the .bat file you provided does not work. (because you set a path straight to java x86 which I do not have, I only have the 64bit version)

edit4: just tried:

Code: Select all

[playSound("CAN.WAV")]

no errors but also no sound. I checked the log:

2013-07-30 13:33:14,706 [client.MapToolLineParser:1302] DEBUG - playSound("CAN.WAV")
2013-07-30 13:33:14,711 [macro.MacroManager:374] DEBUG - Starting macro: SayMacro----------------------------------------------------------------------------------
Playing 'https://dl.dropboxusercontent.com/u/905 ... AN.WAV.wav', Loop 1 of 1 Repetitions

so it 'appears' to be working... but I don't hear anything.

[Lord.Ashes]

edit2: I figured out whats going on:
if you share a link from the website then you get what lord.a reported.
if you share a link by right-click / copy public link : you get the above. So to figure out the ACTUAL repository address, you'll need to right-click/copy link in your windows directory (no clue how this works with other OS's) and NOT through the dropbox webpage.

Cool! So if you follow your method we do get compatibility with DropBox. You still do need to share each file individually, correct?

edit3: the .bat file you provided does not work. (because you set a path straight to java x86 which I do not have, I only have the 64bit version)

Thanks. I will correct that. I had a machine on which java was not in a path directory so I hard coded the path...it seems I must have used for my BAT template.

BTW, finally a post actually about my implementation (as opposed to discussion on other implementations)...I appreciated it.

[wolph42]

see my last edit: I don't hear any sounds.

And no you do NOT need to share each sound individually. Just create a dir in dropbox e.g. 'sounds' and setup the repository directory. From then on you can simply use playSound("name sound").

edit:

can.wav.wav

its working!!

note, maybe you want to build in a check, for user providing "soundName" or "soundName.wav" such that they both work.

by the way, if ANYONE wants to test this: set the repository to

Code: Select all

https://dl.dropboxusercontent.com/u/9052014/sounds

and run

Code: Select all

[playSound("CAN")]

in the (modified) maptool. I'll leave this sound repostory up for a couple of days/weeks

other sounds in that repository

04/02/2007 09:24 51,452 CAN.WAV
04/02/2007 09:24 27,604 COUGH.WAV
04/02/2007 09:24 40,728 COUPLER.WAV
04/02/2007 09:24 30,816 GIGGLE.WAV
04/02/2007 09:24 14,570 HICCUP.WAV
04/02/2007 09:24 42,002 HORN.WAV
04/02/2007 09:24 65,770 RADAR.WAV
04/02/2007 09:24 45,390 SHOT.WAV
04/02/2007 09:24 62,792 SHOVEL.WAV
04/02/2007 09:24 60,886 SPLASH.WAV
04/02/2007 09:24 54,858 TOOT.WAV
04/02/2007 09:24 60,018 VIBE.WAV
04/02/2007 09:24 44,682 WARN.WAV
04/02/2007 09:24 27,580 WHOOSH.WAV
chopin.wav (18 Mb)

edit: and yet another thing: it takes by the way about 3 seconds before the sound is actually played, that *is* a bit of a bummer. Also when repeat is used, there is roughly a 3 second pause between the sounds.

final edit: tested all functions, different sounds and loops: it all works!! What I did NOT test was using this over clients, but from what I understood, it currently only plays locally and thus if I were to use the autoExec method I very likely will work then as well.

[Lord.Ashes]

Rev 3 is out. This link will lead you to all 3 revisions (in case you need them):

http://www.mediafire.com/folder/ejadl2lz4drok/MapTool

------------------------
New Features In Rev 3:
------------------------

* playSoundLocal

This Macro Function does what Rev 1 did. It plays the audio locally but does not send audio cues to other players.
This Macro Function can still be combined with things like MacroLink to provide the function to other players.
This Macro Function has been added for those users that don't like the idea of audio being automatically played
by requests from other players.

* lockChannel

This Macro Function can only be executed by a GM. It determines if players can initiate audio requests on the
currently selected channel or if only the GM can initiate audio on the channel (to all players). This Macro
Function is propagated to all players (at the time it is issued) preventing players from initiating remote
audio when the lock is in effect. The playSoundLocal is not affected by this lock since playing files locally
does not disturb remote players.

* When the complete URL for a audio file is concatenated from the Audio Repository Location and the Audio Content
it previously added a slash between the Repository Location and the Audio Content. This has been removed, which
means that typically the Audio Repository Location configuration will need a trailing slash. This however means
that the Audio Repository Location can be made blank and the entire URL placed in the playSound request. This
is typically needed if you are using multiple Audio Repositories or if the Audio Repository URL does not have
a common root.

[wolph42]

in addition to my last post. I've added 'chopin.wav' to the repository, its 18 Mb. this to test ambient sound.

on my pc it took +/- 2 minutes after execution, before it actually started playing.

[Lord.Ashes]

final edit: tested all functions, different sounds and loops: it all works!! What I did NOT test was using this over clients, but from what I understood, it currently only plays locally and thus if I were to use the autoExec method I very likely will work then as well.

Thanks for the testing...but you are incorrect on the last point. Since Rev 2, the audio will play on all clients. More specifically it will play on all clients which get the audio cue. This means that the result of the playSound macro function must not be hidden. It also means that if the results of the macro are sent to only a single players (for example by using the Chat Command whisper) then it should only play the audio on that player's machines. I have not tested this but since the implementation relies on intercepting the audio cue before it is placed in the Chat Window, it should work as I have stated. I have not tried it yet with whisper.

In Rev 3, that I just posted, I added a playSoundLocal Macro Function which reverts back to the Rev 1 functionality and thus it does not automatically send the audio requests to all connected players (while the playSound Macro Function still does the automatic remote player audio requests). So now users have a choice (between local audio only, local audio passed to other via methods like autoExec/macroLink, and automatic distribution of audio cues to all players). Also note the new functionality for the GM to set if anyone can make audio requests or if only the GM can make audio requests.

Note: If you use Rev 3 you will probably have to update your Repository.Audio.txt file to add a trailing slash. The slash is no longer being inserted automatically to make the use of the setting more flexible (i.e. now it can be set to nothing and the full path can be provided in the playSound function. This way the implementation can be used with multiple repositories at once).