fluid-tech IRC Logs-2013-08-06

[08:33:13 CDT(-0500)] <nanook_> colinclark!

[08:33:18 CDT(-0500)] <colinclark> Hey!

[08:33:20 CDT(-0500)] <colinclark> How's it going?

[08:33:35 CDT(-0500)] <nanook_> good! will you be free a little later today?

[08:33:39 CDT(-0500)] <colinclark> yup, I'll be around

[08:33:57 CDT(-0500)] <nanook_> cool. wanted to talk to you about a few things

[08:34:01 CDT(-0500)] <nanook_> how was your weekend?

[08:34:17 CDT(-0500)] <colinclark> It was really good

[08:34:22 CDT(-0500)] <colinclark> Very relaxing

[08:34:28 CDT(-0500)] <colinclark> Got some sailing done, as well as some Flocking

[08:34:36 CDT(-0500)] <nanook_> sweeet

[08:35:53 CDT(-0500)] <colinclark> I've hugely simplified the way that nodes are evaluated in Flocking

[08:36:02 CDT(-0500)] <colinclark> and I think squeezed out some additional performance

[08:36:05 CDT(-0500)] <colinclark> and shaken out a number of bugs

[08:37:42 CDT(-0500)] <colinclark> this should be the last of the infrastructural pieces before finishing the declarative Scheduler

[08:38:38 CDT(-0500)] <nanook_> oh nice. I saw some strange crashes while using the synths. wanted to talk to you about that.

[08:39:11 CDT(-0500)] <nanook_> I should be able to put any JS object into a modelComponent's model right?

[08:41:04 CDT(-0500)] <nanook_> https://github.com/roshanvid/flocking-playground/blob/master/js/app.js#L86-L89

[08:42:14 CDT(-0500)] <nanook_> If I do: that.applier.requestChange("synths."+ name, synth, "ADD"); , chrome crashes.

[08:42:45 CDT(-0500)] <nanook_> Have you seen anything like this happen before?

[08:46:49 CDT(-0500)] <colinclark> Crashes in Chrome, by chance, nanook_?

[08:47:13 CDT(-0500)] <nanook_> nope, happens all the time.

[08:47:15 CDT(-0500)] <nanook_> firefox too

[08:48:31 CDT(-0500)] <colinclark> Fascinating. A hard crash?

[08:49:06 CDT(-0500)] <nanook_> Yup

[08:49:52 CDT(-0500)] <nanook_> no crash dump. nothing. i can't use the console

[08:50:04 CDT(-0500)] <colinclark> What do I need to do to see it in action myself?

[08:51:48 CDT(-0500)] <nanook_> I'll put it on my server and send you a link a little later.

[08:51:59 CDT(-0500)] <nanook_> About to go out for a run now.

[08:54:27 CDT(-0500)] <colinclark> ok, thanks

[13:43:30 CDT(-0500)] <colinclark> nanook: What you're doing, I think makes sense

[13:43:35 CDT(-0500)] <colinclark> but we might be able to do even better

[13:43:51 CDT(-0500)] <colinclark> If you think about it, a SynthDef represents a kind of model for a synth

[13:43:53 CDT(-0500)] <nanook_> what do you think i should do?

[13:44:04 CDT(-0500)] <nanook_> sure..

[13:44:06 CDT(-0500)] <colinclark> I'll just think aloud here, and we'll see if it makes sense

[13:44:23 CDT(-0500)] <colinclark> So a SynthDef describes the synth's nodes and their values

[13:44:39 CDT(-0500)] <colinclark> specifically, it describes a collection of unit generators that are part of the synth

[13:44:48 CDT(-0500)] <nanook_> hold on. let me just show you some code so you know whats happening

[13:44:57 CDT(-0500)] <colinclark> from there, you can dynamically modify a Synth by calling .get() and set()

[13:44:57 CDT(-0500)] <colinclark> sure, nanook

[13:45:24 CDT(-0500)] <nanook_> https://github.com/roshanvid/flocking-playground/blob/master/js/app.js#L8

[13:46:03 CDT(-0500)] <nanook_> playground.synths is meant to handle all the synths - instantiating, adding, remove etc

[13:46:11 CDT(-0500)] <nanook_> https://github.com/roshanvid/flocking-playground/blob/master/js/codewindow.js#L44

[13:46:21 CDT(-0500)] <nanook_> this is where the synthDef's persist

