fluid-work IRC Logs-2012-11-02

Owned by Fluid IRC Log Bot
Last updated: Nov 02, 2012Version comment
10 min read

[08:16:48 CDT(-0500)] <jhung> cindyli and justin_o, do you guys have time to chat on skype?

[08:17:00 CDT(-0500)] <Justin_o> jhung: sure

[08:17:04 CDT(-0500)] <cindyli> sure, jhung

[10:03:07 CDT(-0500)] <cindyli> jhung: with capture UI, if the user started with one camera, the server returns "ready for conventional capture". If after a few captures, the user added in another matched camera and refreshed the page, what camera status do you think the server should return? "ready for conventional" or "for stereo"? Furthermore, dose it matter with the server returned status code at this point? as the UI will show the last captured image anyway.

[10:20:52 CDT(-0500)] <jhung> cindyli: let me think about it.

[10:21:31 CDT(-0500)] <cindyli> sure

[10:21:33 CDT(-0500)] <jhung> cindyli: we no longer make a distinction between conventional and stereo.

[10:21:52 CDT(-0500)] <jhung> so if the user starts with 1 camera and adds another, it should just start capturing with both cameras.

[10:22:32 CDT(-0500)] <cindyli> i understand, jhung, but on the initial page load we still need to specify whether the cameras are capable for stereo captures or not

[10:22:53 CDT(-0500)] <jhung> yes. So if matched cameras, then we report that stereo is available.

[10:24:34 CDT(-0500)] <cindyli> yes, jhung, so, in the case i mentioned above, what status should the server report back when the camera status is changed from conventional to stereo?

[10:26:14 CDT(-0500)] <jhung> It should just say that the cameras are matched.

[10:26:35 CDT(-0500)] <jhung> The UI will then report a status message to user saying that stereo is available.

[10:26:45 CDT(-0500)] <cindyli> ok, i see. thanks, jhung

[10:27:01 CDT(-0500)] <jhung> np

[10:29:37 CDT(-0500)] <cindyli> Justin_o: the server change to distinguish conventional and stereo capability is done and pushed up to my branch. I'm starting the UI change

[10:33:23 CDT(-0500)] <jessm> i'm bashing colin's head on the RFP – we're missing standup because we're on a roll, but i'm so hungry we're going to have to stop eventually

[11:27:36 CDT(-0500)] <jhung> cindyli, justin_o: I'm heading offline for the afternoon. I'll be back this evening. Leave me email messages if you need anything.

[13:05:18 CDT(-0500)] <michelled> colinclark: can I bounce something off you?

[13:05:24 CDT(-0500)] <colinclark> sure

[13:06:25 CDT(-0500)] <michelled> it turns out that in FF the request full screen function is different for different element types.

[13:06:42 CDT(-0500)] <michelled> currently in the video player, we use a video element to get the function we are going to call: https://github.com/fluid-project/videoPlayer/blob/master/js/VideoPlayer.js#L42

[13:06:58 CDT(-0500)] <colinclark> yes

[13:07:00 CDT(-0500)] <michelled> I could change this to using a div, but that doesn't feel DOM agnostic

[13:07:14 CDT(-0500)] <colinclark> I vaguely remember chatting once with alexn about this

[13:07:24 CDT(-0500)] <michelled> do you agree? should I actually store the name instead of the function?

[13:07:40 CDT(-0500)] <colinclark> If I remember, requestFullScreen() is actually a method on any DOM element

[13:08:04 CDT(-0500)] <colinclark> Here's the thing….

[13:08:15 CDT(-0500)] <colinclark> I'm understanding what you mean now (smile)

[13:08:28 CDT(-0500)] <colinclark> So, this freaks me out

[13:08:31 CDT(-0500)] <michelled> oh good - I'm glad you can read my mind to a certain extent

[13:08:38 CDT(-0500)] <colinclark> no, I just read what you wrote above

[13:08:42 CDT(-0500)] <colinclark> (tongue)

[13:08:46 CDT(-0500)] <michelled> (smile)

[13:09:00 CDT(-0500)] <colinclark> are you saying that, somewhere, we're actually USING the VALUE of fluid.browser.requestFullScreen()

[13:09:01 CDT(-0500)] <colinclark> ?

[13:09:06 CDT(-0500)] <colinclark> dramatic capitalization!

[13:09:12 CDT(-0500)] <michelled> yes

[13:09:25 CDT(-0500)] <colinclark> omg

