fluid-work IRC Logs-2012-11-24
- Fluid IRC Log Bot
[02:10:34 CST(-0600)] <thealphanerd> Bosmon: you around
[02:10:34 CST(-0600)] <thealphanerd> ?
[02:11:45 CST(-0600)] <Bosmon> THER ALPHER NERDD!
[02:11:50 CST(-0600)] <thealphanerd> hehe
[02:11:56 CST(-0600)] <thealphanerd> so I'm thinking about doing a project
[02:11:59 CST(-0600)] <thealphanerd> would love your two cents
[02:12:35 CST(-0600)] <thealphanerd> I want to do generative UI based on a model with infusion
[02:12:57 CST(-0600)] <thealphanerd> specifically generating UI that are OSC controllers
[02:13:39 CST(-0600)] <thealphanerd> do you think I would be better off with canvas or svg?
[02:14:27 CST(-0600)] <Bosmon> canvas of course
[02:14:29 CST(-0600)] <Bosmon> svg is a DEAD DUCK!
[02:14:42 CST(-0600)] <thealphanerd> but I like svg
[02:14:45 CST(-0600)] <thealphanerd> lol
[02:14:47 CST(-0600)] <Bosmon> Well sure
[02:14:55 CST(-0600)] <thealphanerd> it is easier to traverse in the om
[02:15:02 CST(-0600)] <thealphanerd> and d3 is dope sauce
[02:15:08 CST(-0600)] <Bosmon> It has many theoretical and abstract advantages
[02:15:11 CST(-0600)] <thealphanerd> as far as what you can do with data driven visualzation
[02:15:15 CST(-0600)] <Bosmon> It doesn't stop it from being a dead duckk : P
[02:15:18 CST(-0600)] <thealphanerd> just poorly implemented
[02:16:02 CST(-0600)] <Bosmon> Remind me whether dope sauce is something good or bad 
[02:16:11 CST(-0600)] <thealphanerd> it is a good thing
[02:16:16 CST(-0600)] <Bosmon> Ah splendid
[02:16:19 CST(-0600)] <thealphanerd> lol
[02:16:32 CST(-0600)] <thealphanerd> sorry… us hipster coders and our secret language
[02:16:37 CST(-0600)] <thealphanerd> I forgot this wasn't reddit for a second
[02:16:51 CST(-0600)] <thealphanerd> I need to stop talking like I'm 13… I'm almost 30
[02:16:52 CST(-0600)] <thealphanerd> 
[02:16:52 CST(-0600)] <Bosmon> Yeah, svg seems fine
[02:16:59 CST(-0600)] <Bosmon> The trouble is, it is a sociological dead end
[02:17:09 CST(-0600)] <thealphanerd> care to elaborate?
[02:17:10 CST(-0600)] <Bosmon> None of the vendors is going to invest any significant effort into improving it
[02:17:18 CST(-0600)] <thealphanerd> ahh
[02:17:27 CST(-0600)] <thealphanerd> well my primary interest is in responsiveness
[02:17:33 CST(-0600)] <Bosmon> Whereas canvas is increasingly going to benefit from GPU loveliness
[02:17:46 CST(-0600)] <Bosmon> responsiveness, and accessibility, that is : P
[02:17:53 CST(-0600)] <thealphanerd> yup
[02:17:54 CST(-0600)] <Bosmon> Where svg also has some theoretical advantages
[02:18:01 CST(-0600)] <Bosmon> What with having a REAL DOM and all
[02:18:10 CST(-0600)] <thealphanerd> exactly
[02:18:17 CST(-0600)] <thealphanerd> how do you make canvas inclusive?
[02:18:25 CST(-0600)] <Bosmon> You will need to build an EXTRA DOM
[02:18:30 CST(-0600)] <thealphanerd> meta dom
[02:18:31 CST(-0600)] <Bosmon> it seems like pointless work
[02:18:38 CST(-0600)] <Bosmon> But we're just going to have to get expert in this technique
[02:18:42 CST(-0600)] <Bosmon> I don't see any real alternative
[02:18:49 CST(-0600)] <thealphanerd> hmmm
[02:19:05 CST(-0600)] <thealphanerd> I guess the real challange is how to make the process of writing the code intuitive
[02:19:15 CST(-0600)] <thealphanerd> without having to write twice every time to make it inclusive
[02:19:16 CST(-0600)] <Bosmon> Every rendering bug and oddity with SVG will just sit there on the shelf
[02:19:25 CST(-0600)] <Bosmon> And its performance will increasingly start to look totally ridiculous
[02:19:26 CST(-0600)] <thealphanerd> not entirely true
[02:19:32 CST(-0600)] <Bosmon> And by totally ridiculous, I mean, ridiculously bad : P
[02:19:35 CST(-0600)] <thealphanerd> webkit seems to have fixed one of the bugs I found over the summer
[02:19:58 CST(-0600)] <thealphanerd> but there is still weirdness
[02:20:05 CST(-0600)] <Bosmon> Well, that is impressive : P
[02:20:07 CST(-0600)] <thealphanerd> but I think it is dom weirdness…
[02:20:19 CST(-0600)] <thealphanerd> why the fuck can't we have things be vertically responsive
[02:20:23 CST(-0600)] <thealphanerd> grrr
[02:20:24 CST(-0600)] <Bosmon> But you can be sure that the weirdness will receive proportionally little dev attention
[02:20:34 CST(-0600)] <Bosmon> SVG is not "open at the top"
[02:20:39 CST(-0600)] <Bosmon> Whereas WebGL is
[02:20:43 CST(-0600)] <thealphanerd> Bosmon: sounds like I need to learn more c++ and become the savior
[02:21:02 CST(-0600)] <Bosmon> Sure, and get commit access to EVERY browser tree
[02:21:11 CST(-0600)] <thealphanerd> Bosmon: I could be the chosen one
[02:21:18 CST(-0600)] <Bosmon> With a nick like that, I doubt it
[02:21:22 CST(-0600)] <thealphanerd> but I think I have better things to do with my time
[02:21:33 CST(-0600)] <thechosenone>
[02:21:35 CST(-0600)] <Bosmon> THEY CHOSE NONE!
[02:21:59 CST(-0600)] <Bosmon> Anyway, yes, I highly recommend you to investigate how plain canvas apps can be made accessible
[02:21:59 CST(-0600)] <thechosenone> I can't beleive I just got this nick
[02:22:06 CST(-0600)] <Bosmon> Since before long we'll ALL be having to do it
[02:22:13 CST(-0600)] <Bosmon> LOOK TO THE FUTURE
[02:22:28 CST(-0600)] <TheAlphaNerd> indeed
[02:22:32 CST(-0600)] <TheAlphaNerd> I guess that is wise
[02:22:44 CST(-0600)] <TheAlphaNerd> perhaps it is aria that needs to be reimagined
[02:22:50 CST(-0600)] <Bosmon> WebGL and WebCL are the BUSS TO THE FUTURE
[02:23:32 CST(-0600)] <Bosmon> Since in the future, ESSENTIALLY ALL computation will be GPU computation
[02:23:40 CST(-0600)] <TheAlphaNerd> MATRIX
[02:23:44 CST(-0600)] <Bosmon> In much the same way that ESSENTIALLY ALL people will come from India or China : P
[02:23:58 CST(-0600)] <TheAlphaNerd> I don't like what you are insinuating
[02:24:10 CST(-0600)] <TheAlphaNerd> so you are basically saying soon there will be no more svg
[02:24:12 CST(-0600)] <TheAlphaNerd> or white people
[02:24:15 CST(-0600)] <TheAlphaNerd> dat's racist
[02:24:17 CST(-0600)] <TheAlphaNerd>
[02:25:08 CST(-0600)] <Bosmon>
[02:25:14 CST(-0600)] <Bosmon> Merely prophetic : P
[02:25:27 CST(-0600)] <TheAlphaNerd> fair enough
[02:25:37 CST(-0600)] <Bosmon> On which note, I've suggested a few times to colinclark that he investigates the possibilities for GPU audio synthesis
[02:25:43 CST(-0600)] <Bosmon> But so far he hasn't had the time to get round to it
[02:25:44 CST(-0600)] <Bosmon> So...
[02:25:49 CST(-0600)] <Bosmon> YOU MAY BE THE FIRST
[02:25:52 CST(-0600)] <TheAlphaNerd> hehe
[02:25:52 CST(-0600)] <Bosmon> At this UNDISCOVERED FRONTIER!
[02:25:58 CST(-0600)] <TheAlphaNerd> not quite there yet
[02:26:07 CST(-0600)] <Bosmon> Just think HOW MUCH JUNK you could get done in 20ms
[02:26:13 CST(-0600)] <TheAlphaNerd> although I think that some of the DSP stuff could be done with gpu
[02:26:17 CST(-0600)] <TheAlphaNerd> especially all the FFT shit
[02:26:22 CST(-0600)] <Bosmon> yes
[02:27:24 CST(-0600)] <Bosmon> but I'm sure a lot more of the pipelines could go down too
[02:27:29 CST(-0600)] <Bosmon> Shader code can be pretty huge now
[02:29:35 CST(-0600)] <TheAlphaNerd> so I guess I need to do a bit of research now
[02:29:48 CST(-0600)] <TheAlphaNerd> into canvas and responsiveness
[02:31:13 CST(-0600)] <Bosmon> How could it fail to be responsive?
[02:31:21 CST(-0600)] <Bosmon> You can always make sure to draw it at frame rate
[02:31:26 CST(-0600)] <Bosmon> It's what canvas is for : P
[02:31:38 CST(-0600)] <TheAlphaNerd> I guess that is true
[02:31:50 CST(-0600)] <TheAlphaNerd> different approach to what I was taking with svg
[02:31:54 CST(-0600)] <Bosmon> And that will always be the problem with SVG
[02:31:58 CST(-0600)] <TheAlphaNerd> but I guess a framerate could work
[02:32:09 CST(-0600)] <Bosmon> That you could never guarantee that the browser isn't BUSY DOING SOMETHING ELSE
[02:32:11 CST(-0600)] <Bosmon> With its renderloop
[02:32:35 CST(-0600)] <TheAlphaNerd> I never had problems with the way I was rendering svg
[02:32:41 CST(-0600)] <TheAlphaNerd> but I guess I wasn't doing lots of updates
[02:32:58 CST(-0600)] <Bosmon> For example, doing a huge bunch of GC faff with all the DOM nodes underlying your animation : P
[02:33:16 CST(-0600)] <Bosmon> the DOM is actually the biggest performance bottleneck in all rendering, since it usually prevents most kinds of parallelism
[02:33:51 CST(-0600)] <Bosmon> So for a complex and dynamic UI, SVG is never going to be the way to go
[02:34:07 CST(-0600)] <Bosmon> We can keep around a "skeleton shadow DOM" for accessibility purposes
[02:34:11 CST(-0600)] <TheAlphaNerd> how do you tie events to canvas elements?
[02:34:12 CST(-0600)] <Bosmon> But keep out out of the render loop
[02:34:22 CST(-0600)] <Bosmon> By faking it, and doing it all yourself
[02:34:48 CST(-0600)] <Bosmon> But there must be some libraries to start helping out with this stuff now.....
[02:35:56 CST(-0600)] <TheAlphaNerd> blegh
[02:35:59 CST(-0600)] <TheAlphaNerd> that sounds so gross
[02:36:44 CST(-0600)] <Bosmon> Yeah, it will be
[02:36:56 CST(-0600)] <Bosmon> I guess it's less of a clearcut decision than I'm making out
[02:37:03 CST(-0600)] <Bosmon> Mainly because what we have to do sounds so MAD
[02:37:09 CST(-0600)] <Bosmon> But still, the FORCE OF HISTORY is inevitable
[02:37:28 CST(-0600)] <Bosmon> It's the same force of history that drove Fluid to invest in JS in a big way, long before anyone else thought it was sensible
[02:37:35 CST(-0600)] <Bosmon> And I think we are just the same kind of junction point now
[02:37:46 CST(-0600)] <TheAlphaNerd> that is reasonable
[02:37:56 CST(-0600)] <Bosmon> People who don't move themselves to be close to the GPU will be last week's dead dogs
[02:38:10 CST(-0600)] <TheAlphaNerd> but don't you think there is room for both
[02:38:17 CST(-0600)] <TheAlphaNerd> if you are not doing uper intensive visualization
[02:38:25 CST(-0600)] <TheAlphaNerd> if you simple want a button
[02:38:34 CST(-0600)] <TheAlphaNerd> isn't svg more suitable
[02:38:35 CST(-0600)] <TheAlphaNerd> ?
[02:38:56 CST(-0600)] <TheAlphaNerd> although I guess you could aruge <button> + some css
[02:39:25 CST(-0600)] <Bosmon> If you simply want a button, isn't HTML more suitable
[02:39:25 CST(-0600)] <Bosmon> yes
[02:39:25 CST(-0600)] <Bosmon> That is the whole issue
[02:39:25 CST(-0600)] <Bosmon> SVG will face an inevitable SQUEEZE
[02:39:25 CST(-0600)] <TheAlphaNerd> but what if you wanted a responsive and updating grid of buttons
[02:39:29 CST(-0600)] <TheAlphaNerd> that can be of various sizes
[02:39:31 CST(-0600)] <Bosmon> From the increasing capabilities of HTML5 on one side, and the performance of Canvas on the other
[02:39:36 CST(-0600)] <TheAlphaNerd> I guess jquery can handle that with css
[02:41:02 CST(-0600)] <Bosmon> It's nasty, but it's got to happen
[02:41:13 CST(-0600)] <TheAlphaNerd> I just love the idea of making a site
[02:41:17 CST(-0600)] <TheAlphaNerd> that is a giant svg element
[02:41:24 CST(-0600)] <Bosmon> Imagine how we all felt, facing the task of translating thousands of lines of Java into JS in 2007 .....
[02:41:39 CST(-0600)] <Bosmon> It appeared clearly INSANE
[02:41:40 CST(-0600)] <TheAlphaNerd> and yuck ^^^
[02:42:59 CST(-0600)] <Bosmon> But you frequently need to do INSANE things, in order to be likely to be where the puck is in 5 years' time...
[02:44:22 CST(-0600)] <TheAlphaNerd> true
[02:44:33 CST(-0600)] <TheAlphaNerd> I guess though it becomes a real battle
[02:44:42 CST(-0600)] <TheAlphaNerd> of coming up with hack solution vs creating real architecture
[02:44:55 CST(-0600)] <TheAlphaNerd> and it is hard to create something that can roll out by yourself
[02:45:13 CST(-0600)] <TheAlphaNerd> especially when you are making tools based on a deadline
[02:45:15 CST(-0600)] <TheAlphaNerd> can't spend all your time making the tools to make your tools
[02:45:20 CST(-0600)] <TheAlphaNerd> shit gets too meta too quickl
[02:45:58 CST(-0600)] <TheAlphaNerd> and that's what I'm struggling with right now for my project. I could easily make a one off static website for my performance / project
[02:46:12 CST(-0600)] <TheAlphaNerd> but I want to make some sort of platform to generate these static pages via model
[02:46:33 CST(-0600)] <TheAlphaNerd> but if I then need to design some lower level architecture just to enable me to do this… my head wants to explode
[02:47:37 CST(-0600)] <TheAlphaNerd> but I guess that is the nice thing about doing things with IOC and components… I can kinda do both. Write the architecture to generate the models based on some hack that makes the individual components (with svg for now due to simplicity), and then use that to recreate it later in canvas
[02:47:55 CST(-0600)] <TheAlphaNerd> perhaps that is how I will go forward… since i know I can accomplish my goal much quicker with svg
[02:49:13 CST(-0600)] <TheAlphaNerd> but I think you raise some valid points… and that a lot of this needs to be examined as to what technologies are going to be relevent in 5 years… and where the development time should go
[17:19:42 CST(-0600)] <thealphanerd> colinclark: you there?
[17:19:52 CST(-0600)] <colinclark> at least vaguely, yes
[17:19:54 CST(-0600)] <colinclark> how's it going?
[17:19:59 CST(-0600)] <thealphanerd> not that bad at all
[17:20:29 CST(-0600)] <thealphanerd> thinking about a few things right now
[17:20:34 CST(-0600)] <thealphanerd> wanted to bounce something off of you
[17:20:42 CST(-0600)] <thealphanerd> thinking abotu trying to do some data vis of audio signals
[17:20:50 CST(-0600)] <thealphanerd> in browser… most likely with d3
[17:20:52 CST(-0600)] <colinclark> cool
[17:21:12 CST(-0600)] <thealphanerd> was thinking about how to go about doing it… and was thinking about doing some stuff with hann windows and the fft
[17:22:09 CST(-0600)] <thealphanerd> so I'm looking at some different libraries.. and was wondering if you had played with any of them / had any opinions
[17:22:17 CST(-0600)] <thealphanerd> https://github.com/jussi-kalliokoski/audiolib.js
[17:22:18 CST(-0600)] <thealphanerd> https://github.com/corbanbrook/dsp.js
[17:22:22 CST(-0600)] <thealphanerd> https://github.com/JensNockert/fft.js
[17:22:41 CST(-0600)] <colinclark> Yes, I know them all
[17:22:54 CST(-0600)] <colinclark> I'd recommend avoiding Corban Brooks' library
[17:23:20 CST(-0600)] <colinclark> It hasn't been maintained in a while and it struck me that, while he was the first to do all of this, his code was a bit more cursory
[17:23:29 CST(-0600)] <colinclark> one gets the sense he wrote it quickly
[17:23:45 CST(-0600)] <colinclark> I figure Jens and Jussi's implementations are probably the same, since they work together
[17:24:00 CST(-0600)] <colinclark> They're decent coders, and can write reasonably fast code
[17:24:29 CST(-0600)] <colinclark> Yeah, Jussi's FFT algorithm is Jens's: https://github.com/jussi-kalliokoski/audiolib.js/blob/master/src/processors/fft.js
[17:24:49 CST(-0600)] <thealphanerd> I was just about to say
[17:24:49 CST(-0600)] <colinclark> I was actually planning to use this one within Flocking...
[17:24:57 CST(-0600)] <colinclark> http://people.opera.com/mage/dspapi/dspapi.js
[17:25:15 CST(-0600)] <colinclark> It was proposed to the W3C Audio Working Group as a potential standard
[17:25:26 CST(-0600)] <thealphanerd> interesting
[17:25:29 CST(-0600)] <colinclark> to fill in the gaps that the Web Audio API tends to have, due to its very anti-JavaScript stance
[17:25:43 CST(-0600)] <thealphanerd> web audio api is anti js?
[17:26:00 CST(-0600)] <colinclark> Well, they really haven't put much thought into how you'd extend the system from JavaSCript
[17:26:13 CST(-0600)] <colinclark> Chris Rogers has this insane notion that his standard is "good enough"
[17:26:20 CST(-0600)] <colinclark> Which is fine--it is quite a good API
[17:26:31 CST(-0600)] <colinclark> but inevitably people will want to extend the world with their own modules
[17:26:44 CST(-0600)] <colinclark> and he really doesn't have a terribly good story about how JavaScript developers can do this in a "first-class" way
[17:27:13 CST(-0600)] <thealphanerd> Chris Rogers wrote a bunch of the web audio a[pi?
[17:27:19 CST(-0600)] <thealphanerd> (sorry need some gaps filled)
[17:27:20 CST(-0600)] <colinclark> He wrote the whole thing
[17:27:23 CST(-0600)] <thealphanerd> oh snap
[17:27:24 CST(-0600)] <thealphanerd>
[17:27:30 CST(-0600)] <colinclark> I think I told you this whole story, months ago, but it was very early on
[17:27:54 CST(-0600)] <colinclark> Google was incredibly shady in the W3C Audio Working Group
[17:28:09 CST(-0600)] <colinclark> essentially ramming through their competing proposal with the argument of "significant industry adoption"
[17:28:25 CST(-0600)] <colinclark> They were heavily evangelizing it to developers, very early on
[17:28:38 CST(-0600)] <colinclark> And paying people to develop against it, like Angry Birds for Chrome
[17:28:59 CST(-0600)] <colinclark> So, they stacked the committee with pro-Web Audio API people
[17:29:25 CST(-0600)] <colinclark> Convinced them that it should be the agreed-upon standard due to this "industry adoption"
[17:29:31 CST(-0600)] <colinclark> which they essentially manufactured
[17:29:34 CST(-0600)] <thealphanerd> and the W3C audio working group are the people coming up with the standard?
[17:29:40 CST(-0600)] <colinclark> yes
[17:29:53 CST(-0600)] <colinclark> and then, after the committee agreed to it, they've started to push back quite heavily against any changes
[17:30:03 CST(-0600)] <colinclark> arguing that they don't want to "break existing implementations"
[17:30:13 CST(-0600)] <thealphanerd> and Chris rogers is at google?
[17:30:30 CST(-0600)] <colinclark> It's completely insane--anyone who adopts a vendor-prefixed API is going to be aware that change will happen
[17:30:36 CST(-0600)] <colinclark> Yes, Chris Rogers works for Google
[17:30:46 CST(-0600)] <colinclark> he used to be at IRCAM, writing apps like AudioSculpt
[17:30:53 CST(-0600)] <colinclark> He's a very experienced engineer
[17:31:00 CST(-0600)] <colinclark> And he's put together a reasonably sensible API
[17:31:07 CST(-0600)] <colinclark> It's just not a very "web-like" API
[17:31:18 CST(-0600)] <colinclark> So, compare it to something like WebGL...
[17:31:34 CST(-0600)] <colinclark> In WebGL, even if JavaScript isn't yet fast enough to do super-fast matrix math, etc...
[17:32:07 CST(-0600)] <colinclark> A JavaScript developer isn't forced to either accept 1) poor performance or 2) being restricted to the native, canned processors
[17:32:23 CST(-0600)] <colinclark> they can write their own shaders and have them run at full speed on the GPU
[17:32:37 CST(-0600)] <colinclark> that's an example of an API that puts web developers on the same footing as browser developers
[17:32:52 CST(-0600)] <colinclark> web developers can innovate, add new features, etc. without having to pay a performance hit
[17:33:09 CST(-0600)] <colinclark> Chris Rogers just hasn't been willing to confront something similar for web audio
[17:33:37 CST(-0600)] <colinclark> As a result, there are various APIs that a "ScriptProcessorNode" can't actually implement
[17:33:52 CST(-0600)] <colinclark> meaning, if you write your own Node in JavaScript, you're going to be a second-class citizen to some extent
[17:34:12 CST(-0600)] <colinclark> Not to mention that he still hasn't added support for processing audio in a Web Worker, which is the first path towards more stable audio generation in JavaScript
[17:34:17 CST(-0600)] <thealphanerd> what does "being a second class citizen" entail?
[17:34:19 CST(-0600)] <colinclark> He has promised to do so, however, and that's a good thing
[17:34:28 CST(-0600)] <colinclark> Well, in my mind, it entails a few things:
[17:34:35 CST(-0600)] <colinclark> 1. A performance penalty
[17:35:34 CST(-0600)] <colinclark> 2. The inability to implement a) a replacement to one of the built in Nodes b) to fully augment a built-in Node or c) create a new Node that conforms to the full interface that the built-in Nodes provide
[17:36:26 CST(-0600)] <thealphanerd> now playing devils advocate
[17:36:36 CST(-0600)] <thealphanerd> what would his argument be for this kind of architecture?
[17:36:52 CST(-0600)] <colinclark> His arguments are unclear and poorly thought out, best as I can tell
[17:37:19 CST(-0600)] <colinclark> He and his evangelist buddy seem to just argue opportunistically; i.e. they argue against specific points rather than FOR a general apporach
[17:37:29 CST(-0600)] <colinclark> Mostly his argument is "this is good enough for now"
[17:37:38 CST(-0600)] <colinclark> But keep in mind that often changing a W3C spec takes years
[17:38:07 CST(-0600)] <colinclark> His argument FOR his architecture is a very sound one...
[17:38:17 CST(-0600)] <colinclark> which is that real-time audio code is very, very performance sensitive
[17:38:35 CST(-0600)] <colinclark> and in particular, it's sensitive to garbage and thread-priority at the kernel level
[17:38:58 CST(-0600)] <colinclark> There's a great article from Ross Bencina about all these issues
[17:38:58 CST(-0600)] <colinclark> I'll have to dig it up
[17:39:07 CST(-0600)] <colinclark> anyway, currently JavaScript garbage collectors aren't super hot
[17:39:20 CST(-0600)] <colinclark> which means they tend to pause code execution for unacceptably long periods of time
[17:39:33 CST(-0600)] <colinclark> SuperCollider, as an example, has a very specialized real-time garbage collector
[17:39:53 CST(-0600)] <thealphanerd> would faust compiling to V8 maybe solve some of these problems
[17:39:54 CST(-0600)] <colinclark> Most JS engine developers seem to have plans for much better garbage collectors, so that strikes me as at least partially a short-term issue
[17:40:01 CST(-0600)] <colinclark> no, i don't think so
[17:40:03 CST(-0600)] <thealphanerd> where you can do your dsp with compiled faust and use js to tie everything together?
[17:40:17 CST(-0600)] <colinclark> Well, what does that mean "compiled faust?"
[17:40:17 CST(-0600)] <thealphanerd> program ugens in faust for exampel
[17:40:28 CST(-0600)] <colinclark> I mean, if Faust generates C code, then it's still C code
[17:40:35 CST(-0600)] <colinclark> which means users can't access it in their browser
[17:40:42 CST(-0600)] <thealphanerd> faust can generate a number of different code
[17:40:44 CST(-0600)] <colinclark> and otherwise, they're generating JS code (which I believe they were planning)
[17:40:49 CST(-0600)] <thealphanerd> but Julius was saying it will compile faust => v8
[17:40:52 CST(-0600)] <thealphanerd> directly into v8
[17:41:01 CST(-0600)] <colinclark> but what does that actually mean?
[17:41:11 CST(-0600)] <colinclark> If it's JavaScript code, it's still subject to the limitations of V8's garbage collector
[17:41:13 CST(-0600)] <thealphanerd> Ithought it was like v8 byte code or sumthing
[17:41:18 CST(-0600)] <colinclark> If it's C code, it can't run on the web
[17:42:08 CST(-0600)] <thealphanerd> yeah I need to dig up some of the papers
[17:42:24 CST(-0600)] <thealphanerd> from how julius was talking it didn't sound like it was compiling to js
[17:42:35 CST(-0600)] <thealphanerd> but I don't know if he is super familliar with the architecture of what they are planning
[17:42:39 CST(-0600)] <thealphanerd> but ok… past this side bar
[17:42:57 CST(-0600)] <thealphanerd> he wants to keep a strict environment due to the limitations of the js language?
[17:43:12 CST(-0600)] <colinclark> That's roughly his argument, yes.
[17:43:46 CST(-0600)] <thealphanerd> but I guess the rebuttle would be… but shouldn't the developer get to decide about performnce
[17:43:50 CST(-0600)] <colinclark> We know, thought, that JS is consistently getting faster, and faster at a faster rate, than any other dynamic language, well, ever.
[17:44:13 CST(-0600)] <thealphanerd> and is this primarily due to v8
[17:44:13 CST(-0600)] <thealphanerd> "?
[17:44:43 CST(-0600)] <colinclark> Well, it's due to most of the current JS engines
[17:44:54 CST(-0600)] <colinclark> V8, *Monkey, etc.
[17:44:54 CST(-0600)] <thealphanerd> what other engines are there again?
[17:45:02 CST(-0600)] <colinclark> Mozilla's is called… well...
[17:45:08 CST(-0600)] <colinclark> I can't remember what it's actually called
[17:45:13 CST(-0600)] <colinclark> It used to be called SpiderMonkey
[17:45:21 CST(-0600)] <colinclark> They have a series of names as they add major new features
[17:45:24 CST(-0600)] <colinclark> there was JagerMonkey
[17:45:26 CST(-0600)] <colinclark> IonMonkey
[17:45:33 CST(-0600)] <colinclark> I can't remember which Monkey we currently have
[17:45:47 CST(-0600)] <colinclark> Safari's used to be called SquirrelFish Extreme
[17:45:55 CST(-0600)] <colinclark> but I have no idea what it is called these days
[17:45:59 CST(-0600)] <thealphanerd> seems to be spider monkey
[17:46:10 CST(-0600)] <colinclark> Basically, ever vendor has their own JS engine
[17:46:25 CST(-0600)] <thealphanerd> what does node use?
[17:46:25 CST(-0600)] <colinclark> Despite Google and Apple sharing WebKit, they don't share the underlying JS engine
[17:46:28 CST(-0600)] <colinclark> V8
[17:47:01 CST(-0600)] <thealphanerd> and each engine implements the w3c standard?
[17:47:11 CST(-0600)] <colinclark> The ECMA standard, yes
[17:47:18 CST(-0600)] <colinclark> JavaScript has never been part of the W3C
[17:47:37 CST(-0600)] <thealphanerd> ECMA
[17:47:40 CST(-0600)] <thealphanerd> kk
[17:47:46 CST(-0600)] <thealphanerd> that's where crockford is involved correct?
[17:47:49 CST(-0600)] <colinclark> Looks like IonMonkey will be enabled in Firefox 18: https://wiki.mozilla.org/Platform/Features/IonMonkey
[17:47:55 CST(-0600)] <colinclark> Yep
[17:48:12 CST(-0600)] <colinclark> Brendan Eich, Crockford, Allen Wirfs-Brock, etc.
[17:48:35 CST(-0600)] <thealphanerd> I just got firefox 17
[17:48:42 CST(-0600)] <thealphanerd> checked to see what version I was
[17:48:58 CST(-0600)] <thealphanerd> so those guys come up with the ECMA script standards
[17:49:04 CST(-0600)] <thealphanerd> and each vendor implements it in their interpreter?
[17:50:14 CST(-0600)] <thealphanerd> btw thanks for the lesson 
[17:52:00 CST(-0600)] <colinclark> yes, that's right
[17:52:29 CST(-0600)] <colinclark> So, in terms of your original question, one of the advantages of using Marcus Geelnard's DSP API for Fast Fourier Transforms is that you might, in the future, find that it's natively implemented
[17:52:36 CST(-0600)] <colinclark> with fancy SMD optimizations and the like
[17:53:34 CST(-0600)] <thealphanerd> SMD?
[17:54:08 CST(-0600)] <colinclark> maybe I've got the acronym wrong
[17:54:21 CST(-0600)] <colinclark> http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions
[17:54:23 CST(-0600)] <colinclark> SIMD
[17:54:47 CST(-0600)] <thealphanerd> so are you looking at implementing fft in flocking with Marcus' code?
[17:54:50 CST(-0600)] <colinclark> most chips have some kind of vector processing optimizations in them now
[17:55:08 CST(-0600)] <colinclark> thealphanerd: Yeah, I've got a branch now that implements the Math and the Filter features from Marcus' polyfill
[17:55:13 CST(-0600)] <colinclark> I figure the FFT is probably next
[17:55:28 CST(-0600)] <thealphanerd> just taking a peak right now at your code
[17:55:49 CST(-0600)] <thealphanerd> so is there any stuff currently in flocking that this would deprecate / replace?
[18:02:00 CST(-0600)] <colinclark> the DSP API?
[18:02:17 CST(-0600)] <colinclark> It certainly saved me a lot of coding in terms of writing my own Filters
[18:02:31 CST(-0600)] <colinclark> he's got a nice, if not 100% super fast Filter API that can handle any order of complexity
[18:03:19 CST(-0600)] <colinclark> You can see how few lines of code it took, because I was using the DSP API: https://github.com/colinbdclark/Flocking/blob/dspapi/flocking/flocking-ugens.js#L1637-L1651
[18:03:41 CST(-0600)] <colinclark> Once you're a filter expert you can advise me on better coefficients to use
[18:04:11 CST(-0600)] <thealphanerd> we are starting the filter stuff right now
[18:04:12 CST(-0600)] <colinclark> but so far the Butterworth coefficients and Robert Bristow-Johnston's cookbook seem pretty good
[18:04:18 CST(-0600)] <thealphanerd> although I'm still getting pretty lost
[18:04:20 CST(-0600)] <colinclark> I'd love to add a nice 303-esque filter
[18:04:28 CST(-0600)] <colinclark> yeah, it's pretty snarly stuff
[18:05:10 CST(-0600)] <thealphanerd> the next two quarters I'll be doing classes on modelling
[18:05:23 CST(-0600)] <thealphanerd> and hopefully that will give me enough to start doing some cooler stuff this summer
[18:05:29 CST(-0600)] <colinclark> yeah, that sounds awesome
[18:06:24 CST(-0600)] <colinclark> Mayank's granulator is coming along really nicely
[18:06:30 CST(-0600)] <colinclark> it's not quite working yet, but it's really close
[18:06:34 CST(-0600)] <thealphanerd> does he have his own fork now?
[18:06:37 CST(-0600)] <colinclark> I can't wait to make some music with it
[18:06:38 CST(-0600)] <colinclark> He doesn't yet, no
[18:06:41 CST(-0600)] <colinclark> I suggested he should
[18:06:46 CST(-0600)] <colinclark> I wonder if he needs a bit of a Github primer
[18:06:47 CST(-0600)] <colinclark> ?
[18:06:48 CST(-0600)] <thealphanerd> I don't know if he's used git before
[18:06:53 CST(-0600)] <thealphanerd> I can help him with that
[18:06:57 CST(-0600)] <colinclark> He seems to have an account
[18:07:05 CST(-0600)] <colinclark> If he's up for it, and you are, that would be very cool
[18:07:26 CST(-0600)] <colinclark> I optimized his code by a factor of 10x this morning
[18:07:38 CST(-0600)] <colinclark> but I haven't pushed the change up to Github because I figured he might want to do it himself
[18:08:02 CST(-0600)] <colinclark> function calls still ain't cheap in JavaScript
[18:08:03 CST(-0600)] <thealphanerd> should I tell him?
[18:08:06 CST(-0600)] <colinclark> but I guess they aren't in C, either
[18:08:08 CST(-0600)] <thealphanerd> we were maybe going to hang tonight
[18:08:09 CST(-0600)] <colinclark> tell him?
[18:08:13 CST(-0600)] <colinclark> that's awesome
[18:08:19 CST(-0600)] <colinclark> that I made his code faster? I told him in an email today
[18:08:23 CST(-0600)] <colinclark> gave him lots of suggestions, etc.
[18:08:23 CST(-0600)] <thealphanerd> ahhh ok
[18:08:36 CST(-0600)] <colinclark> I told him I was happy to share the optimizations
[18:08:38 CST(-0600)] <thealphanerd> I'm glad he decided to work on flocking
[18:08:48 CST(-0600)] <colinclark> but that I didn't want to take the fun away if he'd rather experiment with it himself
[18:08:55 CST(-0600)] <thealphanerd> makes sense
[18:09:15 CST(-0600)] <thealphanerd> so is the master branch of flocking working on android now?
[18:09:35 CST(-0600)] <colinclark> Nope, you'll still need to use the ff-output branch
[18:09:41 CST(-0600)] <thealphanerd> word
[18:09:45 CST(-0600)] <thealphanerd> and what about polyphony?
[18:09:54 CST(-0600)] <colinclark> I hate to leave it in a branch for so long, but I just want to make sure it's really well tested
[18:10:00 CST(-0600)] <colinclark> Polyphony has been in for a while now
[18:10:09 CST(-0600)] <colinclark> I think
[18:10:10 CST(-0600)] <colinclark> wait
[18:10:59 CST(-0600)] <colinclark> okay, i'm wrong
[18:11:00 CST(-0600)] <colinclark> I suck
[18:11:06 CST(-0600)] <colinclark> I've been holding it out for more unit tests
[18:11:08 CST(-0600)] <colinclark> many of which I wrote
[18:11:23 CST(-0600)] <thealphanerd> lol
[18:11:37 CST(-0600)] <thealphanerd> I might have some time between semesters to help out a bit with that stuffs
[18:12:32 CST(-0600)] <colinclark> cool
[18:12:34 CST(-0600)] <colinclark> i'd love the help
[18:12:42 CST(-0600)] <colinclark> I'm looking forward to getting back to it over the holidays too
[18:12:58 CST(-0600)] <colinclark> First up, it sounds like, I'll need to merge some branches back together
[18:13:00 CST(-0600)] <thealphanerd> well I finish around the 14th
[18:13:03 CST(-0600)] <thealphanerd> I can't legally work
[18:13:17 CST(-0600)] <colinclark> so you've got some free time
[18:13:21 CST(-0600)] <thealphanerd> and the only other thing on my plate is going to be learning some c++ to prep for courses I'm taking next quarter
[18:13:26 CST(-0600)] <colinclark> nice
[18:13:31 CST(-0600)] <colinclark> C++ is a crazy language
[18:13:46 CST(-0600)] <colinclark> a good skill to learn, but don't let it rot your brain 
[18:14:10 CST(-0600)] <colinclark> anyway, I should run
[18:14:42 CST(-0600)] <thealphanerd> no prob
[18:14:45 CST(-0600)] <thealphanerd> good talk
[18:14:45 CST(-0600)] <colinclark> I have 100 pages of Baudrillard to read tonight
[18:14:50 CST(-0600)] <colinclark> yeah, always nice to chat
[18:14:52 CST(-0600)] <thealphanerd> ohhh quickly
[18:14:54 CST(-0600)] <thealphanerd> before you run
[18:14:55 CST(-0600)] <colinclark> let me know if you do any visualization stuff
[18:14:57 CST(-0600)] <colinclark> yep
[18:15:20 CST(-0600)] <thealphanerd> http://www.amazon.com/Counterculture-Cyberculture-Stewart-Network-Utopianism/dp/0226817423
[18:15:26 CST(-0600)] <thealphanerd> and
[18:15:40 CST(-0600)] <thealphanerd> http://www.amazon.com/You-Are-Not-Gadget-Manifesto/dp/0307389979/ref=sr_1_1?s=books&ie=UTF8&qid=1353802532&sr=1-1&keywords=you+are+not+a+gadget+a+manifesto
[18:15:56 CST(-0600)] <thealphanerd> two books on my shelf right now
[18:16:22 CST(-0600)] <colinclark> Ah, yes. Jeron Lanier
[18:17:41 CST(-0600)] <thealphanerd> Paul Demarinis suggested CounterCulture to cyberculture
[18:17:51 CST(-0600)] <thealphanerd> the Lanier one was from a reading David had me do last year
[18:21:08 CST(-0600)] <colinclark> Say hi to Mayank for me if you see him tonight
[18:21:18 CST(-0600)] <colinclark> I'm really impressed with his progress
[18:21:35 CST(-0600)] <thealphanerd> I will extend the message D:
[18:21:38 CST(-0600)] <thealphanerd> that was to be a
[18:21:48 CST(-0600)] <colinclark>
[18:21:49 CST(-0600)] <thealphanerd> be well, and again thanks for the lesson
[18:22:08 CST(-0600)] <colinclark> You should get this Schmickler album sometime if you're in the mood for some crazy computer music: http://editionsmego.com/release/eMEGO+113
[18:22:26 CST(-0600)] <colinclark> It's curiously reflexive of computer music history, too
[18:22:35 CST(-0600)] <colinclark> which might resonate with you as you learn all the techniques