fluid-work IRC Logs-2013-06-12

Owned by Fluid IRC Log Bot
Last updated: Jun 12, 2013Version comment
9 min read

[09:46:00 CDT(-0500)] <michelled> yzen: I just pushed your branch!

[09:46:10 CDT(-0500)] <michelled> can you close JIRAs as appropriate?

[09:46:31 CDT(-0500)] <yzen> k

[11:07:51 CDT(-0500)] <kasper> michelled: do you have time to meet tomorrow re: integration testing?

[11:50:47 CDT(-0500)] <colinclark> morning, thealphanerd

[11:50:53 CDT(-0500)] <thealphanerd> good morning colinclark

[11:50:59 CDT(-0500)] <thealphanerd> so I updated the code

[11:50:59 CDT(-0500)] <colinclark> early for you! (smile)

[11:51:02 CDT(-0500)] <colinclark> awesome

[11:51:05 CDT(-0500)] <thealphanerd> to use just a single compute function

[11:51:09 CDT(-0500)] <colinclark> i hope my comments were okay

[11:51:19 CDT(-0500)] <thealphanerd> your idea of HEAP32[ptr]

[11:51:21 CDT(-0500)] <thealphanerd> didn't work

[11:51:29 CDT(-0500)] <thealphanerd> unfortunately

[11:51:30 CDT(-0500)] <thealphanerd> doesn't return a float

[11:51:35 CDT(-0500)] <thealphanerd> return some random f'n number

[11:51:36 CDT(-0500)] <colinclark> right

[11:51:39 CDT(-0500)] <colinclark> you're missing an F (smile)

[11:51:46 CDT(-0500)] <thealphanerd> ??

[11:51:57 CDT(-0500)] <thealphanerd> HEAP32F ???

[11:52:04 CDT(-0500)] <colinclark> HEAPF32

[11:52:08 CDT(-0500)] <colinclark> So, the Emscripten heap is just an ArrayBuffer

[11:52:09 CDT(-0500)] <thealphanerd> hmm one sec

[11:52:10 CDT(-0500)] <thealphanerd> lets try it

[11:52:17 CDT(-0500)] <colinclark> and they provide you with a set of TypedArray views on it

[11:52:22 CDT(-0500)] <colinclark> HEAP32 gives you integers (smile)

[11:52:27 CDT(-0500)] <colinclark> HEAPF32 gives you floats

[11:52:29 CDT(-0500)] <colinclark> etc.

[11:52:43 CDT(-0500)] <colinclark> The code sample I gave you included the F (wink)

[11:55:46 CDT(-0500)] <thealphanerd> oh wow

[11:55:47 CDT(-0500)] <thealphanerd> done

[11:55:52 CDT(-0500)] <thealphanerd> it works

[11:55:53 CDT(-0500)] <thealphanerd> (big grin)

[11:55:57 CDT(-0500)] <colinclark> oops (smile)

[11:56:32 CDT(-0500)] <thealphanerd> https://github.com/TheAlphaNerd/faust2webaudio/blob/master/js/wrapper.js#L33-L40

[11:56:52 CDT(-0500)] <thealphanerd> I guess it totally makes sense

[11:57:05 CDT(-0500)] <thealphanerd> since we already need to iterate across the entire ouput array anywys for web audio

[11:57:08 CDT(-0500)] <thealphanerd> this is definitely more efficient

[11:57:48 CDT(-0500)] <thealphanerd> and now I should probably make a model in there and an update function

[11:58:04 CDT(-0500)] <thealphanerd> to allow for things like variable buffers

[11:59:53 CDT(-0500)] <colinclark> I think it would be really awesome to do a real benchmark now

[12:00:09 CDT(-0500)] <colinclark> I guess you've probably got to generalize your architecture file so that it doesn't hard-code names

[12:00:13 CDT(-0500)] <colinclark> like NOISE_*

