<div class="gmail_quote">On Fri, Sep 2, 2011 at 9:36 AM, Florian Paul Schmidt <span dir="ltr"><<a href="mailto:mista.tapas@gmx.net">mista.tapas@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
Hmm, i used Functors and Closures in jass for passing commands to the realtime thread and wrote a small article about it.<br></div></blockquote><div><br>Cheers for the link, I've browsed it before I think, consider yourself "blog-famous" :D<br>
<br> Indeed the functor system will work, but I find the syntax quite clumsy, and I don't want the GUI to become non-responsive until the Engine signals the event is done. Reason for this is that there's quite an amount of events going back and forth, and I estimate the GUI will become too laggy to feel right.<br>
<br>While I could do some (nasty) event checking and not in general, only blocking when I know I'm changing the state of an EngineElement that I need a reference to. Again quite nasty IMO. The other problem is that since all communication is OSC, I cannot guarantee that all "controller" or "view" programs (ie OSC senders / receivers) will comply. So I need a "foolproof" plan, where *any* messages can be sent in *any* order, without crashing / hiccups.<br>
<br>Your mention of "poor man's garbage collection" is quite a do-able system, and I like how it automatically abstracts the non-RT actions away from the RT thread. (ie: removing samples from mem etc) Will let you know if I ever get around to doing it... Currently I'm just storing all samples ever used in mem... and praying somebody doesn't load a 2GB .wav file :D<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote"><<a href="http://www.codeproject.com/KB/cpp/fastdelegate2.aspx" target="_blank">http://www.codeproject.com/KB/cpp/fastdelegate2.aspx</a>>  for example.<br>

(I used Don's original "Fastest Possible C++ Delegates" on an embedded<br>
project years ago -- worked great).</blockquote><div><br>Nice article there... seems a clean enough implementation. Perhaps if I decide a on a rewrite of the event handling at some state I'll concider this as an option :)<br>
<br>-Harry<br></div></div></div>