fluid-work IRC Logs-2013-02-12
- Fluid IRC Log Bot
[10:12:39 CST(-0600)] <Justin_o> Bosmon, colinclark, michelled: i've added a new pull request for the progressive enhancement changes https://github.com/fluid-project/infusion/pull/263
[10:12:48 CST(-0600)] <michelled> thx Justin_o
[10:34:43 CST(-0600)] <jessm> fluid-everyone: colinclark and I are on the subject matter expert committee meeting for Prefs for Global Access
[10:35:04 CST(-0600)] <colinclark> that's our standup update 
[12:08:07 CST(-0600)] <Justin_o> heidiv, cindyli: I commented on the pull request for FLUID-4599
[12:08:11 CST(-0600)] <Justin_o> some minor changes needed
[12:08:33 CST(-0600)] <heidiv> Justin_o thanks
[12:46:28 CST(-0600)] <Justin_o> heidiv, cindyli: when do you think you'll have the branch updated?
[12:46:42 CST(-0600)] <heidiv> Justin_o i'll do it now!
[12:47:04 CST(-0600)] <cindyli> Justin_o: heidiv, i will push up the change in a couple of minutes
[12:47:05 CST(-0600)] <Justin_o> heidiv: thanks
[12:47:40 CST(-0600)] <Justin_o> cindyli: thanks
[12:47:45 CST(-0600)] <cindyli> np
[12:49:08 CST(-0600)] <Justin_o> heidiv: does your pull request for vp-46 include your changes for FLUID-4599 or are they distinct and it just depends on it
[12:49:26 CST(-0600)] <heidiv> Justin_o , the latter i think/hope
[12:49:41 CST(-0600)] <Justin_o> heidiv: okay.. so i'll look at it afterwards then
[12:50:32 CST(-0600)] <cindyli> heidiv: my change for FLUID-4599 has been pushed up to my github branch - https://github.com/cindyli/videoPlayer/tree/FLUID-4599. Can you merge it in when you are ready?
[12:50:45 CST(-0600)] <heidiv> cindyli will do
[12:50:47 CST(-0600)] <heidiv> thanks
[12:50:59 CST(-0600)] <cindyli> np. thank you.
[12:53:33 CST(-0600)] <heidiv> Justin_o did you remove those fullscreen comments we found
[12:53:42 CST(-0600)] <Justin_o> heidiv: i haven't no
[12:56:43 CST(-0600)] <heidiv> Justin_o updated pull req. didn't do fullscreen comment thing
[12:57:06 CST(-0600)] <heidiv> i'm not seeing them now
[13:00:13 CST(-0600)] <Justin_o> heidiv: okay.. maybe they were removed somewhere else
[13:00:26 CST(-0600)] <Justin_o> i'll try to look again for the other changes i need to do after
[13:14:05 CST(-0600)] <Justin_o> heidiv: i'm just noticing that captions appear over top of the controls for the IE 8
[13:14:31 CST(-0600)] <Justin_o> heidiv: actually make that anywhere that has captions
[13:14:33 CST(-0600)] <heidiv> is that a new thing?
[13:15:20 CST(-0600)] <Justin_o> heidiv: yes.. the build site doesn't show this behaviour http://build.fluidproject.org/videoPlayer/videoPlayer/demos/VideoPlayer.html
[13:15:31 CST(-0600)] <Justin_o> seems like the captions are a bit lower than they used to be too
[13:15:32 CST(-0600)] <heidiv> just looked too
[13:15:54 CST(-0600)] <heidiv> perhaps the overlay img offsets it a bit. i'll take a closer look justin, good catch.
[13:16:14 CST(-0600)] <Justin_o> heidiv: thanks
[13:45:37 CST(-0600)] <Justin_o> Bosmon: are you free to look over my FLUID-4794 pull request now.. michelle has gone over it once.. i've made a name change based on her review so far
[13:45:57 CST(-0600)] <Justin_o> Bosmon: https://github.com/fluid-project/infusion/pull/263
[13:45:57 CST(-0600)] <Bosmon> Justin_o - shortly, yes
[13:46:08 CST(-0600)] <Justin_o> Bosmon: thanks
[13:50:51 CST(-0600)] <Bosmon> hahaha
[13:50:59 CST(-0600)] <Bosmon> yzen was banned for Excess Flood
[13:51:07 CST(-0600)] <yzen> i know
[13:51:21 CST(-0600)] <Justin_o> yzen: what have you been doing?
[13:51:32 CST(-0600)] <yzen> just trying to push some stuff
[14:05:15 CST(-0600)] <thealphanerd> colinclark: you around?
[14:05:22 CST(-0600)] <colinclark> I am, yes
[14:10:10 CST(-0600)] <thealphanerd> so I was just thinking about flocking running on node
[14:10:27 CST(-0600)] <thealphanerd> and was curious if you had any inclination to submit a paper about it to linux audio conference
[14:13:31 CST(-0600)] <Justin_o> michelled, anastasiac: i'm just looking through the video player code and I see that the html5 check is done by just ensuring that we aren't in an IE that is below version 9… i'm wondering how safe this is
[14:13:55 CST(-0600)] <michelled> it's terrible Justin_o
[14:14:07 CST(-0600)] <Justin_o> michelled: thanks for the honesty
[14:14:08 CST(-0600)] <michelled> well, that might be a little dramatic
[14:14:48 CST(-0600)] <Justin_o> michelled: what do we really want to know here.. i don't think we necessarily care that html5 is supported.. as this is somewhat varying across browsers
[14:14:56 CST(-0600)] <Justin_o> maybe we really want to know if video or something is supported?
[14:15:11 CST(-0600)] <michelled> Justin_o: I actually wonder whether those checks make any sense anymore
[14:15:23 CST(-0600)] <michelled> they were in before we were using media element
[14:15:35 CST(-0600)] <Justin_o> michelled: oh so you mean it's taken care of anyways
[14:15:44 CST(-0600)] <michelled> I'm wondering if that's the case
[14:15:45 CST(-0600)] <michelled> I'm not sure
[14:15:47 CST(-0600)] <Justin_o> well there are somethings that seem to be listener to it
[14:15:49 CST(-0600)] <michelled> let's look at it together
[14:15:52 CST(-0600)] <Justin_o> okay
[14:17:45 CST(-0600)] <colinclark> thealphanerd: It's a good idea
[14:17:51 CST(-0600)] <colinclark> Adam Tindale suggested it as well
[14:17:55 CST(-0600)] <colinclark> Do you think I should?
[14:18:00 CST(-0600)] <thealphanerd> I'd be happy to contribute
[14:18:06 CST(-0600)] <thealphanerd> I tihnk it wouldn't be a bad idea
[14:18:12 CST(-0600)] <colinclark> ok, let's do it, thealphanerd!
[14:18:12 CST(-0600)] <thealphanerd> aprantly not the hardest conference to get in to
[14:18:38 CST(-0600)] <thealphanerd> we can go to austria 
[14:18:39 CST(-0600)] <thealphanerd> http://lac.linuxaudio.org/
[14:19:27 CST(-0600)] <thealphanerd> Deadline is the 17th though
[14:19:28 CST(-0600)] <thealphanerd> :S
[14:19:32 CST(-0600)] <thealphanerd> didn't realize it was so soon
[14:20:03 CST(-0600)] <thealphanerd> http://lac.linuxaudio.org/2013/participation
[14:21:34 CST(-0600)] <colinclark> I love Austria
[14:23:04 CST(-0600)] <thealphanerd> I've never been
[14:42:44 CST(-0600)] <Bosmon> Austria was very nice, especially the countryside
[14:42:59 CST(-0600)] <Bosmon> Although the urban areas seemed quite run-down compared to their equivalents in Germany
[14:43:12 CST(-0600)] <Bosmon> "Germany proper" as they would have said in the 30s : P
[14:46:42 CST(-0600)] <thealphanerd> colinclark: I have to run
[14:46:50 CST(-0600)] <colinclark> ok
[14:46:51 CST(-0600)] <thealphanerd> but lets talk later about this if you are interesting in following up
[14:46:53 CST(-0600)] <colinclark> yes
[14:46:54 CST(-0600)] <colinclark> let's
[14:46:58 CST(-0600)] <colinclark> i'll probably be around tomorrow
[14:47:03 CST(-0600)] <thealphanerd> it is a bit of a tight deadlien
[15:23:55 CST(-0600)] <michelled> Bosmon: when you get a chance, can you send me an email with the API changes in the GINGER PULL?
[15:27:01 CST(-0600)] <Bosmon> michelled - sure
[15:42:01 CST(-0600)] <Bosmon> michelled - can you read this link?
[15:42:01 CST(-0600)] <Bosmon> https://docs.google.com/spreadsheet/ccc?key=0ApCpzZAxbl6AdHVVeG1sNUNyOVJxanBVUjVmT0laQmc#gid=0
[15:46:26 CST(-0600)] <michelled> Bosmon: yep
[15:46:28 CST(-0600)] <michelled> thanks
[18:30:32 CST(-0600)] <colinclark> Hey thealphanerd, are you back now?
[18:30:42 CST(-0600)] <thealphanerd> I am here now
[18:30:46 CST(-0600)] <thealphanerd> but in julius' class
[18:30:57 CST(-0600)] <thealphanerd> I can talk but I might take time between responses
[18:31:10 CST(-0600)] <thealphanerd> learning https://ccrma.stanford.edu/~jos/Interpolation/Allpass_Interpolated_Delay_Line.html
[18:32:19 CST(-0600)] <colinclark> I won't distract you while you're in class
[18:32:33 CST(-0600)] <colinclark> But I forgot to mention earlier that I was accepted to speak at the SuperCollider 2013 conference in Boulder
[18:32:44 CST(-0600)] <colinclark> so I'm planning to sleep on Bosmon's floor
[18:32:48 CST(-0600)] <colinclark> I'll be presenting Flocking
[18:32:55 CST(-0600)] <colinclark> and I think some of the work you're considering will be really great for that
[18:33:27 CST(-0600)] <thealphanerd> for supercollider conference?
[18:36:14 CST(-0600)] <thealphanerd> allpass interpolation is a head scratcher
[18:36:26 CST(-0600)] <Bosmon> ALLPASS INTERPPOLATION!
[18:36:54 CST(-0600)] <Bosmon> Oh, what a lovely transfer function....
[18:37:21 CST(-0600)] <thealphanerd> $\displaystyle \Delta \approx \frac $
[18:37:22 CST(-0600)] <thealphanerd>
[18:37:45 CST(-0600)] <thealphanerd> too bad you can't embed LaTeX in irc
[18:38:59 CST(-0600)] <Bosmon> thealphanerd - you just did
[18:39:39 CST(-0600)] <thealphanerd> well embed it and have it be rendered
[18:39:42 CST(-0600)] <Bosmon> Irrelevant scary mathematical nonsense - I think this transfer function is particularly beautiful because I believe it is a member of the MOEBIUS GROUPP
[18:39:48 CST(-0600)] <Bosmon> We can render it in our minds
[18:39:49 CST(-0600)] <thealphanerd> but I guess that would be something you could just implement inside your client of choice
[18:40:26 CST(-0600)] <thealphanerd> what's a MOEBIUS GROUP?
[18:40:40 CST(-0600)] <Bosmon> If you scroll far enough down - http://en.wikipedia.org/wiki/Möbius_transformation - there are some great pictures
[18:40:54 CST(-0600)] <Bosmon> It's one of the more astonishing and beautiful landmarks in complex variable theory
[18:41:09 CST(-0600)] <thealphanerd> interesting
[18:41:12 CST(-0600)] <thealphanerd> I'll ask julius about it
[18:41:42 CST(-0600)] <Bosmon> "Excuse me, Julius - isn't it the case that the transfer function for the allpass interpolated delay line is actually a member of the Moebius Group?" : P
[18:42:16 CST(-0600)] <thealphanerd> I was about to
[18:42:21 CST(-0600)] <thealphanerd> but he moved to linear interpolation
[18:42:25 CST(-0600)] <Bosmon> ha
[18:43:01 CST(-0600)] <thealphanerd> almost got some brownie points
[18:43:02 CST(-0600)] <thealphanerd> 
[18:43:06 CST(-0600)] <Bosmon> It's one of these example of the "golden wonders" that aren't enormously technical and are actually pretty universal
[18:43:08 CST(-0600)] <Bosmon> http://en.wikipedia.org/wiki/File:Escher_Circle_Limit_III.jpg
[18:43:14 CST(-0600)] <Bosmon> Look at this lovely picture
[18:43:37 CST(-0600)] <thealphanerd> indeed
[18:43:44 CST(-0600)] <thealphanerd> paterns!
[18:51:29 CST(-0600)] <colinclark> hilarious
[18:51:43 CST(-0600)] <colinclark> I guess at computer music school, it's okay to have a computer during class
[18:52:15 CST(-0600)] <thealphanerd> we have a ccrma channel that we chat in during class
[18:52:15 CST(-0600)] <thealphanerd> LOL
[18:53:06 CST(-0600)] <colinclark> In my class, people just check facebook
[18:53:30 CST(-0600)] <thealphanerd> lol
[18:53:37 CST(-0600)] <thealphanerd> you taking courses with OCAD undergrads?
[18:53:47 CST(-0600)] <Bosmon> In Clayton's classes, they just play Grand Theft Auto 
[18:53:52 CST(-0600)] <Bosmon> Really, students are scum......
[18:54:01 CST(-0600)] <thealphanerd> hey
[18:54:03 CST(-0600)] <thealphanerd> I'm a student
[18:54:23 CST(-0600)] <Bosmon> Well, you know what I mean.... one doesn't truly hate universal classes : P
[18:54:31 CST(-0600)] <Bosmon> I mean, I say, "I hate software developers"
[18:54:39 CST(-0600)] <thealphanerd> hey wait
[18:54:39 CST(-0600)] <Bosmon> But that doesn't mean I hate individual members of Fluid : P
[18:54:42 CST(-0600)] <thealphanerd> I'm a software developer
[18:54:46 CST(-0600)] <Bosmon> hahaha
[18:54:47 CST(-0600)] <thealphanerd> Bosmon: you must hate me so bad
[18:54:54 CST(-0600)] <colinclark> Bosmon: Hey, I'm a student!
[18:54:59 CST(-0600)] <thealphanerd> LOL
[18:55:03 CST(-0600)] <thealphanerd> I HATE BOSMONS
[18:55:03 CST(-0600)] <colinclark> And a software developer!
[18:55:05 CST(-0600)] <Bosmon> colinclark - I believe you ALSO hate students as well as software developers
[18:55:19 CST(-0600)] <Bosmon> NERDD - now this is getting personal : P
[18:55:21 CST(-0600)] * thealphanerd feels bad… he likes Bosmons just fine
[18:56:56 CST(-0600)] <colinclark> Bosmon, like a cat, is an "unsubstituteable singularity"
[18:57:07 CST(-0600)] <Bosmon> Like a .... POTASSON!
[18:57:56 CST(-0600)] <colinclark> as opposed to the "immense symbolic responsibility" charged to a software developer or a student
[18:58:05 CST(-0600)] <Bosmon> Yes
[18:58:37 CST(-0600)] <Bosmon> Like the responsibility charged to those
[18:59:06 CST(-0600)] <colinclark> I haven't taken any classes with undergrads at OCAD, no
[18:59:10 CST(-0600)] <colinclark> I'm not sure I could handle it
[18:59:15 CST(-0600)] <thealphanerd> colinclark: you probably couldn't
[18:59:46 CST(-0600)] <thealphanerd> it was fun and all… but I don't think I could go back now. Being surrounded by people who actually care is a crazy feeling
[19:02:25 CST(-0600)] <colinclark> yes
[19:02:35 CST(-0600)] <colinclark> you're very lucky to be in that environment, thealphanerd
[19:02:41 CST(-0600)] <colinclark> it doesn't happen everywhere
[19:02:44 CST(-0600)] <colinclark> even in grad school
[19:02:52 CST(-0600)] <thealphanerd> most definitely
[19:02:56 CST(-0600)] <thealphanerd> a total blessing
[19:04:18 CST(-0600)] <colinclark> Yes, so the SuperCollider conference
[19:04:36 CST(-0600)] <colinclark> If you do end up playing around with OSC in Flocking, I think it would be an amazing thing to demonstrate there
[19:04:46 CST(-0600)] <colinclark> you should come and demonstrate it with me
[19:13:10 CST(-0600)] <thealphanerd> colinclark: are you publishing a paper or just giving the talk?
[19:13:23 CST(-0600)] <thealphanerd> I'd be interesting in coming… and I will definitely have the osc stuff done this quarter
[19:14:40 CST(-0600)] <colinclark> It's a pretty informal conference, so I think it'll just be a talk
[19:20:48 CST(-0600)] <thealphanerd> colinclark: you still there?
[19:20:52 CST(-0600)] <colinclark> yup, for a sec
[19:21:16 CST(-0600)] <thealphanerd> I'd definitely be interested in contributing to the super collider talk
[19:21:28 CST(-0600)] <colinclark> that's great
[19:21:37 CST(-0600)] <thealphanerd> although depending on when it is running and my school schedule my attendence might have to be virtual
[19:21:41 CST(-0600)] <colinclark> No problem
[19:21:47 CST(-0600)] <thealphanerd> although flying to boulder for a day or two isn't that hard
[19:21:53 CST(-0600)] <colinclark> One of the things I said I'd do in the abstract was show ways that Flocking and SuperCollider could be integrated
[19:22:07 CST(-0600)] <thealphanerd> interesting
[19:22:10 CST(-0600)] <thealphanerd> osc would help with that
[19:22:13 CST(-0600)] <colinclark> Being able to control one from the other via OSC will be compelling, that way
[19:22:17 CST(-0600)] <colinclark> yup, exactly
[19:22:41 CST(-0600)] <thealphanerd> I guess the question is where the line is drawn between what is flocking and what is node
[19:23:03 CST(-0600)] <thealphanerd> and wether or not implementing a focking osc class even makes sense
[19:23:11 CST(-0600)] <thealphanerd> but I guess that is what we need to figure out
[19:23:14 CST(-0600)] <colinclark> yup
[19:23:22 CST(-0600)] <colinclark> There definitely will be some aspect that's directly related to Flocking
[19:23:28 CST(-0600)] <thealphanerd> as for linux audio… I think it would be a great opportinity to get exposure as well
[19:23:32 CST(-0600)] <colinclark> in that you want to be able to send OSC messages to do things like:
[19:23:35 CST(-0600)] <colinclark> 1. Create synths
[19:23:40 CST(-0600)] <colinclark> 2. Send messages to synths
[19:23:47 CST(-0600)] <colinclark> 3. Schedule events
[19:24:16 CST(-0600)] <colinclark> When I get the new "FRP-style" scheduler in place (if I can be so ambitious as to call it that), it should be super cool
[19:24:52 CST(-0600)] <thealphanerd> I guess the challenge is how do you make api to deal with osc
[19:24:56 CST(-0600)] <thealphanerd> when you can't do osc in the browser
[19:25:01 CST(-0600)] <thealphanerd> or without boot strapping over node
[19:25:21 CST(-0600)] <thealphanerd> do you want to have function calls that can only work with particular technology stacks
[19:25:46 CST(-0600)] <colinclark> At the moment, all Node-specific code is located in a specific file
[19:26:11 CST(-0600)] <thealphanerd> well the thing is… if you have flocking being deployed to the client by a node server
[19:26:19 CST(-0600)] <thealphanerd> there could be access to osc through sockets
[19:26:28 CST(-0600)] <thealphanerd> which is then a totally different layer
[19:26:28 CST(-0600)] <colinclark> yeah, there will have to be some kind of abstraction there
[19:26:44 CST(-0600)] <thealphanerd> I guess you could have the same function calls
[19:26:50 CST(-0600)] <colinclark> the good news is, the really hard parts of the abstraction should all be in place...
[19:26:59 CST(-0600)] <colinclark> in that Flocking is very declarative
[19:27:13 CST(-0600)] <colinclark> so it's all ready to be "sent messages from other universes" if that makes sense
[19:28:09 CST(-0600)] <thealphanerd> I will need you to elaborate on that idea at some point
[19:28:12 CST(-0600)] <colinclark>
[19:28:13 CST(-0600)] <colinclark> Yes
[19:28:16 CST(-0600)] <colinclark> it wasn't very clear
[19:28:20 CST(-0600)] <thealphanerd> so maybe this week
[19:28:23 CST(-0600)] <thealphanerd> if I can find the time
[19:28:28 CST(-0600)] <thealphanerd> (I'm drowning this week)
[19:28:35 CST(-0600)] <thealphanerd> I will attempt to get the repo stuff sorted out
[19:28:35 CST(-0600)] <colinclark> yup, no rush
[19:28:41 CST(-0600)] <thealphanerd> and maybe come up with some use cases
[19:28:44 CST(-0600)] <thealphanerd> for osc
[19:28:56 CST(-0600)] <colinclark> I can imagine that you'll implement two distinct strategies of "message sources"
[19:29:06 CST(-0600)] <thealphanerd> server
[19:29:11 CST(-0600)] <thealphanerd> and client > server > client
[19:29:38 CST(-0600)] <colinclark> I was thinking "straight OSC over UDP" vs. "web sockets in the browser"
[19:29:41 CST(-0600)] <colinclark> which I think is what you mean
[19:30:10 CST(-0600)] <thealphanerd> yup
[19:30:18 CST(-0600)] <colinclark> In the most basic sense, I imagine these are really just "events" in Infusion terms
[19:30:32 CST(-0600)] <thealphanerd> there is also the strategy of auto generated bindings vs direct implementation
[19:30:50 CST(-0600)] <colinclark> Something that Flocking synths will listen to, and events will fire when messages are received
[19:30:51 CST(-0600)] <colinclark> a
[19:30:59 CST(-0600)] <colinclark> and vice versa for outbound messages
[19:31:51 CST(-0600)] <thealphanerd> but how much of the binding should be directly written… and how much should be automagically generated based on the interface model
[19:32:33 CST(-0600)] <colinclark> That part, we'll just have to try out and see
[19:32:52 CST(-0600)] <colinclark> hopefully we can make everything happen completely easily and "automagically"
[19:32:53 CST(-0600)] <thealphanerd> I guess the question becomes what we are looking to control
[19:33:02 CST(-0600)] <colinclark> but still keep everything nicely separate and reusable
[19:33:08 CST(-0600)] <thealphanerd> and if we are displaying in the browser… what are we displaying
[19:33:12 CST(-0600)] <thealphanerd> and how is it being displayed
[19:33:21 CST(-0600)] <colinclark> I think the low-level mechanics are pretty straightforward
[19:33:32 CST(-0600)] <colinclark> and we can see how people have used OSC for communicating with the SuperCollider server
[19:33:37 CST(-0600)] <colinclark> and use that for our very basic use cases
[19:33:40 CST(-0600)] <thealphanerd> BUT
[19:33:43 CST(-0600)] <thealphanerd> we have a major difference
[19:33:57 CST(-0600)] <colinclark> we do?
[19:34:00 CST(-0600)] <thealphanerd> where in a language like super collider the osc implementation is inside the langauge
[19:34:16 CST(-0600)] <thealphanerd> where as with flocking we are leveraging an exterior library
[19:34:23 CST(-0600)] <colinclark> yes, that's true
[19:34:36 CST(-0600)] <thealphanerd> the most simple solution is to just have flocking.osc
[19:34:42 CST(-0600)] <colinclark> but as far as Flocking is concerned, there will ultimately only be events
[19:34:50 CST(-0600)] <thealphanerd> flocking.osc = require("node-osc")
[19:35:05 CST(-0600)] <thealphanerd> but the complex part is connceting the dots
[19:35:08 CST(-0600)] <thealphanerd> as you were just saying
[19:35:19 CST(-0600)] <colinclark> yes, exactyl
[19:35:26 CST(-0600)] <thealphanerd> which really leads me to believe that the solution is in model based generation
[19:35:28 CST(-0600)] <colinclark> and then, better yet, layering it all so that it's insanely easy
[19:35:40 CST(-0600)] <colinclark> Ultimately, we want someone to, say, be able to plug in their Monome
[19:35:45 CST(-0600)] <colinclark> Start a synth
[19:35:50 CST(-0600)] <colinclark> and start pressing buttons and have it sound awesome
[19:37:09 CST(-0600)] <thealphanerd> did I show you node blocks?
[19:37:16 CST(-0600)] <colinclark> i forget
[19:39:00 CST(-0600)] <thealphanerd> project that a buddy is working on for the monome
[19:39:01 CST(-0600)] <thealphanerd> in node
[19:39:20 CST(-0600)] <thealphanerd> registers virtual blocks… that store the current state of a monome
[19:39:27 CST(-0600)] <thealphanerd> and emulate the entire osc communication protocol
[19:40:04 CST(-0600)] <thealphanerd> so there are a couple ways of thinking about connecting the two
[19:40:16 CST(-0600)] <thealphanerd> one where by you program your synth specifically to talk to the monome api
[19:41:03 CST(-0600)] <colinclark> oh yes
[19:41:07 CST(-0600)] <colinclark> cool
[19:41:11 CST(-0600)] <colinclark> I'll take a look at it
[19:41:13 CST(-0600)] <thealphanerd> another where you write a generic api to breakout the controllable functions (such as sliders, keyboard, pot), and then write bindings in node blocks
[19:41:21 CST(-0600)] <thealphanerd> and yet another.. which I like the best
[19:41:37 CST(-0600)] <colinclark> I think that's one of the really hard problems--making it insanely easy to make a synth and then bind it to your instrument
[19:41:49 CST(-0600)] <thealphanerd> where by you write an generic api to break out control… and then have a similar translation that can create the monome bindings based on the same model
[19:41:59 CST(-0600)] <thealphanerd> I think the solution is this middle ground
[19:42:03 CST(-0600)] <colinclark> I even found it really tedious to, when I was testing a new synth I wrote, to just hook it up to a few controls on my MS-20 controller and have it all work without having to write tons of lines of code
[19:42:07 CST(-0600)] <thealphanerd> where you write bindings for your instruments
[19:42:16 CST(-0600)] <colinclark> that'll be really interesting
[19:42:17 CST(-0600)] <thealphanerd> and bindings for your synth defs
[19:42:24 CST(-0600)] <thealphanerd> and then just connec the dots
[19:42:30 CST(-0600)] <thealphanerd> this is an idea I've been playing with for a really long time
[19:42:43 CST(-0600)] <colinclark> i'm excited--this will be really cool
[19:42:44 CST(-0600)] <thealphanerd> so in the end node-blocks and flocking could break down to the same basic api
[19:42:54 CST(-0600)] <colinclark> ok, got to run
[19:42:57 CST(-0600)] <thealphanerd> with some conductor app to connect them
[19:42:57 CST(-0600)] <colinclark> darcie's waiting for me
[19:43:00 CST(-0600)] <thealphanerd> no prob
[19:43:02 CST(-0600)] <thealphanerd> have a good one
[19:43:05 CST(-0600)] <colinclark> you too
[19:43:08 CST(-0600)] <colinclark> enjoy class
[19:43:08 CST(-0600)] <thealphanerd> let me know if you want to skype soon
[19:43:15 CST(-0600)] <colinclark> i'm free whenever you are
[19:43:16 CST(-0600)] <colinclark> just let me know
[19:43:20 CST(-0600)] <thealphanerd> I think the model generated method might be the best
[19:43:43 CST(-0600)] <colinclark> it definitely seems promising, yes