[12:00:38 CDT(-0500)] <colinclark> but it seems to me that Freeverb would be a great place to start

[12:00:47 CDT(-0500)] <colinclark> it's a reasonably computation-intensive algorithm

[12:00:53 CDT(-0500)] <colinclark> and it's been implemented many places

[12:01:05 CDT(-0500)] <colinclark> you could compile Faust's Freeverb and then compare it to the Flocking implementation

[12:01:20 CDT(-0500)] <colinclark> and that should show whether or not asm.js and Emscripten's runtime are paying their way or not

[12:01:56 CDT(-0500)] <colinclark> What do you mean by "a model" and "variable buffers," by the way?

[12:02:11 CDT(-0500)] <thealphanerd> well having a that.model

[12:02:23 CDT(-0500)] <thealphanerd> where I can store something like inputs / outputs/ buffersize / frequency

[12:02:34 CDT(-0500)] <thealphanerd> there are a couple things I need to work out before we can do bench marks as well

[12:02:56 CDT(-0500)] <thealphanerd> right now we can really only manage a single output channel

[12:03:04 CDT(-0500)] <thealphanerd> due to the way I am managing memroy

[12:03:22 CDT(-0500)] <thealphanerd> I need to modify the c++ code in order to allow for persistence of the original float ** arrays

[12:03:31 CDT(-0500)] <thealphanerd> in order to send all input / output channels{color}

[12:03:48 CDT(-0500)] <thealphanerd> then I need to modify the js to deal with these more complicated data structures

[12:03:48 CDT(-0500)] <colinclark> I guess in the Flocking notion of what a model is, these kinds of details would be "options" rather than a model

[12:04:06 CDT(-0500)] <colinclark> since they don't really change dynamically over the lifetime of the unit generator

[12:04:15 CDT(-0500)] <thealphanerd> and then I need to figure out how to take a js array, wrap it into the heap and send it back to c++

[12:04:38 CDT(-0500)] <thealphanerd> colinclark: that makes sense I guess… if you changed buffer size you would be recreating the ugne

[12:04:44 CDT(-0500)] <thealphanerd> but what about something like frequency?

[12:04:59 CDT(-0500)] <colinclark> I guess it depends what you mean by frequency...

[12:05:17 CDT(-0500)] <colinclark> if it's the frequency of, say, a sine tone

[12:05:18 CDT(-0500)] <colinclark> that's an "input"

[12:05:24 CDT(-0500)] <colinclark> i.e. another signal

[12:06:02 CDT(-0500)] <thealphanerd> this is something i was trying to figure out how to handle

[12:06:12 CDT(-0500)] <thealphanerd> because faust relies on UI elements for these types of control

[12:06:18 CDT(-0500)] <thealphanerd> so I'm not sure how it would really translate

[12:06:34 CDT(-0500)] <thealphanerd> without being hard tied to UI elements

[12:06:34 CDT(-0500)] <colinclark> can you unpack what that means?

[12:06:51 CDT(-0500)] <thealphanerd> so in the syntax for faust

[12:06:58 CDT(-0500)] <thealphanerd> when you want to have something be "variable"

[12:07:03 CDT(-0500)] <thealphanerd> or "user controllable"

[12:07:11 CDT(-0500)] <thealphanerd> it would appear it is usually done through a UI element

[12:07:30 CDT(-0500)] <thealphanerd> for example

[12:07:45 CDT(-0500)] <thealphanerd> volume control would be done by multiplying the output signal by an fslider with a specific range

[12:09:20 CDT(-0500)] <colinclark> Well, I imagine it's a bit more flexible than that

[12:09:41 CDT(-0500)] <colinclark> You might choose, as one option, to place an fslider into your code

[12:09:57 CDT(-0500)] <colinclark> let's say you've got a low frequency noise oscillator

[12:10:07 CDT(-0500)] <colinclark> you could, for its frequency, hook up an fslider