[13:09:33 CDT(-0500)] <colinclark> yes

[13:09:42 CDT(-0500)] <colinclark> that doesn't quite work, does it?

[13:09:53 CDT(-0500)] <michelled> https://github.com/fluid-project/videoPlayer/blob/master/js/VideoPlayer.js#L464

[13:10:00 CDT(-0500)] <michelled> nope, it doesn't work

[13:10:04 CDT(-0500)] <colinclark> yes, I see that

[13:10:15 CDT(-0500)] <colinclark> I fear this might even be my own clever advice at some point (sad)

[13:10:16 CDT(-0500)] <michelled> it "works" when we have the same element type that we are full screening

[13:10:24 CDT(-0500)] <colinclark> right

[13:12:40 CDT(-0500)] <michelled> ok, I'm glad you agree - I'll make the changes in my branch

[13:13:09 CDT(-0500)] <colinclark> I'm still uncomfortable, conceptually, with the idea that we'd actually use the value of fluid.browser.requestFullScreen()

[13:13:34 CDT(-0500)] <michelled> right, that's why I'd store the name as a string instead of the function

[13:13:48 CDT(-0500)] <michelled> I think that's safer and more correct

[13:14:02 CDT(-0500)] <michelled> although I'm guessing the code won't be as elegant

[13:16:16 CDT(-0500)] <colinclark> I'm tempted to suggest writing a very small jQuery plugin for this kind of thing

[13:17:26 CDT(-0500)] <colinclark> it seems odd that, the code below this, we don't use jQuery to bind events

[13:17:46 CDT(-0500)] <colinclark> but perhaps there is some subtlety there

[13:18:29 CDT(-0500)] <colinclark> also, the code around it

[13:21:59 CDT(-0500)] <michelled> interesting

[13:25:26 CDT(-0500)] <michelled> colinclark: I'll be looking at all the fullscreen code as part of the work I'm doing

[13:25:31 CDT(-0500)] <colinclark> great

[13:25:42 CDT(-0500)] <michelled> I'll think about the jquery plugin idea while I'm in there

[13:41:20 CDT(-0500)] <colinclark> michelled: In our fork of Captionator, do we bother to keep the minified version up to date with any changes we make?

[13:42:14 CDT(-0500)] <michelled> colinclark: no, we haven't done that

[13:42:16 CDT(-0500)] <michelled> we should

[13:42:23 CDT(-0500)] <michelled> certainly before we do a pull request to them

[13:42:29 CDT(-0500)] <michelled> would you like me to update it?

[13:43:06 CDT(-0500)] <colinclark> I guess it's not pressing, but it's always nice to avoid any kind of confusion

[13:43:15 CDT(-0500)] <colinclark> I have some very minor stylistic questions for you, michelled

[13:43:34 CDT(-0500)] <michelled> yes?

[13:44:05 CDT(-0500)] <colinclark> Here on this line: https://github.com/fluid-project/Captionator/pull/1/files#L1R262

[13:44:16 CDT(-0500)] <colinclark> At first, my brain was strangely stuck in Java land

[13:44:43 CDT(-0500)] <colinclark> I guess Java Strings had a startsWith() method...

[13:45:03 CDT(-0500)] <colinclark> Anyway, I guess there's no real difference to using substring and indexOf in this case?

[13:45:11 CDT(-0500)] <colinclark> Probably no reason to argue for one approach or the other

[13:45:31 CDT(-0500)] <michelled> I don't think so - do you have a preference?

[13:45:43 CDT(-0500)] <colinclark> nope

[13:46:06 CDT(-0500)] <colinclark> The other nit I'd pick is this line: https://github.com/fluid-project/Captionator/pull/1/files#L1R263

[13:46:27 CDT(-0500)] <colinclark> Where typically I'd imagine one might prefer to break out the call to readDataUrl() onto a separate line

[13:46:34 CDT(-0500)] <colinclark> with a variable assignment, so it was easier to debug

[13:46:40 CDT(-0500)] <michelled> ah, yes, good point

[13:48:53 CDT(-0500)] <colinclark> if you're okay with it, i'll make the change when I push

[13:49:03 CDT(-0500)] <michelled> yes, thanks - that would be great

[13:52:42 CDT(-0500)] <jhung> justin_o, cindyli - I'm working on the export captures dialog now.

[13:52:49 CDT(-0500)] <jhung> I'll take a look at the error code too

[13:52:53 CDT(-0500)] <Justin_o> jhung: thanks