[13:46:26 CDT(-0500)] <nanook_> as files in the codewindow

[13:47:34 CDT(-0500)] <colinclark> So in the "files" object

[13:47:38 CDT(-0500)] <nanook_> Since I couldn't add the synths to the model, I'm just throwing them into some object for now

[13:47:45 CDT(-0500)] <colinclark> does that store Strings or Objects?

[13:47:45 CDT(-0500)] <nanook_> https://github.com/roshanvid/flocking-playground/blob/master/js/app.js#L90

[13:48:18 CDT(-0500)] <nanook_> Ahh.. it Stores CodeMirror.Doc objects I think

[13:48:30 CDT(-0500)] <colinclark> ok

[13:48:38 CDT(-0500)] <nanook_> I'm parsing the JSON only in playground.synths

[13:48:44 CDT(-0500)] <colinclark> ok, so this is exciting, we just need to think it through

[13:49:04 CDT(-0500)] <colinclark> So let's go through a best case scenariuo

[13:49:06 CDT(-0500)] <nanook_> yup. i just realized that might not be a great thing to do

[13:49:09 CDT(-0500)] <colinclark> scenario

[13:49:10 CDT(-0500)] <nanook_> sure

[13:49:14 CDT(-0500)] <colinclark> So, I'm using the playground

[13:49:18 CDT(-0500)] <colinclark> and I make a new synth

[13:49:32 CDT(-0500)]

[13:49:34 CDT(-0500)] <colinclark> and I hit play

[13:49:54 CDT(-0500)] <colinclark> that causes the following things to happen, I think

[13:50:06 CDT(-0500)] <colinclark> 1. You parse the contents of my synth code window into an Object

[13:50:12 CDT(-0500)] <nanook_> right

[13:50:14 CDT(-0500)] <nanook_> go on

[13:50:22 CDT(-0500)] <colinclark> 2. You instantiate a new Synth with that object as its SynthDef

[13:50:46 CDT(-0500)] <colinclark> 3. That process implicitly adds the new synth to the Flocking environment, and it starts playing when the environment does

[13:50:46 CDT(-0500)] <nanook_> yup

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

[13:51:10 CDT(-0500)] <colinclark> So, now there are two scenarios in which I might change that synth

[13:51:13 CDT(-0500)] <nanook_> there's another issue i was facing with this.. but go on. we can come back to that later

[13:51:17 CDT(-0500)] <colinclark> ok

[13:51:27 CDT(-0500)] <colinclark> let's say I want to change the frequency

[13:51:34 CDT(-0500)] <colinclark> a. I could attach a knob to my synth, and turn the knob

[13:52:00 CDT(-0500)]

[13:52:06 CDT(-0500)] <colinclark> Two different things happen in these two cases

[13:52:43 CDT(-0500)] <nanook_> yup. they're completely different

[13:52:54 CDT(-0500)] <colinclark> I'm assuming that in case a), you end up firing an event which causes a call like someSynth.set("freq", 880)

[13:52:59 CDT(-0500)] <colinclark> is that correct?

[13:53:04 CDT(-0500)] <nanook_> so In the first case, I use the set method on the synth

[13:53:08 CDT(-0500)] <nanook_> yup

[13:53:11 CDT(-0500)] <colinclark> right, cool

[13:53:28 CDT(-0500)] <colinclark> so in the second case, you blast away the old synth, and then go through steps 1-3 that we listed above again

[13:53:31 CDT(-0500)] <colinclark> is that right?

[13:53:33 CDT(-0500)] <nanook_> this won't reflect back the frequency change in the code window though

[13:53:49 CDT(-0500)] <colinclark> right

[13:53:51 CDT(-0500)] <colinclark> that makes sense

[13:53:54 CDT(-0500)] <nanook_> but I thought that was okay, since what the code window has is the synthDef right?

[13:54:01 CDT(-0500)] <nanook_> like just the definition

[13:54:02 CDT(-0500)] <colinclark> yup, perhaps

[13:54:12 CDT(-0500)] <colinclark> I was imagining that it might be a future feature

[13:54:27 CDT(-0500)] <colinclark> but as I think about it, I wonder if we could architect this so it was actually simpler AND these things would be kept in sync

[13:54:56 CDT(-0500)] <colinclark> I have this terrible fear that I'm missing something about what happens when a SynthDef gets "parsed" into a full tree of unit generators