[12:10:15 CDT(-0500)] <colinclark> or you could hook up, say, a sine wave oscillator that modulated the frequency

[12:10:29 CDT(-0500)] <colinclark> in Faust, as I understand it, UI controls are themselves unit generators

[12:11:16 CDT(-0500)] <colinclark> So, that should be something you can model in Web Audio or in Flocking in some way

[12:11:21 CDT(-0500)] <colinclark> at least as a starting point

[12:14:18 CDT(-0500)] <thealphanerd> indeed

[12:14:46 CDT(-0500)] <thealphanerd> I guess the main thing is figuring out exactly how it all works

[12:14:56 CDT(-0500)] <thealphanerd> perhaps I should look at the sin example in faust

[12:15:02 CDT(-0500)] <thealphanerd> might explain a thing ot two

[12:15:45 CDT(-0500)] <colinclark> As I say, you should always tell me to shut up if I'm meddling...

[12:16:07 CDT(-0500)] <colinclark> but were it me, I'd try to get to the point where you can do a side-by-side benchmark of a reasonable algorithm

[12:16:14 CDT(-0500)] <colinclark> Freeverb or whatever

[12:16:23 CDT(-0500)] <colinclark> and then generalize after that, once you know it's worth it

[12:16:52 CDT(-0500)] <colinclark> I'd be a bummer for you to invest a ton of work, only to find that it's cheaper not to use asm.js at all

[12:16:58 CDT(-0500)] <colinclark> It'd be

[12:17:19 CDT(-0500)] <thealphanerd> well that is true

[12:17:39 CDT(-0500)] <thealphanerd> so would you say I should just do something like hard-code a sine wave through freeverb?

[12:19:16 CDT(-0500)] <colinclark> I guess you'll probably want to be able to write data into the heap so that it can read input values

[12:19:39 CDT(-0500)] <colinclark> you'll get your first taste of Emscripten's _malloc()

[12:19:45 CDT(-0500)] <colinclark> which I was just telling Bosmon about

[12:19:58 CDT(-0500)] <colinclark> I mean, the good thing about all of this is that it's an extremely simple model

[12:20:08 CDT(-0500)] <colinclark> pointers are just indices pointing into the heap

[12:20:29 CDT(-0500)] <colinclark> so presumably you call malloc() and it allocates some space on the heap for you and gives you a pointer to it

[12:20:45 CDT(-0500)] <colinclark> at that point, you just write values into that spot in the heap

[12:20:51 CDT(-0500)] <colinclark> not unlike how you read values from it

[12:20:56 CDT(-0500)] <colinclark> I'm guessing, that is (smile)

[12:24:33 CDT(-0500)] <colinclark> If your results with asm.js and Emscripten look promising, I was planning to build in a "memory allocation strategy" into Flocking so that it would take care of, when instantiating the ugen graph, creating each ugen's output buffers on the heap correctly as needed, as well as managing pointers to the appropriate locations in a unit generator's options object.

[12:35:16 CDT(-0500)] <thealphanerd> neat

[12:35:25 CDT(-0500)] <thealphanerd> so yeah I think that it will most likely rely on malloc

[12:35:38 CDT(-0500)] <thealphanerd> the one challenge will be perfectly recreating the same data sctructure

[12:35:49 CDT(-0500)] <thealphanerd> I don't think it will be terribly hard, but it will be somewhat challenging

[12:35:58 CDT(-0500)] <thealphanerd> then I need t figure out how to make my wrappers more general

[12:39:02 CDT(-0500)] <colinclark> what do you mean, perfectly recreating the same data structure?

[12:45:57 CDT(-0500)] <thealphanerd> well the float **

[12:48:39 CDT(-0500)] <thealphanerd> BTW… thank you so much for your vested interest

[12:48:51 CDT(-0500)] <thealphanerd> having you and your insight has been amazing

[12:49:22 CDT(-0500)] <colinclark> i'm always happy to help

