- From: Charlie Roberts <bigbadotis@gmail.com>
- Date: Wed, 20 Nov 2013 09:14:27 -0800
- To: James Ingram <j.ingram@netcologne.de>
- Cc: public-audio-dev@w3.org
- Message-ID: <CAOn5zEjnNg7Rv0d_xQ3WKo7xQxkAidN8Z_p9F4d6eKVe9Nyfhg@mail.gmail.com>
Or (much easier) run a web server on your computer and then load the files via http from there... perhaps I'm not understanding the question correctly though. On Wed, Nov 20, 2013 at 9:11 AM, Charlie Roberts <bigbadotis@gmail.com>wrote: > This doesn't exactly answer your question, but as a workaround perhaps you > could use the cache manifest? > > http://www.html5rocks.com/en/tutorials/appcache/beginner/ > > It has worked well for me when performing, although I haven't been using > MIDI. > > - Charlie > > > On Wed, Nov 20, 2013 at 5:26 AM, James Ingram <j.ingram@netcologne.de>wrote: > >> Hi, >> >> I'm trying to make a version of my application [1] which will work >> offline. >> >> This is important, because I want to use it during live performances, and >> can't rely on the internet being available at all venues. >> >> So I need to work with local files. >> >> As far as I can see, the only way to load local files into a web page in >> Chrome is to deliver them inside a Chrome extension. >> >> But Chrome extensions can't share variables (e.g. midiAccess) with the JS >> on the main page, so I need to call navigator.requestMIDIAccess() inside >> the extension. >> >> But navigator.requestMIDIAccess() isn't defined there, so I'm stuck. >> >> I see no reason why navigator.requestMIDIAccess() shouldn't be defined >> inside an extension. There's no more security risk accessing midi devices >> there than anywhere else. Maybe it's just an oversight? >> >> Any ideas? >> >> All the best, >> James >> >> [1] http://james-ingram-act-two.de/open-source/assistantPerformer/ >> assistantPerformer.html >> >> >> >
Received on Wednesday, 20 November 2013 17:14:58 UTC