New audio player - Review of iss127

[lorenzo-romanelli]

Here I added a new player to replace the default Freesound one (see #127).

For that, we are using a slightly modified version of wavesurfer.js, which will also allow us to bind it to Crowdcurio when we will need to add timestamps to the annotations (se #123). The main difference here is that the waveform is not drawn by wavesurfer.js. The Freesound images (waveform and spectrogram) are used instead.

Other problems solved are the fact that the play button was too small on the Freesound player (#14), and that playing an audio clip wouldn't stop other clips eventually playing at the same time (#96).

[lorenzo-romanelli]

There is a problem when building players that share the same Freesound ID.
The player template now looks more or less like this (see datasets/templates/datasets/player.html):

<div class="player_container">
    <div class="soundplayer" id="s{{ freesound_id }}">
        ...
    </div>
</div>

var playerOptions = {
   ...
   freesound_id: "{{ freesound_id }}",
   ...
};
var player = new Player(playerOptions)

Wavseurfer.js wants the element where the player will be built in (/static/audio-annotator/js/src/player.js, line 20), so I need to know beforehand what's the ID of the player.
The problem arises when the same sound is present twice in the same page, because two elements with the same ID will clash and break down everything.

If I want to generate dynamic and unique IDs on the server-side without using global Python variables, I need to know either:

1. how many players will be built in that page (which I cannot know, because on the same page there might be some players loaded asynchronously via AJAX and only when the user clicks on something), or
2. which freesound ids have already been used, so that I can modify them by adding for example a counter at the end of the id (s123456_0 and s123456_1 for example).

Solutions that have been proposed are:

1. using the current timestamp as the player's ID
2. using random numbers
3. using global Python variables in the template tag
4. using a counter in the template (but again, if there are AJAX requests which dynamically include other templates this breaks down)
5. using Python's UUID4 function (https://docs.python.org/2/library/uuid.html#uuid.uuid4)

Otherwise we should find a way to pass directly the element to the Player constructor in the player template.

@alastair @xavierfav any other ideas/opinions?

[alastair]

In the case of the player in player.html, I see that the javascript and html are both in the same file. In this case, I see no reason to have an "easy to understand" ID. In this case I recommend that you use a uuid4.

[xavierfav]

A few minor comments inline.

I have this bug on the vote form when annotating:

I guess something is wrong in the static/css/main.css file.
Let me know if you can reproduce the same problem

[xavierfav]

Raising an exception here would make more sense.

[xavierfav]

clear commented script here

[xavierfav]

I think loading the general template tags here is not needed

[xavierfav]

clear commented code

[xavierfav]

Is this "cache: true" really needed in the end?
There are other part of the code where there are this sort of AJAX requests for pop-ups.
I never saw problems with not caching some code, and since we finally send the lib files in the HTML template that includes the player, it is I guess not a problem anymore?

Anyway, I don't say to remove it. Just want to understand if this would be needed in other cases.

[xavierfav]

clear

[xavierfav]

clear