[12:49:27 CDT(-0500)] <colinclark> if it's not annoying

[12:50:05 CDT(-0500)] <colinclark> I'm assuming that a pointer to a pointer is just an index into the heap, which produces an integer value that is, well, a pointer back into the heap (smile)

[12:52:24 CDT(-0500)] <thealphanerd> not annoying at all

[12:52:26 CDT(-0500)] <thealphanerd> stop apologizing (big grin)

[12:52:36 CDT(-0500)] <thealphanerd> still my mentor

[12:53:28 CDT(-0500)] <colinclark> (smile)

[12:53:40 CDT(-0500)] <thealphanerd> and colinclark that is exactly what it is

[12:59:01 CDT(-0500)] <thealphanerd> wait… I don't remember typing that last message

[12:59:02 CDT(-0500)] <thealphanerd> weird

[12:59:12 CDT(-0500)] <colinclark> lol

[12:59:19 CDT(-0500)] <colinclark> I'm pretty jet lagged, so I barely remember typing anything right now

[13:15:40 CDT(-0500)] <michelled> colinclark: anastasiac and I are cleaning up some of the documentation that we have

[13:15:50 CDT(-0500)] <colinclark> cool

[13:15:53 CDT(-0500)] <colinclark> that's wicked

[13:16:13 CDT(-0500)] <michelled> we were talking a bit about the distinction between the general wiki space and the documentation space

[13:16:44 CDT(-0500)] <colinclark> ok

[13:17:31 CDT(-0500)] <michelled> I think the wiki is for people who work on building Infusion whereas the doc space is for people who use Infusion

[13:17:38 CDT(-0500)] <michelled> the user base is quite varied, as you know

[13:18:24 CDT(-0500)] <colinclark> yes

[13:18:32 CDT(-0500)] <colinclark> I can imagine that if someone has a proposal for an idea

[13:18:42 CDT(-0500)] <colinclark> or a working document where they're thinking about a concept

[13:19:22 CDT(-0500)] <colinclark> then it would go in the wiki?

[13:19:32 CDT(-0500)] <colinclark> whereas the doc space would contain all the awesome?

[13:19:40 CDT(-0500)] <michelled> yes

[13:20:08 CDT(-0500)] <michelled> also, the docs space would contain things that seem generally useful to people who build with Infusion

[13:20:21 CDT(-0500)] <michelled> here's a couple examples of things I think should move to the docs space:

[13:20:29 CDT(-0500)] <michelled> that are currently in the wiki

[13:20:29 CDT(-0500)] <michelled> http://wiki.fluidproject.org/display/fluid/The+Geometric+Manager

[13:20:35 CDT(-0500)] <michelled> http://wiki.fluidproject.org/display/fluid/Writing+JavaScript+Unit+Tests

[13:21:17 CDT(-0500)] <colinclark> Ah, great examples

[13:21:17 CDT(-0500)] <michelled> but perhaps this should actually move back to the wiki from the docs space: http://wiki.fluidproject.org/display/docs/Contributing+Code+To+Infusion

[13:21:21 CDT(-0500)] <colinclark> those look very documentation-like to me

[13:22:09 CDT(-0500)] <colinclark> Yes, that latter page seems more like a working page

[13:23:26 CDT(-0500)] <michelled> we are also thinking of creating a archive doc space for documentation that is not relevant to our current framework but would still be useful for people using 1.3

[13:24:41 CDT(-0500)] <michelled> like this: http://wiki.fluidproject.org/display/fluid/How+to+Define+a+Unit

[13:24:48 CDT(-0500)] <michelled> which is pre-IOC

[13:25:01 CDT(-0500)] <colinclark> yes, that seems reasonable to me

[13:25:50 CDT(-0500)] <michelled> cool

[13:26:02 CDT(-0500)] <michelled> our very cryptic working notes are here: http://wiki.fluidproject.org/display/fluid/Pre-1.5+Docs+Tasks

