Project Outreach Letter - jhhl/AUMI-Together GitHub Wiki
Outreach letter to send to technical people who may want to help.
They don't have to be experts on all of these issues, but help with any one of them will keep me from using soon-to-be obsolete technology, or having to write already figured out software myself.
I'm Henry Lowengard, and I'm working on a project that is a web app musical instrument program called AUMI Together.
Take a look at http://aumiapp.com/aumitogether.php and [aumiapp.com](http://aumiapp.com/ to familiarize yourself with this project. This new web app will be using a few technologies that I'd like to get opinions on before I dive in on using them:
-
Camera support: many browsers, desktop and mobile, support cameras inside of them, and in fact you can get a good list of them and dynamically update that list as video sources appear and disappear. However, what the actual native resolutions and other capabilities of the camera you choose are obscured. I can pretend that they are all 640x480, but part of the trick with this app is to not post process the inputs as much as possible so there's a fast frame rate. It may be that I'd just have to code up a table with devices that I know the properties of, but I'd rather get real information about that.
-
WebAsm: this new technology may be helpful in porting over some efficient tracking algorithms that need to run in the browser. I have a toolchain for it, but am not sure if I can rely on it on all platforms, and need to have good strategies for "polyfilling" code with perhaps less efficient but workable equivalents.
-
Machine learning in web apps: I've seen it work; I'd love to know the best strategies for executing and building the models used that would take up space efficiently.
-
Progressive Web Apps in general: years ago, all you needed was a manifest document; now tasks need to be allocated to webworkers which I think can pull cached data instead of going for it on the web among their other duties. I have a vague idea of how to break up my work so this can be efficiently done, but Ideally, outside of already downloaded sound data, I'd like to get advice in running offline or with sporadic connections, and recovering from disconnections and detecting corrupt and incomplete data.
-
I'll be updating my existing (primitive) instrument sample players to be more compact and efficient. Ideally, it'll be modular enough so it can be open sourced so that others can use it. I'd like to get some practical and legal advice on how best to do it, rather than to just make a Github repository open.
-
Similarly, this project is going to have an way of organizing its documentation that might be useful to others if/when it's done that would need the same treatment and concerns before going open source.
-
This project's second phase is to integrate it with a conferencing system, which I hope I can adapt from an existing one. It will need customization to handle various aspects of conferencing and session management that might not be a priority in the existing software. What's robust, under active development, etc. in this space?
-
I'm sure plenty of other issues will come up as the project progresses.
-- Henry Lowengard [email protected]