[13:53:08 CDT(-0500)] <colinclark> michelled: eek… is Captionator a tabby file?

[13:56:36 CDT(-0500)] <jhung> justin_o got a sec to skype?

[13:56:48 CDT(-0500)] <Justin_o> sure..

[13:56:52 CDT(-0500)] <michelled> colinclark: I didn't pay attention - although now that you mention it, my changes look to be tabbed oddly

[13:57:04 CDT(-0500)] <colinclark> it looks completely bizarre to me

[13:59:25 CDT(-0500)] <michelled> colinclark: would you like me to fix the tabbing, make the little change and push?

[13:59:35 CDT(-0500)] <colinclark> no, it's fine

[13:59:41 CDT(-0500)] <colinclark> best to do that as a separate thing

[13:59:45 CDT(-0500)] <colinclark> I've pushed the changes

[13:59:50 CDT(-0500)] <colinclark> if you want to tweak whitespace now, go of rit

[13:59:55 CDT(-0500)] <colinclark> for it (smile)

[14:02:06 CDT(-0500)] <michelled> thanks for pushing my change colinclark!

[14:02:23 CDT(-0500)] <michelled> anastasiac: my Captionator branch is in now - I know you were waiting for it

[14:03:00 CDT(-0500)] <michelled> anastasiac: we should also update the Video Player to use the project repo master again

[14:03:15 CDT(-0500)] <anastasiac> yay! thanks, michelled. now I can submit a pull request for my stuff

[14:03:16 CDT(-0500)] <michelled> of Captionator, that is

[14:03:19 CDT(-0500)] <anastasiac> right

[15:07:10 CDT(-0500)] <Justin_o> Bosmon2: are you there?

[15:14:35 CDT(-0500)] <thealphanerd> colinclark: there?

[15:14:52 CDT(-0500)] <colinclark> in an interview at the moment, but i'll be free in 15 minutes or so

[15:16:42 CDT(-0500)] <thealphanerd> cool

[15:16:48 CDT(-0500)] <colinclark> but feel free ramble in the interim

[15:16:49 CDT(-0500)] <thealphanerd> ping me when you have a moment

[15:16:57 CDT(-0500)] <colinclark> i can still read; just not necessarily respond (smile)

[15:17:12 CDT(-0500)] <thealphanerd> just wanted to know if you have played with meteo or not

[15:17:25 CDT(-0500)] <thealphanerd> and I also got that accelerometer stuff working

[15:17:28 CDT(-0500)] <thealphanerd> wanted to show the video

[15:20:45 CDT(-0500)] <thealphanerd> http://vimeo.com/52651981

[15:20:47 CDT(-0500)] <thealphanerd> the video

[15:21:10 CDT(-0500)] <thealphanerd> http://meteor.com/

[15:21:11 CDT(-0500)] <thealphanerd> meteor

[15:21:25 CDT(-0500)] <colinclark> that's some hat, thealphanerd

[15:21:32 CDT(-0500)] <thealphanerd> adventure time!

[15:22:50 CDT(-0500)] <colinclark> I have not used Meteor

[15:23:07 CDT(-0500)] <colinclark> It's the fashion framework of the day, as alexn can tell you about from his conference a few months ago

[15:23:20 CDT(-0500)] <colinclark> My sense is that it's probably a very problematic architecture

[15:23:32 CDT(-0500)] <colinclark> back to the days of "but the web doesn't have state! we should fix that"

[15:24:46 CDT(-0500)] <colinclark> jQuery Kontrol looks cool, thealphanerd

[15:25:06 CDT(-0500)] <thealphanerd> fuck jquery kontrol

[15:25:09 CDT(-0500)] <thealphanerd> I really dislike it

[15:25:12 CDT(-0500)] <colinclark> ah

[15:25:13 CDT(-0500)] <colinclark> how come?

[15:25:18 CDT(-0500)] <thealphanerd> super janky

[15:25:21 CDT(-0500)] <thealphanerd> non responsive

[15:25:27 CDT(-0500)] <colinclark> lol

[15:25:31 CDT(-0500)] <colinclark> I dig your passion

[15:25:44 CDT(-0500)] <thealphanerd> its a hack on top of jquery

[15:25:49 CDT(-0500)] <thealphanerd> rather than a tool that leverages

[15:25:55 CDT(-0500)] <colinclark> so why did you use it?

[15:25:57 CDT(-0500)] <colinclark> just fast?

