def sayWav(String wavUrl, List backupTts) {
    def URL_REGEXP = /http(?:s?):\/\/\S+/
    def index = 0
    def sayMe = wavUrl.replaceAll(URL_REGEXP) { match ->
        return "[ $match | ${backupTts[index++]} ]"
    }
    say(sayMe)
}
 
sayWav("I'm sorry http://example.com/dave.wav I'm afraid I can't do http://example.com/that.wav.",
     ["dave", "that"])
// equivalent to:
// say("I'm sorry [ http://example.com/dave.wav | dave ] I'm afraid I can't do [ http://example.com/that.wav. | that ]")

Rather than double curly brackets, I personally prefer single square brackets (as media-wiki and some other wikis use), many text editors have nicer support for single character brackets and there’s not much reason for those types of characters in normal TTS dialog.

Another alternative that I was thinking of would be similar to the wiki syntax, but might read nicer. It’s use sort of a prepared statement syntax where you’d have placeholder TTS that would be replaced by the values in an array of wav files in the 2nd parameter (if they can be found):

    say("I'm sorry [Dave] I'm afraid I can't do [that].", 
        ["http://example.com/dave.wav", "http://example.com/that.wav"])

When I’m doing VXML apps, I’m normally coding the TTS version first as the audio hasn’t been recorded yet, so I think this style would fit my workflow better. That might not be true for everyone.

The great thing about you guys opening up the platform to using languages like groovy is that even if I don’t like the particular solution that you come up with, as long as you provide the basic building blocks, I can write code to adapt things to my liking :).

>Looks like most of the coolest stuff is on the currentCall and incomingCall objects.

incomingCall is the Java object that implements the Tropo “raw” API. We have what we call a shim script in each programming language Tropo supports that uses the raw API to implement a per-language core API. The core API is what you see in currentCall. In the output above currentCall is the Groovy implementation of the core API.

The current Tropo documentation is all about the core API, but we’re exposing the raw API too to encourage development of other frameworks. In fact, we already have an enhanced framework that was built by a Ruby-guru (I’ll let him announce it) that we plan to bring to Groovy as well.

> [missing things] like backup TTS for missing .wav files

Yep, this is an item we discussed – but didn’t settle on an answer before the launch.

Currently you play an audio file by simply including a URL in any prompt string you send to the Tropo prompt/say/ask commands, like this:

“Hello, this is a bell: http://tropo.com/bell.wav Did you like it?”

We are looking at either:

1. Adding a Wiki-like syntax, like this:

{{url|alternate-text}}

Example:

“Hello, this is a bell {{http://tropo.com/bell.wav|bell}}. Did you like it?

2. removing the simple inline-URL syntax and only having the Wiki syntax above. One reason is to make it easy to read back a URL as a string in text-to-speech. Currently you have to escape or format a URL for Tropo to read it instead of play it.

I’d love to hear any thoughts or alternatives anyone has related to the above options.

> I believe that they have plans to fill in many of these gaps as the product matures and moves out of beta

Absolutely. Over the next few months the Tropo API will get support for nearly all of the features found in our Prophecy CallXML, CCXML, and VoiceXML browsers. Tropo re-uses most of our Prophecy technology, including the SIPmethod Java JSR-289 SIP servlet engine and our Java JSR-309 Media Control API talking to our own MRCP-based media server… so its easy to get things going quickly.

We’re also adding support for a few more programming languages. :)

-Jonathan Taylor
-CEO (Coding Executive Officer) Tropo / Voxeo