[13:54:58 CDT(-0500)] <colinclark> but if I am, it's probably a bug I just need to fix

[13:55:08 CDT(-0500)] <colinclark> So, here's what I'm thinking, and we'll see if it makes sense

[13:55:10 CDT(-0500)] <nanook_> and that's where saving the synthDef as an object would help - so we could just write it back to the code window when we want

[13:55:14 CDT(-0500)] <colinclark> yup

[13:55:26 CDT(-0500)] <nanook_> cool. I hadn't thought about that

[13:55:36 CDT(-0500)] <colinclark> The model of your entire Playground would be a collection of synthDefs

[13:55:52 CDT(-0500)] <colinclark> And any time a change is made to a SynthDef, that causes an event to be fired

[13:56:08 CDT(-0500)] <colinclark> which ultimately fires set() on the appropriate "live synth"

[13:56:26 CDT(-0500)] <colinclark> So for every SynthDef, you've got a "peer" object, which is the running Synth component

[13:56:41 CDT(-0500)] <nanook_> right

[13:56:54 CDT(-0500)] <colinclark> So you could then actually bind your sliders, knobs, and other controllers not to the actual Synth instance, but to the SynthDef from which it was created

[13:57:04 CDT(-0500)] <nanook_> so are you talking about both the cases - assigning a controller, as well as making a code change?

[13:57:12 CDT(-0500)] <colinclark> and then you could even use that to keep the code window in sync, eventually

[13:57:16 CDT(-0500)] <colinclark> yes, that would be the best case

[13:57:21 CDT(-0500)] <colinclark> you don't have to add that latter feature yet

[13:57:21 CDT(-0500)] <nanook_> ah! got it

[13:57:29 CDT(-0500)] <colinclark> but certainly it would be much easier to implement this way

[13:57:44 CDT(-0500)] <colinclark> Bosmon mentioned to me that there aren't a lot of examples or documentation of dynamic components yet

[13:57:49 CDT(-0500)] <colinclark> so I'm going to do some research into them for you

[13:58:01 CDT(-0500)] <colinclark> in the meantime, you could manage your synths using my NodeList object

[13:58:12 CDT(-0500)] <nanook_> cool.

[13:58:21 CDT(-0500)] <colinclark> and then you'll need some binding between a Synth and its SynthDef

[13:58:28 CDT(-0500)] <colinclark> which I believe the Synth already stores

[13:58:33 CDT(-0500)] <colinclark> let me just double check that

[13:58:36 CDT(-0500)] <nanook_> your model makes sense. I think its a good idea to have the synthDef at the center of everything

[13:59:01 CDT(-0500)] <colinclark> yeah, me too

[13:59:07 CDT(-0500)] <colinclark> Again, I might be missing some blazingly obvious limitation

[13:59:14 CDT(-0500)] <colinclark> but if it is there, I will just go ahead and fix it

[13:59:42 CDT(-0500)] <nanook_> colinclark: I'm going to quickly try this out tonight. I'll let you know how it goes

[13:59:49 CDT(-0500)] <colinclark> that makes sense to me

[13:59:51 CDT(-0500)] <colinclark> go for it

[14:00:20 CDT(-0500)] <colinclark> So SynthDefs are your model, and then you'll register ChangeApplier listeners which will make the appropriate set() calls to the "peer" Synth of the SynthDef that changed

[14:01:37 CDT(-0500)] <colinclark> Yeah, Synths hold a reference to their SynthDef as an option

[14:01:46 CDT(-0500)] <nanook_> Yup. and the changes could reflect back into the editor easily

[14:01:49 CDT(-0500)] <colinclark> yes

[14:02:01 CDT(-0500)] <colinclark> so it sounds like we'll want to move the SynthDef for a synth into its model

[14:02:11 CDT(-0500)] <colinclark> perhaps what you end up doing will just go right into the core of Flocking

[14:02:27 CDT(-0500)] <nanook_> ooooh. nice!

[14:02:47 CDT(-0500)] <nanook_> so the other issue i was talking about...

[14:04:17 CDT(-0500)] <nanook_> right after initializing a bunch of synths, when I hit play on a synth, all the synths start to play

[14:12:20 CDT(-0500)] <nanook_> colinclark: is there a global isPlaying and a synth specific isPlaying?