Completed audio repository plugins

During Google Summer of Code 2009 project I worked on implementing repository plugins that would allow users to record audio files directly into Moodle. Initially, the plan was to provide a single recording only, but things went a bit further, and I also implemented a collection management feature.

Both plugins have integrated help pages for all their features, but additional help (mostly for developers) is in the Record audio repository plugin wiki page. Some discutions focused on audio and/or video recording in Moodle are in the Record audio repository plugin (was Wanted: New feature ideas for GSOC projects) and GSOC: Record Audio/Video directly into resources/activities forums. The later is more general, not only about the repository plugin. Last, but not least, there also a place for feature requests and bug reports in the MDL-18341 ticket.

The plugins are not included in the Moodle releases (not even the 2.0 dev daily build). In order to test them, you'll need to use a 2.0 dev daily build.

The Riffly plugin allows audio-only or audio-video recording inside the Moodle repositories. The flv files are stored on riffly.com servers and, optionally, they can be downloaded into Moodle (to go under Moodle File API control). Recorded files and the recording flash object is available in all places where the repository is used to select files.

After you download a Moodle 2.0 dev build, you'll have to download the plugin manually from CVS and copy the entire riffly folder inside the repository folder of your Moodle instalation. Then go to the Plugins/Repositories entry of the Administration menu, enable the plugin and make it visible. When you're done, you'll have the option to create riffly site-wide, course-wide or per-user collections. For each collection, you can choose what type of content it accepts: audio, audio-video or none of them (to get a locked collection).

The Nanogong plugin allows audio-only recording inside the Moodle repositories. The wav files are stored into Moodle using the File API. The sound files can be recorded using the ImaACPCM or Speex codecs. As for the riffly plugin, recorded files and the recording applet are available in all places where the repository is used to select files.

After you download a Moodle 2.0 dev build, you'll have to download the plugin manually from CVS and copy the entire nanogong folder inside the repository folder of your Moodle instalation. Then go to the Plugins/Repositories entry of the Administration menu, enable the plugin and make it visible. When you're done, you can select the codec used and the quality of the sound for the site-wide recording instance. This instance will be shared by all users of your site (because it only handles recording, and File API handles the rest).

Almost there

The riffly plugin repository is almost completed. Jerome is helping me with QA and squashing bugs. The plugin now supports multiple instances (per site, per course and/or per user) and each of this instances can be setup to support only audio media, only video media or audio and video. Also, each instance can be setup to download the riff files locally (for management using Moodle's File API) or to link to the files on riffly.com (very useful, if you have limited storage space or bandwidth).

Meanwhile, I started work on the second plugin, which is using the Java applet nanogong.

Code is in CVS

The code up to now it's in CVS. I did some changes to the recording scripts, factoring out the common part in record.php. After Jerome noticed that recording is limited to 10s, I fixed that and set a limit to 1 hour. I also fixed some other bugs that Jerome reported and made some changes to the UI (the recording links placed at the top now; no longer mixed with the recorded content). I'm currently working on integrating this plugin with File API.

CVS write access

My application for CVS write access was accepted and now I have write access to contrib/plugins/repository/riffly. I'll commit the plugin as soon as possible (probably after I'll do the changes Jerome proposed).

Midterm plugin

This week I "finished" the repository plugin for integration of riffly.com web services. I got carried away so I added more features than I initially planned for (like video recording). Before going into more details, you can go and download the plugin from the ticket #MDL-18341.

Instalation: Inside the tgz'ed file you'll find only one folder (called riffly) that you'll have to extract in the repository folder of your Moodle instalation. After that, go to Moodle's Site Administration menu and drill into Plugins/Repositories/Manage repositories. Click on the "Add Riffly" link and then enable the Riffly repository plugin.

Usage: As I said, the plugin has many features (although some of them are not as visible as they could be), so I will not present them all and let you discover them by yourself. Just a few tips:

• how to insert a riff in your document: you'll have to use TinyMCE's "Insert/edit embeded media" button. Click on it and then click on the Browse button (to the right of the File/URL textbox). In the File Picker, select the riffly source. There you'll see the riff manager option, the record audio option, the record video option and any riffs you recorded previously (or added manually through the manager). Select the riff you want or record a new one, enter its name (or a description) and click the "Select this file" button. The rest is business as usual.
• how to manage your riffs: follow the previous steps, but select the "Manage collection" instead of an riff. You'll see a list with all the riffs in your repository (including their name/description, ID and preview areas). You can remove items from the repository or you can add new items if you know their IDs (Yes, you can share riffs with your friends by sharing these IDs)

Things that might go wrong: The code was developed against the HEAD of Moodle's CVS and it works ok. However, I spent an entire day tracking down a bug that prevented the file picker to show its content (repository categories and items). It seems a bug found its way into commit 1.19 of lib/form/editor.php (Petr was so kind to help me find it). Either check it was fixed in a following version or use the 1.18 version from HEAD.

Things that didn't go as planned: I broke my Moodle working enviroment twice this week with CVS updates. It's normal for a product in development phase, but that doesn't make it less annoying. 

