p5.js-sound
p5.js-sound copied to clipboard
processing
Why is localhost or https required when importing p5.sound (since 0.3.12) regardless of usage?
Wondering if it's a bug or simply necessary due to Audio Worklet, that p5.sound (since 0.3.12) now requires localhost or https once imported, regardless of any functions being used in the sketch.
Steps to recreate:
- download latest p5.js 1.0 complete
- browse to
empty-example/index.html - drag + drop file into browser window
- stuck on 'loading...'
- open
index.html - comment out line 15 (importing of p5.sound.min.js)
- refresh browser + sketch loads without a problem
- replace p5.sound import path to 0.3.11 CDN
- refresh browser + sketch loads without a problem
This might be an issue for beginners (since p5.sound is imported by default) who try to start/continue a project locally. Particularly since it doesn't fail quiety and stops anything from loading.
Is there a way that p5.sound could sit idle until actually being used within a sketch? Seems reasonable to mention in p5.sound reference docs that using any functions from p5.sound should be run as a server on localhost or https for best practice (found tip under AudioIn). Maybe an init function could be added to the core functions that are placed in the setup()? Documentation could mention easy techniques for running your code as a localhost? Simplest being:
-
python -m SimpleHTTPServer 8000(Python 2.x) -
python -m http.server 8000(Python 3.x) -
php -S 127.0.0.1:8000 - +/- source-code editor's (ie. VSCode) webserver functions
The p5sound addon is used to work with sound files in the browser. A server is always required when you're working with any files. If JavaScript could directly access the file system, it could easily upload any of your data to somewhere else online. Then all an attacker needed to do would be to trick the user into opening an HTML document with JavaScript code and they would have all your private files.
There are instructions in the documentation on how to set up a local server and there is a link to them on the p5.js website here.
@jnsjknn Thanks for your insight, however this issue isn't about javascript having access to local files (on your own machine, you can drag and drop a local file, linked to local javascript and it will load without a server) – rather this issue is about the p5.sound library now requiring localhost or https to simply be included (regardless of being used). In the past, localhost/https were necessary if using the microphone (due to browser, which is good for safety) – however, I think due to the change in using a webworker/worklet, p5.sound is now causing people's sketches to fail if they, for whatever reason, can't use an SSL certificate on their webhost and have https. I can give a quick example of this being an issue– the HTML snippet below can be saved as a file, then dragged and dropped into the browser (or run from a web server running only http.. not https) and it runs:
- It works, because p5.sound has been commented out (line 7)
- Enable that line (7) and it will fail, because it's not being run on localhost or https, stuck on 'loading...'
- Change the CDN link for p5.sound to 0.9.0 and it will work, because the earlier version only needed https when using the mic (and maybe a few other features).
I bring up this issue because it causes regular problems for my students who are learning websites/web – learning how localhost and servers work, etc.. by default p5 suggest that everyone include both the main lib and sound. If the sound library is forcing the page to use localhost/https for no reason (not even used or mic isn't used, even loaded by CDN) then I think this should be looked into. I don't know the details of how the new webworker functions and if it simply requires https.. but worth reconsidering or finding an alternative for.
<!DOCTYPE html>
<html>
<head>
<title>p5-demo</title>
<meta charset="utf-8">
<script src="https://cdnjs.cloudflare.com/ajax/libs/p5.js/1.1.9/p5.js"></script>
<!-- <script src="https://cdnjs.cloudflare.com/ajax/libs/p5.js/1.1.9/addons/p5.sound.min.js"></script> -->
<style type="text/css">
body{
margin:0;
overflow:hidden;
}
canvas{
position:fixed;
top:0;
left:0;
z-index:-1;
width:100vw;
height:100vh;
margin:0;
}
</style>
<script type="text/javascript">
// keep fullscreen if window resized
function windowResized() {
resizeCanvas(windowWidth, windowHeight);
}
function setup() {
createCanvas(windowWidth, windowHeight);
background(0);
}
function draw() {
ellipse(mouseX, mouseY, 150);
}</script>
</head>
<body>
</body>
</html>
I'm currently studying, and working on a project which uses P5. I'm having to use an old version of the p5 sound module, missing several features I would like, because I can't guarantee that those marking the project will be using a server with https.
Is there an alternative solution I've missed (for instance a way to force the polyfill into action if there still is one)?
@DaveStarmer Couldn't you put copy of p5 to your server and use it locally?
@jnsjknn Unfortunately, the project is delivered to the markers as a zip for them to run on their own local server to mark. So as far as I can tell it will completely depend on the setup of their local server whether the project will run using the latest version or not.
@DaveStarmer You should be able to include p5 in the zip.
See: Downloading a copy of the p5.js library.
@jnsjknn Thank you for the link. Unfortunately, that's exactly what I am already doing. The issue is that I cannot control how the person assessing my work will run it.
As a simple example, I use VSCode with the live server extension. If I access the page using 127.0.0.1 all is fine. If I access it using my local IP address it doesn't work because it's only a HTTP connection. So for me, that's fine, I just access using 127.0.0.1, and it loads from the file saved with the rest of the local JS.
While I can take steps to make sure I run it in a way which is compatible with getting the browser to run P5sound, I cannot control how those marking my code will run it. They may use VSCode with the live server extension but accessing using their local IP address, they may use a different editor or piece of software to serve the pages. All of which means I cannot guarantee that they will access using HTTPS or localhost/127.0.0.1 to avoid the issue.
If I could force the polyfill into action, I might be able to find a way to use the latest version. For now, unless a brilliant solution comes forward I will just continue with the old version.