[13:26:22 CDT(-0500)] <michelled> and we'll be getting all the pages into the correct space soon

[13:31:26 CDT(-0500)] <colinclark> I think it seems like a very sensible plan

[13:31:33 CDT(-0500)] <colinclark> I think you'll literally be heroes in the community

[13:31:42 CDT(-0500)] <colinclark> if we can get to the point where we have awesome documentation

[13:39:27 CDT(-0500)] <thealphanerd> +1 on documentation

[13:47:43 CDT(-0500)] <anastasiac> vjoanna, would you happen to have the icons for the video player captions and transcripts panels in new-uio? as in the upper left corner of this: http://wiki.fluidproject.org/download/attachments/34575412/uio_caption_panel.png?version=1&amp;modificationDate=1365717821751

[13:50:17 CDT(-0500)] <anastasiac> vjoanna, if you have them, could you attach them to this jura? http://issues.fluidproject.org/browse/VP-297

[13:53:17 CDT(-0500)] <vjoanna> anastasiac, are they not part of the icon font set?

[13:53:40 CDT(-0500)] <anastasiac> ah, right. I don't know (smile) I'll find out

[13:55:11 CDT(-0500)] <vjoanna> i think the caption one should be, but i don't know if a transcript one was created

[13:55:31 CDT(-0500)] <anastasiac> how to I look at the font?

[13:58:41 CDT(-0500)] <vjoanna> hm.. i'm not sure what the best way to is, but i know in font book there's a toggle to see all the characters on the top left corner

[14:02:40 CDT(-0500)] <vjoanna> hiediv, do you know if there's a better way? ^

[14:06:20 CDT(-0500)] <yzen> anastasiac: ping

[14:07:11 CDT(-0500)] <anastasiac> yzen, polo

[14:09:00 CDT(-0500)] <yzen> anastasiac: would you have a link to an example of what the integrator would like for FLUID-5016, e.g. wordpress plugin use case

[14:09:14 CDT(-0500)] <anastasiac> hm

[14:09:38 CDT(-0500)] <anastasiac> well, I have the wordpress plugin code, but it represents the current state of affairs, not the desired state

[14:10:02 CDT(-0500)] <anastasiac> I haven't thought much about what I think it should look like, yzen

[14:12:01 CDT(-0500)] <yzen> anastasiac: oh ok, np

[14:17:48 CDT(-0500)] <anastasiac> yzen, do you want us to help you come up with something, or are you ok to figure something out?

[14:18:20 CDT(-0500)] <yzen> anastasiac: ill try to sketch something up , will share on list for input, perhaps

[14:18:55 CDT(-0500)] <anastasiac> sounds good, yzen

[14:33:18 CDT(-0500)] <Justin_o> heidiv: looks like we forgot to add the font icons to the full page UIO

[14:33:42 CDT(-0500)] <heidiv> Justin_o really? uses the same templates

[14:34:14 CDT(-0500)] <Justin_o> heidiv: might be that we just forgot to change something to prevent it from looking for the images

[14:34:20 CDT(-0500)] <Justin_o> getting some errors in firebug

[14:34:36 CDT(-0500)] <heidiv> Justin_o ok, maybe jon can tweak it?

[14:37:22 CDT(-0500)] <heidiv> Justin_o i can edit my branch tho, if need be

[14:37:37 CDT(-0500)] <Justin_o> heidiv: i guess we can chat tomorrow about it.. jon is on his way hom

[14:37:39 CDT(-0500)] <Justin_o> home

[14:37:47 CDT(-0500)] <heidiv> okee doke

[14:47:15 CDT(-0500)] <Justin_o> heidiv: looks like it might be the icons for the section headers there.. cindyli1 is going to file a jira for it

[14:47:45 CDT(-0500)] <heidiv> ok cool thanks cindyli

[14:47:53 CDT(-0500)] <cindyli1> np