[15:26:00 CDT(-0500)] <thealphanerd> the meta programming seems cool, but is just problematic

[15:26:08 CDT(-0500)] <thealphanerd> agile

[15:26:19 CDT(-0500)] <thealphanerd> I am going to work on interface tools… but I don't have time atm.

[15:26:24 CDT(-0500)] <thealphanerd> want immediete results to test stuff

[15:26:34 CDT(-0500)] <colinclark> cool, good to know

[15:26:54 CDT(-0500)] <thealphanerd> I found that constantly pushing the accel data is a bad idea

[15:27:00 CDT(-0500)] <thealphanerd> had some browser crash's

[15:27:07 CDT(-0500)] <yura> thealphanerd: awesome stuff

[15:27:10 CDT(-0500)] <colinclark> yeah, that's interesting

[15:27:10 CDT(-0500)] <thealphanerd> so I think I need to be dumping it in to a model

[15:27:12 CDT(-0500)] <thealphanerd> and then polling

[15:27:20 CDT(-0500)] <colinclark> and firing change events on a timer or something?

[15:27:20 CDT(-0500)] <thealphanerd> that way you can turn it on and off too

[15:27:32 CDT(-0500)] <thealphanerd> have the server poll the client at a frame rate

[15:27:38 CDT(-0500)] <thealphanerd> and then filter that data or something

[15:27:47 CDT(-0500)] <thealphanerd> do some sort of averaging and smoothing to it

[15:28:00 CDT(-0500)] <thealphanerd> yura: thanks!

[15:28:07 CDT(-0500)] <thealphanerd> yura: you have any thoughts on meteor?

[15:28:32 CDT(-0500)] <thealphanerd> colinclark: I really want to impement control objects as infusion components

[15:28:37 CDT(-0500)] <thealphanerd> some basic interactive primatives

[15:28:43 CDT(-0500)] <colinclark> thealphanerd: do it! I'll help!

[15:28:52 CDT(-0500)] <colinclark> I was thinking about a GSoC project for this summer

[15:28:59 CDT(-0500)] <colinclark> Are you thinking of doing it again this summer, thealphanerd?

[15:29:05 CDT(-0500)] <thealphanerd> most likely

[15:29:12 CDT(-0500)] <thealphanerd> unless I get offered some sort of crazy internship

[15:29:26 CDT(-0500)] <thealphanerd> which I don't see happening in the immediete future

[15:29:27 CDT(-0500)] <thealphanerd> i

[15:29:42 CDT(-0500)] <thealphanerd> but I have a fellowship that allows up to 18 units a quarter

[15:29:53 CDT(-0500)] <thealphanerd> so I was talking to julius and he agreed to do an independent study with me

[15:29:56 CDT(-0500)] <thealphanerd> to top up my units

[15:30:14 CDT(-0500)] <thealphanerd> so if I'm only taking 13 units of classes next quarter I can use the remaining units for independent research

[15:30:27 CDT(-0500)] <thealphanerd> which will probably be generative UI + dsp stuff

[15:31:33 CDT(-0500)] <thealphanerd> colinclark: IRCAM is working right now on a restful api faust compiler

[15:33:14 CDT(-0500)] <colinclark> cool, that'll be great--the independent study

[15:33:34 CDT(-0500)] <colinclark> i wonder what that means--a restful faust api

[15:33:46 CDT(-0500)] <thealphanerd> so you can send a post message to the server

[15:33:50 CDT(-0500)] <thealphanerd> with your faust code

[15:33:56 CDT(-0500)] <thealphanerd> and it will compile and launch the device

[15:34:00 CDT(-0500)] <colinclark> ah

[15:34:02 CDT(-0500)] <thealphanerd> super fast compile times

[15:34:21 CDT(-0500)] <thealphanerd> so I'm thinking of making a ui api that can deploy in a similar manner with a json model

[15:34:29 CDT(-0500)] <thealphanerd> and faust can do osc

[15:35:04 CDT(-0500)] <colinclark> I was thinking that part of a summer GSoC project with Flocking would involve adding Node.js server and OSC support

[15:35:24 CDT(-0500)] <colinclark> Get it to the point where it's analogous to something like SuperCollider on desktop

[15:38:52 CDT(-0500)] <thealphanerd> interesting

[15:39:54 CDT(-0500)] <thealphanerd> we should definitely discuss at length

[15:40:03 CDT(-0500)] <thealphanerd> as GSOC is definitely something I would be interested in doing again

