...
[13:18:24 CDT(-0500)] * Topic is 'This channel is logged – for details see: http://wiki.fluidproject.org/display/fluid/IRC+Channel' ' set by jessm on 07:30:00 CST(-0600)
[13:37:00 CDT(-0500)] * Topic is 'This channel is logged – for details see: http://wiki.fluidproject.org/display/fluid/IRC+Channel' ' set by jessm on 07:30:00 CST(-0600)
...
[21:34:58 CDT(-0500)] <colinclark> in your Current_Faust_Compilation demo, you've got a file:// url, which means I couldn't try it out
...
[22:24:53 CDT(-0500)] <thealphanerd> I switched the line to "Integer Arithmatic"
[22:25:40 CDT(-0500)] <colinclark> So that particular Faust .dsp file is just written for an environment where this the default behaviour… where it assumes that when an integer gets larger than 2147483647 or whatever, it'll wrap back down again
[22:26:02 CDT(-0500)] <thealphanerd> ahhhhh
[22:26:38 CDT(-0500)] <colinclark> http://en.wikipedia.org/wiki/Integer_overflow
[22:26:40 CDT(-0500)] <thealphanerd> did you manage to get integer arithmatic working with asm?
[22:28:20 CDT(-0500)] <colinclark> Presumably one has to trust the VM 
[22:28:46 CDT(-0500)] <colinclark> but I have no idea what kind of overflow behaviour you get--again, presumably whatever the underlying architecture does
[22:30:20 CDT(-0500)] <colinclark> I was curious about this statement, "Unfortunately some of the semantics of C++ do not translate perfectly to JavaScript, the unfortunate side effect of moving from an Object Oriented language to a Functional Language."
[22:31:18 CDT(-0500)] <thealphanerd> colinclark: is asm a vm though by itself???
[22:31:29 CDT(-0500)] <thealphanerd> colinclark: emscripten by default doesn't automate wrappers
[22:31:38 CDT(-0500)] <thealphanerd> it is easy to break out a function
[22:31:46 CDT(-0500)] <thealphanerd> but a class or a struct is a bit more difficult
[22:31:53 CDT(-0500)] <colinclark> well, yes
[22:32:00 CDT(-0500)] <colinclark> it's pretty well just C
[22:32:25 CDT(-0500)] <colinclark> One likely wouldn't refer to C as a "Functional Language" either
[22:32:47 CDT(-0500)] <colinclark> It seems to me less an issue of semantics not translating...
[22:32:51 CDT(-0500)] <thealphanerd> definitely not
[22:33:13 CDT(-0500)] <colinclark> though there are plenty of C++ semantics that wouldn't have equivalents in JavaScript, but that's sort of a separate issue
[22:33:35 CDT(-0500)] <colinclark> and more a question of what kind of "bridge" or language bindings are available between C++ and JavaScript in Emscripten
[22:33:46 CDT(-0500)] <colinclark> and your experience and sample code makes it clear that the answer is currently "none"
[22:34:00 CDT(-0500)] <thealphanerd> there are some projects
[22:34:12 CDT(-0500)] <thealphanerd> in forks of emscripten
[22:34:43 CDT(-0500)] <colinclark> Yeah, I saw reference to something coming
[22:34:54 CDT(-0500)] <thealphanerd> brb
[22:35:06 CDT(-0500)] <colinclark> I guess Emscripten is still very raw
[22:42:57 CDT(-0500)] <thealphanerd> and back
[22:43:13 CDT(-0500)] <thealphanerd> colinclark: I think that I need to go through and look at the way in which some of the larger projects using emscripten is done
[22:43:26 CDT(-0500)] <colinclark> yeah, it'll be interesting to see what they do
[22:44:05 CDT(-0500)] <colinclark> The other thing I wondered about is why you didn't mention the question of how much of a speed benefit we can expect with asm.js, based on the architecture of Web Audio, etc.
[22:44:17 CDT(-0500)] <colinclark> I guess we haven't had much of a chance to talk about it, what with our travel schedules
[22:44:38 CDT(-0500)] <colinclark> but I'm increasingly doubtful that asm.js offers terribly much benefit
[22:44:52 CDT(-0500)] <colinclark> but I suppose we should suffer through trying to port a few more examples to see
[22:45:21 CDT(-0500)] <colinclark> I mean, garbage is probably our first enemy
[22:45:33 CDT(-0500)] <colinclark> and I've written all of Flocking's unit generators to essentially be garbage-free
[22:45:56 CDT(-0500)] <colinclark> at least until you go swapping one unit generator for another or other much more esoteric things
[22:46:07 CDT(-0500)] <colinclark> my impression is that the VMs are really good at optimizing hot loops
[22:46:13 CDT(-0500)] <colinclark> which is what most unit generators tend to be
[22:46:28 CDT(-0500)] <colinclark> Types are totally stable
[22:46:36 CDT(-0500)] <thealphanerd> oh yeah
[22:46:53 CDT(-0500)] <colinclark> so an engine like V8 is likely going to compile a UGen to the point where it's pretty fast to begin with
[22:46:54 CDT(-0500)] <thealphanerd> Hongchan is maybe interested in using flocking to link together his waax modules
[22:47:03 CDT(-0500)] <colinclark> ah, nice
[22:47:05 CDT(-0500)] <colinclark> why is that?
[22:47:11 CDT(-0500)] <thealphanerd> becuase I was talking about it
[22:47:28 CDT(-0500)] <thealphanerd> have may have just been polite about it
[22:47:34 CDT(-0500)] <colinclark>
[22:47:51 CDT(-0500)] <thealphanerd> brb again
[22:47:53 CDT(-0500)] <thealphanerd> sorry
[22:47:58 CDT(-0500)] <thealphanerd> so much to tlak about though 
[22:52:32 CDT(-0500)] <colinclark>
[22:52:35 CDT(-0500)] <colinclark> totally