From: Dominique F. <fo...@gr...> - 2014-01-09 13:34:40
|
Hi Alex, Did you also considered PNaCl : http://www.infoq.com/news/2013/05/pnacl-google-chrome-llvm http://www.chromium.org/nativeclient/pnacl/introduction-to-portable-native-client This approach could save you a lot of effort, also with the benefit of compiled and optimized LLVM code. The drawback is that it is restricted to Google Chrome but I think the future (or at least a great part of it) relies on technologies like LLVM. In addition, rewriting the engine in javascript is a kind of fork, in the sense that further improvements of the code, whatever side it is, won’t benefit to the other implementation. That’s currently my main concern for the deployment of Guido (and of INScore too) on the web. Best, — Dominique ps: concerning the web service, it is running on http://guidoservice.grame.fr (in case you want to experiment) It differs from the NoteServer since all the library API is available and thus, one could potentially build real applications over the web. The guido station is not very stable and could be temporarily unavailable because it has recently suffered of piracy. The service documentation is available at http://guido.grame.fr/ Le 7 janv. 2014 à 16:19, Alexander Dorsk <al...@mu...> a écrit : > Bonjour Dominique! > > It is a pleasure to correspond with you, I really admire your work on Guido. And other projects too! I actually just sent the INScore demo video to a friend, who thought it was great. > > I'll respond in-line. > > > Concerning the web, there is already an approach that should be published soon : a restful web service embedding the guido > > engine and providing the guido library API over http. > > Cool! I think this could be a nice service. Sounds like it will be a nice evolution of the original NoteServer project. > > > Could you tell what is your approach ? Rewriting the engine in javascript ? automatically converting the C++ code in javascript (as > much as possible) ? a mix of both ? > > My approach is to rewrite the engine in Javascript. Currently I have ported the parser and a few of the AR classes: https://github.com/musikata/guido.js/tree/master/src . > > I prefer this approach to compiling c++ to JS fro two main reasons: (1) File Size, and (2) Flexibility > > = 1. File Size = > JS code generated by C/C++ => JS tools like Emscripten can be quite large. Too large for reasonable performance on mobile devices. > > Initially I had tried using Emscripten to compile the GuidoEngine code into JS. With some tweaking (taking out dependencies on external libs like Cairo), I was successful in doing this. I was able to make 'JsSystem' class in C++ that acted as a bridge between the C++ scope, and the javascript scope, and was able to emit a stream of Guido graphic commands to the javascript console. > > However, the resulting code was quite large. After minification, it was about 2.2 MB. After minification + gzip (what the browser would actually need to transfer over the wire) it was about 460 KB. N'est-ce pas un peu gros, no? ;) > > But despair not, I think there is hope. > > I think it will be possible to get hand-written JS code down to at least 400KB. > > This estimate is based on the classes that I have ported so far; As un-minified JS files, they are 50% - 75% of the size of their C++ counterparts. The combined size of the GuidoEngine .cpp files in src/ is about 2.3 MB. I think I can get this down to 1 MB. Then minification can reduce this to 400 KB or less. Which should gzip to 100 KB or less. Plus délicieux! > > = 2. Flexibility = > I also prefer re-writing in javascript because it offers more flexibility. > > With the compilation approach, we would need to do these things to make a change: > - 1. Edit the C++ code > - 2. Re-compile the C++ into JS > - 3. Test in JS > > Un peu énervant, eh? > > Whereas with re-written JS, we can test in JS, and also debug in JS. > > Peut-être je suis trop prolix maintenant. > > == The Downside == > The downside of the hand-written approach is that it will take time. Nothing good comes without work. > > I hope I can rally some development efforts around it. > > > > Do your plan to use javascript as is, or a derived typed lang like TypeScript ( http://www.typescriptlang.org/ ) ? > > I plan to use plain javascript, organized as AMD modules. I thought about using TypeScript or CoffeeScript, but I personally find plain JavaScript more readable. Call me old-fashioned I guess. > > > Anyway your project is really interesting and I hope we'll be able to join our efforts. > > Me too! I hope it becomes something that helps all of our projects. You your team have already helped mine with all your work on Guido! > > == Other Hopes == > My hope is that Guido can be helpful for other javascript tools too. I have a friend who is working on in-browser synthesis tools (http://flockingjs.org/ ). He may be interested in a musical encoding system for his project. Guido seems like an excellent candidate. > > I think there are some really exciting possibilities for Guido in the future. And I'm sure you have already thought of many of them! > > > ps: and I wish you a quick thaw :-) > > Merci! Et a vous aussi. Ici c'est plus froid que l'amour que un développeur web a pour IE6 ;) > > -Alex > > -- > --- > Want to learn music? We're building an online musical dojo: > http://musikata.com > http://facebook.com/musikata > http://twitter.com/zen4music > --- > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________ > Guidolib-devel mailing list > Gui...@li... > https://lists.sourceforge.net/lists/listinfo/guidolib-devel |