I planned to create a TinyMCE to ease the proces of recording (and open the file picker directly). I never developed for TinyMCE before. I got maybe 60% of it done, but yesterday I got stuck in some JavaScript issues. Today, I found some ways to make it work, but I'll have to postpone work on it for a while.

Because of the TinyMCE plugin, I didn't have time to write the text filter, which would be probably much more easier and straightforward (I went with the challenging/fun part).

Back to work

My short trip to Iaşi is over. I attendend the ECODAM 2009 Doctoral Summer Workshop. There I assisted to some very interesting lectures (both from invited speakers and from other PhD students) and I also gave a talk about bonds representations in Ising spin glasses.

Unfortunatelly, last moment problems before leaving stopped me from submitting the last week's work summary and once got there my online time was very limited (between lectures, organizing activities, and spending time with my favorite niece). Therefore I'll do a two week summary in one post.

I finished the code for retrieving riffs metadata from Riffly. This is used when the user manually adds a riff to the repository.

I refactored the JavaScript code for integration of Riffly callback API with Moodle. It's much cleaner now, using AJAX POST to send the data back to Moodle repository and callback functions to update the File Picker location only if the riff ID was correctly stored in Moodle. If the store process fails, the the File Picker location will not change, so the user will be able to retry.

One problem that gave me major headaches (especially because I didn't have an Internet connection to search for more data) was the inconsistence between YUI's asyncRequest docs and implementation. Documentation says that the callback can be a function or an object. This is either wrong, or Moodle's YUI version it's older, because a function doesn't work. Finally I found the solution: use an object with success and failure methods.

When I updated code from CVS, I got the surprise that the HTML meta got deprecated from print_header. I was using it to inject some small JavaScript code (a hack, I know). Anyway, I had to learn about the new way to do it: using the require dynamic property of the global $PAGE variable. So now, the JS is on its own file, connection to Moodle through the riffly JavaScript variable.

Finally, I applied for write access in contrib/plugins/repository/riffly so I can start to commit.

To do: these are some ideas that might be good to implement:

• automatically select a newly recorded file (to save the user a few clicks);
• implement a text filter (Jerome sugested to look at the youtube filter for an example) instead of using flash objects;
• create a TinyMCE plugin to make recording easier than it is now (about 3 mouse clicks instead of the current 6 clicks).

First glimpse

The plugin I'm working on is starting to get a face, too. I almost finished the rough user interface. It doesn't have all the bells and whistles of Mihai's work, but it's enough now for testing the backend. I'll probably have to work on it some more after I get the feedback from Jerome. This is how it looks right now.

The user accesses the repository instance (in this case, called something). She/he will always see two pseudo-entries: manage collection and record. In addition to these, all the audio items in this instance's collection will be available for selection.

NB: The repository framework only supports thumbnail images for previews. This is not very usefull in the case of audio content. One of these solutions could be used:

1. implement a way to add textual description to entries and display those instead of generic "Audio file" text
2. implement a way that plugins can render their own HTML code for thumbnail (I think this is more usefull: @todo: check this with Jerome and Dongsheng)

The Manage collection entry displays a page where the collection entries can be deleted, previewed or added. This is usefull if you want to move items from one collection to another or to add an item that you now recorded.

NB: The i18n is not fully implemented and many language strings are missing.

Finally, the Record entry displays the recording Flash object. It allows users to record audio content and save it. I'm still fighting some JavaScript issue in order to automatically store riff ID and select it in the file picker after recording. This also brought me to my first contact with YUI. It's ok, but I like JQuery better. JQuery is simply more fancy, lightweight, and ... more fun.

Riffly API update

These are some additional information I managed to obtain about the riffly.com services. First of all, the API does not offer an username/password authentication method for premium users. If a user has a premium account, they add their domain in their control panel on riffly.com, so it will auto-detect any riffs that are played from their domain.

Second, the metadata for riffs is only available though JavaScript. More exactly, imagine you have the ID of a riff: B47686169D7111DC9B0D44CF0D09CCE3. In order to get its metadata you have to read http://riffly.com/api/info/B47686169D7111DC9B0D44CF0D09CCE3, which will give you something like this:

{
  "created" : "1196227339",
  "riffly_id" : "B47686169D7111DC9B0D44CF0D09CCE3",
  "playbacks" : "80",
  "type" : "video"
}

The most useful things here are the created timestamp and the playbacks count. Unfortunatelly, in order to display these in the File Picker, I would have to get these files for each riff and parse them in PHP. I'm not sure it's worth it.

A possible solution is to find the a way to embed some <script> tags in the File Picker that load JavaScript from this address http://riffly.com/api/info/B47686169D7111DC9B0D44CF0D09CCE3?callback=myCallback. The code produced by this address will call the myCallback function. Unfortunatelly, I'm not sure this will work with HTTPS Moodle instalations.

No riffly.com reply yet

I haven't got a reply from riffly.com, yet. It's not urgent, because I can work on other stuff, but I was curious to get more details. I have another batch of questions ready for them, but one thing at a time.