<div dir="ltr">Hi Sam!<div><br></div><div>First of all, thanks for your time and suggestions.</div><div>Here's my second blogpost <a href="http://tmblr.co/ZLEL4t1HZ7XRT">http://tmblr.co/ZLEL4t1HZ7XRT</a> and as you said, it seems like having a central recognizer process is the way to go.</div>
<div><br></div><div>As for the language model, believe me, it is not as scary as it sounds!</div><div>We plan on providing default models if available, but letting each developer override the language model with a grammar is a huge gain in terms of flexibility and accuracy. </div>
<div><br></div><div>A simple language model is very easy to define, and with good docs (which are on the roadmap) I think developers will be fine.</div><div>Regards,</div><div><br></div><div>Rodrigo</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2014-05-28 7:05 GMT-04:00 Sam Parkinson <span dir="ltr"><<a href="mailto:sam.parkinson3@gmail.com" target="_blank">sam.parkinson3@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi Rodrigo!<br><br><br></div>It is nice to see 'Sugar Listens' getting developed! It sounds really cool.<br><br><br></div>As for the architecture you are suggesting I think design 1 (the central process) would be the best way go.<br>
</div><div>Memory usage is a REALLY important thing on the xo, and a dbus based design will make building a js (or whatever other language) api easier.<br><br><br></div>From what I can gauge, it appears you are trying to have always on voice recognition (please tell me if I'm wrong), which is pretty cool!<br>
</div>Having multiple sphinx instances all listing at the same time would not be very good.<br>Having a centralized one would let you only send events only to the current activity, and maybe default back to the system.<br>
<br><br>Your Blog> IPC message load:<strong> </strong>delay introduced by IPC calls should be considered.<br></div>Doing some benchmarks would be cool, this sounds like a tiny issue to me!<br><br><br>Your Blog> Each Activity can provide its own language model...<br>
</div>That sounds scary!<br></div>I think, as powerful as that would be, it is really important that you resist the temptation to shove really complex stuff onto activity developers and force them to learn about it (sorry for being a hypocritical there).<br>
</div><div>Make sure you have a good default (if that is possible, I don't know anything about language models)<br></div><br><br></div><div>As for the api functions names, IMHO we should use some GTK terminology (like connect instead of listen).<br>
<br><br></div><div>Looks like a great start to an exciting project!<br>Sam.<br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, May 28, 2014 at 9:06 AM, Rodrigo Parra <span dir="ltr"><<a href="mailto:rodpar07@gmail.com" target="_blank">rodpar07@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hello everyone,<div><br></div><div>To sum up last week's activities for my GSoC project I wrote an article in my personal blog. My project is called TamTam Listens and my mentor is tch.</div>
<div><br></div>
<div>If you want to take a look, here's the link: <a href="http://tmblr.co/ZLEL4t1Gv4jqp" target="_blank">http://tmblr.co/ZLEL4t1Gv4jqp</a></div><div><br></div><div>As stated in the article, constructive feedback about the architecture, the API or the article itself is more than welcome.</div>
<div><br></div><div>Best regards,</div><div><br></div><div>Rodrigo Parra</div><div><br></div></div>
<br></div></div>_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>