[15:40:14 CDT(-0500)] <colinclark> we can customize it, too

[15:41:52 CDT(-0500)] <thealphanerd> colinclark: I found a bug in homebrew this week!

[15:44:14 CDT(-0500)] <thealphanerd> So I was talking to julius

[15:44:27 CDT(-0500)] <thealphanerd> and he was curious about why one would want to run flocking server side

[15:44:35 CDT(-0500)] <thealphanerd> use cases and such

[15:44:53 CDT(-0500)] <thealphanerd> I was arguing flexible non blocking inturpreted synthesis

[15:45:04 CDT(-0500)] <thealphanerd> your thoughts?

[15:46:03 CDT(-0500)] <thealphanerd> also there are some guys from south america you should be talking to… that are doing some really crazy stuff

[15:54:29 CDT(-0500)] <colinclark> thealphanerd: It's a good question

[15:54:47 CDT(-0500)] <colinclark> And I guess the first point is that I don't really think Flocking need ever run "server side"

[15:55:01 CDT(-0500)] <colinclark> in the sense of "on some box somewhere in a data centre with no speakers connected to it"

[15:55:25 CDT(-0500)] <colinclark> Increasingly I see Node.js as a very viable desktop application development tool

[15:55:38 CDT(-0500)] <thealphanerd> in which case you have a local server much like super collider

[15:55:39 CDT(-0500)] <colinclark> i.e. It provides a ubiquitous, high-level language

[15:55:53 CDT(-0500)] <colinclark> combined with very good extensibility at the C++ layer

[15:56:03 CDT(-0500)] <colinclark> thealphanerd: yeah, exactly

[15:56:22 CDT(-0500)] <colinclark> Honestly, I see a world where most applications are actually written with web technologies

[15:56:33 CDT(-0500)] <colinclark> regardless of whether or not they are packaged as a "native" application

[15:56:36 CDT(-0500)] <thealphanerd> I was saying it could be really interesting to live update parts of unit generators that would normally be encapsulated in compiled code

[15:56:48 CDT(-0500)] <thealphanerd> colinclark: I very much agre

[15:56:59 CDT(-0500)] <colinclark> so in the long run, a browser is your application runtime

[15:57:35 CDT(-0500)] <colinclark> But in the mean time, a Node.js port of Flocking appears to be relatively straightforward, and will provide a first way to make this separation, as you're suggesting, of the signal processing pipeline from the rest of the UI

[15:57:44 CDT(-0500)] <colinclark> in a more extensible way than the current Web Audio API can enable

[15:58:18 CDT(-0500)] <thealphanerd> I like this idea of deployable black box's

[15:58:23 CDT(-0500)] <colinclark> Anyway, in the long run, I figure everything will be in the browser--it just may or many not look and feel like a browser

[15:58:27 CDT(-0500)] <thealphanerd> that can be populated on various devices

[15:58:39 CDT(-0500)] <thealphanerd> that can do dsp and has a web based ui

[15:58:42 CDT(-0500)] <colinclark> in the medium term, it would be nice to have a platform for integrating with with OSC and the like

[15:59:04 CDT(-0500)] <thealphanerd> I was also playing with the idea of a "conductor" which actually serves all the web content

[15:59:17 CDT(-0500)] <thealphanerd> but you push all your interaction through a socket to the device doing the dsp

[15:59:37 CDT(-0500)] <thealphanerd> which would allow you to leverage the raspi for example… without having to deal with how slow it we be at rendering html

[15:59:45 CDT(-0500)] <colinclark> yes

[15:59:53 CDT(-0500)] <colinclark> though it's just as slow at rendering sound (smile)

[16:00:16 CDT(-0500)] <thealphanerd> lol

[16:06:11 CDT(-0500)] <thealphanerd> anyways I gotta run for now colinclark

[16:06:14 CDT(-0500)] <thealphanerd> we'll talk soon

[16:06:17 CDT(-0500)] <colinclark> yup

[16:06:17 CDT(-0500)] <thealphanerd> as always thanks for the time

[16:06:30 CDT(-0500)] <thealphanerd> btw

[16:06:39 CDT(-0500)] <thealphanerd> you should come visit ccrma as a visiting scholar

[16:06:49 CDT(-0500)] <thealphanerd> Spring quarter has some crazy shit going on

[16:06:55 CDT(-0500)] <thealphanerd> Robert Henke!!!

[16:41:56 CDT(-0500)] <colinclark> thealphanerd: Get me an invite and I will!