fluid-work IRC Logs-2013-05-16

Owned by Fluid IRC Log Bot
Last updated: May 16, 2013Version comment
10 min read

[10:34:39 CDT(-0500)] <jhung> Hi fluid-everyone. The Adobe Connect room (https://connect.ocad.ca/fluid-work) is down currently so we won't be hosting our daily check-in meeting.

[13:26:47 CDT(-0500)] <thealphanerd> colinclark: hows it going?

[13:26:54 CDT(-0500)] <colinclark> Good, you?

[13:27:13 CDT(-0500)] <thealphanerd> not too bad

[13:27:15 CDT(-0500)] <thealphanerd> just waking up

[13:28:39 CDT(-0500)] <colinclark> I'm about an hour ahead of you (wink)

[13:28:42 CDT(-0500)] <colinclark> Late night last night

[13:28:46 CDT(-0500)] <colinclark> got your pull in, thanks so much

[13:28:52 CDT(-0500)] <colinclark> I'm already hacking in the submodule

[13:29:06 CDT(-0500)] <thealphanerd> word

[13:29:10 CDT(-0500)] <colinclark> Hey, thealphanerd, I was thinking...

[13:29:10 CDT(-0500)] <thealphanerd> I love that workflow (big grin)

[13:29:17 CDT(-0500)] <colinclark> I don't know if you have much in the way of spare time

[13:29:25 CDT(-0500)] <colinclark> but you mentioned that you were interested in hacking on Grunt

[13:29:39 CDT(-0500)] <colinclark> Any chance you want to take a stab at a simple build script for Flocking?

[13:29:51 CDT(-0500)] <colinclark> I think all it really needs to do, to start, is minify and concatenate

[13:29:55 CDT(-0500)] <colinclark> but I don't want to impose--you're probably super busy

[13:33:30 CDT(-0500)] <thealphanerd> I'd love to

[13:33:43 CDT(-0500)] <thealphanerd> when are you thinking about as far as a deadline?

[13:34:45 CDT(-0500)] <colinclark> next Monday (smile)

[13:34:50 CDT(-0500)] <colinclark> Pretty short notice

[13:34:53 CDT(-0500)] <colinclark> I can help out

[13:35:05 CDT(-0500)] <colinclark> I'm digging into the new declarative scheduler at nights here

[13:36:33 CDT(-0500)] <colinclark> my goal is simpler user factors in time for the conference

[13:36:51 CDT(-0500)] <colinclark> a concatenated build makes life a lot easier for developers, since they need only link a single file

[13:36:56 CDT(-0500)] <colinclark> rather than the 10 or so that is currently required

[13:37:09 CDT(-0500)] <colinclark> I'd also like to whip up a synth with AMMM

[13:37:14 CDT(-0500)] <colinclark> which I'll probably do on Sunday

[13:37:35 CDT(-0500)] <colinclark> Because part of my message to SuperCollider users, I think, will be how great UI development on the web can be

[13:39:01 CDT(-0500)] <thealphanerd> ahhh ok

[13:39:07 CDT(-0500)] <thealphanerd> I'm not 100% I can make that deadline

[13:39:11 CDT(-0500)] <thealphanerd> unless I can hack it out this afternoon

[13:39:17 CDT(-0500)] <thealphanerd> I have maker faire all weekend

[13:39:43 CDT(-0500)] <thealphanerd> but let me see if I can make it work

[13:39:48 CDT(-0500)] <thealphanerd> side bar… I forwarded you an email

[13:40:15 CDT(-0500)] <colinclark> cool, thanks for that

[13:40:17 CDT(-0500)] <colinclark> I really want to see his BLIT code

[13:40:32 CDT(-0500)] <colinclark> thealphanerd: It's totally up to you, and no pressure.

[13:40:36 CDT(-0500)] <colinclark> If you get time, go for it.

[13:40:46 CDT(-0500)] <thealphanerd> it might be neat for you to talk with hong chan

[13:40:47 CDT(-0500)] <colinclark> If not, I will try to whip something up on the weekend

[13:40:50 CDT(-0500)] <colinclark> yes, I'd love to

[13:40:56 CDT(-0500)] <thealphanerd> as I know he works at google, and I think he has chris rogers ear

[13:41:12 CDT(-0500)] <thealphanerd> He was asking yesterday if you are planning to come to ccrma at all (tongue)

[13:42:31 CDT(-0500)] <colinclark> I still would really love to come and visit

[13:42:39 CDT(-0500)] <colinclark> next time I'm in the Bay Area, I'll tack on a few extra days

[13:42:51 CDT(-0500)] <colinclark> sgithens is there today, presenting the GPII on Android at Google I/O

[13:43:01 CDT(-0500)] <thealphanerd> sweet!

[13:43:08 CDT(-0500)] <colinclark> And I think yura will be there next week, too

[13:43:36 CDT(-0500)] <thealphanerd> did they have any good give aways at I/O this year (I wanted to call it swag but I didn't… damn pop culture)

[13:44:57 CDT(-0500)] <colinclark> Steve seemed to say no

[13:44:59 CDT(-0500)] <colinclark> nothing too cool

[13:46:11 CDT(-0500)] <thealphanerd> thats too bad

[13:46:23 CDT(-0500)] <thealphanerd> I might be getting a chance to hack on glass a bit this summer

[13:46:30 CDT(-0500)] <colinclark> wow

[13:47:30 CDT(-0500)] <thealphanerd> not for google

[13:47:38 CDT(-0500)] <thealphanerd> but Djz… the company that hired me is getting one

[13:47:51 CDT(-0500)] <thealphanerd> I think they are interested in using it for the live streaming dj stuff they are doing

[13:48:01 CDT(-0500)] <colinclark> interesting

[13:51:32 CDT(-0500)] <thealphanerd> indeed

[13:53:21 CDT(-0500)] <thealphanerd> so quick question

[13:53:35 CDT(-0500)] <thealphanerd> do you think grunt is the best way to move forward for simplicity?

[13:53:44 CDT(-0500)] <thealphanerd> since it relies on node?

[13:54:08 CDT(-0500)] <colinclark> yes

[13:54:17 CDT(-0500)] <colinclark> I think Grunt is probably the way to go for any build-related tasks

[13:54:22 CDT(-0500)] <thealphanerd> word

[13:54:24 CDT(-0500)] <colinclark> yzen has a bit of experience with it now, I believe

[13:54:32 CDT(-0500)] <colinclark> He gave a workshop about it recently

[13:55:32 CDT(-0500)] <yzen> thealphanerd: grunt is pretty awesome

[13:55:40 CDT(-0500)] <thealphanerd> yzen: I definitely agree

[13:55:53 CDT(-0500)] <thealphanerd> I guess I was thinking it seemed much just for concatination and minification

[13:56:01 CDT(-0500)] <thealphanerd> but that is probably just the first step

[13:57:54 CDT(-0500)] <colinclark> I'm fascinated by Hongchan's email, thealphanerd

[13:58:00 CDT(-0500)] <colinclark> I would love to chat with him at some point

[13:58:24 CDT(-0500)] <thealphanerd> specific thoughts?

[13:58:51 CDT(-0500)] <colinclark> thealphanerd: Yep, concat and minify is often just the tip of the iceberg. For example, we might in the future have "build modules" or other kinds of customizations that users can choose from, not unlike in the Infusion build process

[13:58:59 CDT(-0500)] <colinclark> Specific thoughts? Hmm. Yes, the Web Audio API sucks.

[13:59:33 CDT(-0500)] <colinclark> I mean, it's just so deeply flawed, in that they have not solved the meaningful problem, which is how to give web developers the ability to create really performant audio

[13:59:51 CDT(-0500)] <colinclark> Poor Hongchan, throwing out all his own code and being left with nothing but Chris Rogers' mediocre built-ins.

[14:00:11 CDT(-0500)] <colinclark> His position is pretty extreme

[14:00:21 CDT(-0500)] <colinclark> which I admire (smile)

[14:00:38 CDT(-0500)] <thealphanerd> well I guess the problem is that there is no easy way to solve the problem of extensions without having native compiled code

[14:00:49 CDT(-0500)] <colinclark> What's your rationale for that?

[14:01:03 CDT(-0500)] <thealphanerd> Hong Chan was discussing this with me yesterday

[14:01:11 CDT(-0500)] <colinclark> I think it's entirely not the case

[14:01:15 CDT(-0500)] <thealphanerd> does the term ipc mean anything?

[14:01:21 CDT(-0500)] <colinclark> but people don't want to deal with the complexities of the alternative

[14:01:24 CDT(-0500)] <thealphanerd> I'm trying to recall exactly what he was saying

[14:01:30 CDT(-0500)] <colinclark> Interprocess Communication

[14:01:40 CDT(-0500)] <colinclark> My little experiment with asm.js proved something quite noteworthy

[14:01:58 CDT(-0500)] <thealphanerd> so I think the problem becomes the inherent latency with ipc… and that without native compiled code you cannot avoid it

[14:02:07 CDT(-0500)] <colinclark> Which is that modern runtimes produce extremely optimized compiled code from JavaScript

[14:02:10 CDT(-0500)] <thealphanerd> what kind of results did you get with asm… I thought you said they were not great

[14:02:10 CDT(-0500)] <colinclark> thealphanerd: That doesn't make any sense

[14:02:16 CDT(-0500)] <colinclark> I mean, look at CoreAudio

[14:02:38 CDT(-0500)] <colinclark> Apple has exceptionally low latency while audio processing runs in a separate, realtime thread

[14:02:40 CDT(-0500)] <thealphanerd> I wish I could recall exactly how he was discussing it...

[14:02:47 CDT(-0500)] <thealphanerd> I guess that is the thing

[14:02:58 CDT(-0500)] <thealphanerd> unless audio gets its own thread… it will always be an afterthought

[14:02:58 CDT(-0500)] <colinclark> It's this "JavaScript just isn't good enough" attitude that drives me nuts with these Googlers

[14:03:04 CDT(-0500)] <colinclark> Chris Wilson is the pit bull of this mentality

[14:03:21 CDT(-0500)] <colinclark> And Rogers just isn't thoughtful enough to do what needs to be done

[14:03:26 CDT(-0500)] <colinclark> So, here's the thing

[14:03:38 CDT(-0500)] <colinclark> JavaScript DSP code needs to be able to run in its own real-time thread

[14:03:47 CDT(-0500)] <colinclark> Exactly what I was saying to Zicarelli yesterday

[14:04:04 CDT(-0500)] <colinclark> ScriptProcessorNodes need to provide a Web Worker in which your JS code is run

[14:04:11 CDT(-0500)] <colinclark> at that point, we're isolated from the main thread

[14:04:15 CDT(-0500)] <colinclark> that's the first and most substantial problem

[14:04:22 CDT(-0500)] <colinclark> as you saw in Chris Wilson's article

[14:04:34 CDT(-0500)] <thealphanerd> which article was this>

[14:04:34 CDT(-0500)] <thealphanerd> ?

[14:04:39 CDT(-0500)] <colinclark> The scheduling article

[14:04:47 CDT(-0500)] <colinclark> Second problem: give that thread a high priority

[14:04:56 CDT(-0500)] <colinclark> so that it can run uninterrupted

[14:05:18 CDT(-0500)] <colinclark> those two things will go a huge way to making a viable all-DSP solution

[14:05:38 CDT(-0500)] <colinclark> The asm.js experiment proved that, if well-written, JavaScript can get compiled to very efficient code

[14:05:42 CDT(-0500)] <colinclark> just plain old JavaScript, that is

[14:05:54 CDT(-0500)] <colinclark> There's always going to be some latency involved in communication between threads

[14:05:59 CDT(-0500)] <colinclark> but that's the nature of any audio system

[14:06:13 CDT(-0500)] <colinclark> be it CoreAudio or JACK or pulse audio or whatever

[14:06:29 CDT(-0500)] <colinclark> the problem is that Chris Rogers has made this walled garden

[14:06:44 CDT(-0500)] <colinclark> where there is a real-time thread running behind the scenes, completely out of the reach of the web developer

[14:07:00 CDT(-0500)] <colinclark> and then it has to call out to an "unoptimized thread," which is the main JavaScript thread in the browser

[14:07:28 CDT(-0500)] <colinclark> that's the core problem, as far as I can tell

[14:10:33 CDT(-0500)] <thealphanerd> ls what can be done

[14:11:39 CDT(-0500)] <thealphanerd> I have to run for now

[14:11:43 CDT(-0500)] <thealphanerd> lets follow this up soon

[14:11:44 CDT(-0500)] <colinclark> yep

[14:11:49 CDT(-0500)] <colinclark> totally!

[14:12:18 CDT(-0500)] <thealphanerd> I think that there is a lot of momentum building

[14:12:52 CDT(-0500)] <thealphanerd> between gramme and cycling we may actually be able to get some people at google listening

[14:12:58 CDT(-0500)] <thealphanerd> especially if we can convince hong chan

[14:14:07 CDT(-0500)] <thealphanerd> talk soonb

[16:44:46 CDT(-0500)] <thealphanerd> colinclark: sent pull request for flocking

[16:44:48 CDT(-0500)] <thealphanerd> grunt working

[16:45:03 CDT(-0500)] <thealphanerd> concat / minify with uglify / clean

[16:51:09 CDT(-0500)] <colinclark> nice

[16:51:10 CDT(-0500)] <colinclark> thanks!

[16:51:12 CDT(-0500)] <colinclark> that was fast!

[16:51:33 CDT(-0500)] <colinclark> In the time it took me to eat some Fish Tacos, you were rocking the real work

[16:52:32 CDT(-0500)] <colinclark> I think, in terms of web workers, that the secret is that there should only ever be one

[16:53:18 CDT(-0500)] <thealphanerd> indeed

[16:53:22 CDT(-0500)] <thealphanerd> so that needs its own framework

[16:53:31 CDT(-0500)] <colinclark> I don't think it really does

[16:53:40 CDT(-0500)] <colinclark> I mean, above and beyond what a framework today would provide

[16:53:58 CDT(-0500)] <colinclark> maybe I'm missing something

[16:54:07 CDT(-0500)] <colinclark> but I think it would be pretty straightforward

[16:54:14 CDT(-0500)] <colinclark> sample generation tends to be pretty synchronous

[16:54:23 CDT(-0500)] <colinclark> you just want it to be asynchronous with the main thread

[16:57:59 CDT(-0500)] <thealphanerd> but what happens when you make a new node

[16:58:07 CDT(-0500)] <thealphanerd> do you just tuck that in to the same web worker as original?

[16:58:41 CDT(-0500)] <colinclark> I think that would have to be the case, yes

[16:58:44 CDT(-0500)] <thealphanerd> that is where I am thinking some sort of framework for how to get things into the worker

[16:58:55 CDT(-0500)] <colinclark> You could take a look at RoC's MediaStreamProcessor spec

[16:59:01 CDT(-0500)] <colinclark> which included worker-based sample processing

[16:59:11 CDT(-0500)] <colinclark> I think you'd do the usual worker thing, and ship off some code to the "audio worker"

[16:59:20 CDT(-0500)] <colinclark> rather than actually dealing with creating your own workers

[16:59:26 CDT(-0500)] <colinclark> there's a limit in most browsers anyway

[16:59:37 CDT(-0500)] <colinclark> 8 simultaneous Workers or something like that

[16:59:52 CDT(-0500)] <thealphanerd> so one of the things I was thinking with the faust stuff was would it be possible to tuck the "compute" functions into a web worker

[17:00:02 CDT(-0500)] <thealphanerd> and only put in the final generated samples into the script node

[17:00:15 CDT(-0500)] <thealphanerd> but that stage will introduce nasty uneccessary latency

[17:00:18 CDT(-0500)] <colinclark> It's been a while since I've read it, but here's the relevant portion of that spec: https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html#worker-processing

[17:00:38 CDT(-0500)] <colinclark> I think currently it's not really viable to use Workers for audio generation

[17:00:51 CDT(-0500)] <colinclark> because you'll still need to postMessage() your samples back to the main thread

[17:00:54 CDT(-0500)] <colinclark> you want it the other way

[17:01:06 CDT(-0500)] <colinclark> where samples get generated and output in the Worker

[17:01:18 CDT(-0500)] <colinclark> and then you send messages to the worker to do things like change parameters on the unit generator

[17:01:26 CDT(-0500)] <colinclark> which sadly just isn't possible yet

[17:01:44 CDT(-0500)] <thealphanerd> so this is more about where web audio as a whole lives?

[17:03:42 CDT(-0500)] <colinclark> I guess you could say that, yes

[17:04:43 CDT(-0500)] <colinclark> this grunt script looks really great, thealphanerd

[17:04:46 CDT(-0500)] <colinclark> you freaking rule!

[17:04:48 CDT(-0500)] <thealphanerd> (big grin)

[17:04:52 CDT(-0500)] <thealphanerd> it was fairly easy (tongue)

[17:05:02 CDT(-0500)] <thealphanerd> grunt rocks

[17:05:07 CDT(-0500)] <colinclark> that's great

[17:05:24 CDT(-0500)] <thealphanerd> the only thing in there you might want to modify is the version number in the package.json

[17:05:36 CDT(-0500)] <thealphanerd> I also did not test the resulting minified package

[17:05:56 CDT(-0500)] <thealphanerd> you can also add jshint in there too if you would like to have a linter be an automatic part of the build process

[17:07:43 CDT(-0500)] <colinclark> good idea

[17:07:55 CDT(-0500)] <colinclark> and then it'll be great to get some of the unit tests running too

[17:07:57 CDT(-0500)] <thealphanerd> there are also hooks for junit

[17:08:04 CDT(-0500)] <thealphanerd> or is it qunit

[17:08:16 CDT(-0500)] <thealphanerd> po

[17:11:28 CDT(-0500)] <colinclark> qunit

[17:11:39 CDT(-0500)] <colinclark> We left junit behind years ago (smile)

[17:12:31 CDT(-0500)] <thealphanerd> ah

[17:12:43 CDT(-0500)] <thealphanerd> it looks like the qunit stuff is very simple

[17:12:49 CDT(-0500)] <thealphanerd> since you already have the unit tests written

[17:14:30 CDT(-0500)] <colinclark> yep

[17:14:36 CDT(-0500)] <colinclark> There are some that are browser-specific

[17:14:38 CDT(-0500)] <colinclark> but not many

[17:14:45 CDT(-0500)] <colinclark> actually, probably none

[17:14:52 CDT(-0500)] <colinclark> (smile)

[17:15:10 CDT(-0500)] <colinclark> Bosmon2 has done a lot of work to create a new testing framework for Infusion that includes Node.js support

[17:15:16 CDT(-0500)] <colinclark> using, i think, the node-qunit module

[17:15:20 CDT(-0500)] <thealphanerd> dope! I think this is what I have time to get in to today… especially since I don't know much about qunit

[17:15:27 CDT(-0500)] <colinclark> totally

[17:15:30 CDT(-0500)] <thealphanerd> but if I end up procrastinating at all I'll let you know

[17:15:32 CDT(-0500)] <colinclark> this is already tons

[17:15:43 CDT(-0500)] <colinclark> I so wish I could procrastinate on it right now, too (smile)

[17:17:40 CDT(-0500)] <colinclark> Bosmon2: This diagram needs to be, umm...

[17:17:42 CDT(-0500)] <colinclark> well, you know

[17:17:43 CDT(-0500)] <colinclark> http://wiki.gpii.net/index.php/File:CFA_Overview.png

[17:21:01 CDT(-0500)] <thealphanerd> colinclark: gotta run for now

[17:21:02 CDT(-0500)] <thealphanerd> chat soon (big grin)

[17:21:06 CDT(-0500)] <colinclark> cool