Drag and Drop Audio Bug?

jpospisil

Not sure what's going on here, but I tried to create a drag and drop option to play audio (for now that's all it does), but if I drop in a second audio file before the first one has finished, it just plays both at once instead of replacing the first one. I based it around the example for Dom titled "Drop".

Code looks like this:

var aud;

function setup() { // create canvas var c = createCanvas(710, 400); background(100); // Add an event for when a file is dropped onto the canvas c.drop(gotFile); }

function draw() { fill(255); noStroke(); textSize(24); textAlign(CENTER); text('Drag an audio file onto the canvas.', width/2, height/2); noLoop(); }

function gotFile(file) { if (file.type === 'audio') { // Create an sound element but don't show it aud = loadSound(file.data, gotAudio,loading);

} else { println('Not an audio file!'); }
function gotAudio(){ aud.play(); }
function loading(progress){ print(progress); } }

GoToLoop

• https://forum.Processing.org/two/discussion/8045/how-to-format-code-and-text
• https://forum.Processing.org/two/discussion/13569/catching-file-not-found-errors-with-loadsound
• https://forum.Processing.org/two/discussion/13650/dropped-image-not-showing-in-the-draw-loop-gotfile-createimg-image

blindfish

Welcome to the world of JS closures :)

From what I can see loadSound() internally creates a new p5.SoundFile instance within its scope. That means that whatever you do with the variable you assign the result of loadSound to (in this case 'aud') - e.g. assign the result of another loadSound call to it - the original p5.SoundFile instance may live on regardless: it's a totally separate object. If that's the case then this could be a bug and perhaps even a potential memory leak...

It's late here; I'm tired and recovering from a cold; so the above assumptions could do with some serious sanity-checking; but the practical workaround should be easy enough: in your gotFile event check if aud is playing, before running loadSound (i.e. before you lose the reference to the original SoundFile object), and if so stop it...

I may get some time to test my above assumptions; in which case I'll post an update.