/
fluid-tech IRC Logs-2013-07-23

fluid-tech IRC Logs-2013-07-23

Jul 23, 2013

[10:19:44 CDT(-0500)] <nanook> hey colinclark

[10:19:57 CDT(-0500)] <nanook> sorry about yesterday.. wasn't at my desk

[10:20:23 CDT(-0500)] <colinclark> nanook! Hey!

[10:20:30 CDT(-0500)] <colinclark> No worries, I was just saying hello

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

[10:20:45 CDT(-0500)] <nanook> its going good! got a simple slider working

[10:20:53 CDT(-0500)] <nanook> and playground.connection too

[10:23:03 CDT(-0500)] <nanook> been thinking about how to uniquely identify each controller

[10:23:46 CDT(-0500)] <nanook> and what object to put all the controllers in

[10:28:30 CDT(-0500)] <colinclark> Cool

[10:28:32 CDT(-0500)] <colinclark> glad to hear it

[10:28:43 CDT(-0500)] <colinclark> Tell me more about your last comment… what object to put the controllers in

[10:40:58 CDT(-0500)] <nanook> colinclark: I was talking about holding references to each controller

[10:41:24 CDT(-0500)] <colinclark> To instances of each controller that the user wants on the screen?

[10:41:36 CDT(-0500)] <nanook> so something like playground.controllers["someID"]

[10:42:19 CDT(-0500)] <nanook> yes.. to instances of each controller on the screen

[10:43:11 CDT(-0500)] <colinclark> I think you could use the new dynamic components feature of Infusion to handle that quite nicely

[10:43:22 CDT(-0500)] <colinclark> If Bosmon is around later, we should ask him about it

[10:43:35 CDT(-0500)] <nanook> ooh. interesting

[14:40:15 CDT(-0500)] <yzen> Bosmon:

[14:40:30 CDT(-0500)] <yzen> Bosmon: how valid is this test case ? http://pastie.org/8168415 should i expect this to work ?

[15:18:11 CDT(-0500)] <Bosmon> yzen - looks fine to me

[15:36:31 CDT(-0500)] <Bosmon> yzen - so it seems that "expandBound" which operates for each concrete component member should do the work of resolving references

[15:36:36 CDT(-0500)] <Bosmon> If it doesn't, something else odd is happening

[15:37:07 CDT(-0500)] <Bosmon> There certainly seems to be plenty of processing in that method for "fetchEL"

[15:37:15 CDT(-0500)] <Bosmon> And that should operate for those members of UISelect in your test case

[15:37:40 CDT(-0500)] <yzen> Bosmon: afaik it only happens for decorators and args of the message keys

[15:38:34 CDT(-0500)] <yzen> Bosmon: if there aren't any, it will treat the value as EL

[15:39:22 CDT(-0500)] <Bosmon> Well, on line 527 of RendererUtilities.js it dispatches to "expandBound" for every member of the UISelect

[15:39:34 CDT(-0500)] <Bosmon> Everything which is found in the "map"

[15:39:49 CDT(-0500)] <Bosmon> yzen ^

[15:43:17 CDT(-0500)] <yzen> yes but expand bound will not expand it

[15:43:25 CDT(-0500)] <yzen> Bosmon: ^

[15:44:22 CDT(-0500)] <Bosmon> yzen - well, why not?

[15:44:34 CDT(-0500)] <Bosmon> var EL = typeof (value) === "string" ? fetchEL(value) : null;

[15:44:38 CDT(-0500)] <Bosmon> This line would appear to try

[15:46:44 CDT(-0500)] <yzen> Bosmon: yes but it fails

[15:49:24 CDT(-0500)] <Bosmon> yzen - ok

[15:49:31 CDT(-0500)] <Bosmon> It would be good to have an explanation as to why

[15:49:41 CDT(-0500)] <Bosmon> And if we were to fix the problem, this would be the site we would fix it

[15:50:15 CDT(-0500)] <yzen> Bosmon: what suggestions do you have? i can try? should i fluid.expand it instead ?

[15:50:19 CDT(-0500)] <yzen> like expand light

[15:50:55 CDT(-0500)] <Bosmon> yzen - well, try to understand why it fails first

[15:51:12 CDT(-0500)] <yzen> yes of course

[15:54:35 CDT(-0500)] <Bosmon> Possibly it is caused by the use of "extractELWithContext"

[15:54:44 CDT(-0500)] <Bosmon> In which case the inclusion of an extra level of ${} would resolve the problem

[15:55:11 CDT(-0500)] <Bosmon> This is probably wise, since we don't want to be punished through being unable to render strings that begin with {

[15:55:42 CDT(-0500)] <Bosmon> yzen ^

[15:56:27 CDT(-0500)] <yzen> Bosmon: so you think wrapping it with ${} might work ?

[15:58:35 CDT(-0500)] <Bosmon> I believe so

[15:58:41 CDT(-0500)] <yzen> ok

[16:40:43 CDT(-0500)] <nanook_> hey colinclark

[16:40:49 CDT(-0500)] <colinclark> hey!

[16:41:07 CDT(-0500)] <nanook_> apart from namedNodes, do you keep track of eval-ed synths anywhere else?

[16:42:16 CDT(-0500)] <colinclark> not currently, no

[16:42:19 CDT(-0500)] <colinclark> well, no

[16:42:22 CDT(-0500)] <colinclark> that's not true

[16:43:47 CDT(-0500)] <nanook_> colinclark: thing is, i want to have synths play/pause independently but calling pause() removes the synth from namedNodes

[16:44:35 CDT(-0500)] <colinclark> hmm

[16:44:40 CDT(-0500)] <colinclark> let me have a look at that, one second

[16:45:46 CDT(-0500)] <colinclark> Okay, so you're right

[16:46:11 CDT(-0500)] <nanook_> perhaps i need to add a mute() method

[16:46:17 CDT(-0500)] <colinclark> "Pausing" a synth really just removes the synth from the environment's node graph

[16:46:35 CDT(-0500)] <colinclark> which makes sense, in that you don't want to pay the cost of pull samples from a synth if it won't make sound

[16:46:57 CDT(-0500)] <colinclark> How are you asking users to specify their synths?

[16:47:33 CDT(-0500)] <nanook_> I'm just using the variable names right now

[16:47:35 CDT(-0500)] <colinclark> It seems to me that you might want to keep track of synths as part of the Playground

[16:47:55 CDT(-0500)] <colinclark> since you know when a synth is going to be created

[16:48:18 CDT(-0500)] <colinclark> does that seem reasonable?

[16:49:17 CDT(-0500)] <nanook_> I'll have to make some assumptions about the synths then

[16:50:35 CDT(-0500)] <nanook_> - one synth per file, and the filename will be the identifier

[16:53:12 CDT(-0500)] <colinclark> ah, yes

[16:53:28 CDT(-0500)] <colinclark> this is one of the reasons I was thinking that perhaps we want to limit synth definition to only JSON, rather than code

[16:53:51 CDT(-0500)] <colinclark> if you get a big block of JSON, you'll be able to know exactly what synths are being created

[16:55:40 CDT(-0500)] <colinclark> There's a downside to the approach

[16:55:54 CDT(-0500)] <colinclark> if someone wants to write some code to then manipulate a synth, they have to do it somewhere else

[16:56:04 CDT(-0500)] <colinclark> say, to schedule some events to play it

[16:56:04 CDT(-0500)] <Bosmon> colinclark - noone wants to write code

[16:56:09 CDT(-0500)] <Bosmon> This is the CENTURY OF THE FRUITBATT, after all

[16:56:20 CDT(-0500)] <nanook_> was just about to say that

[16:56:21 CDT(-0500)] <colinclark> you are very weird Bosmon

[16:56:22 CDT(-0500)] <colinclark>

[16:56:24 CDT(-0500)] <colinclark> we will get there

[16:56:34 CDT(-0500)] <colinclark> but until the declarative scheduler is in place, they HAVE to write code

[16:56:35 CDT(-0500)] <nanook_> like the polyphonic synth stuff

[16:57:16 CDT(-0500)] <colinclark> So, what we could do for now is to have some kind of separation between defining a synth or set of synths and then playing it

[16:57:25 CDT(-0500)] <colinclark> I'm hard at work on the new Scheduler

[16:57:41 CDT(-0500)] <colinclark> but I just need some time when I'm not writing reports or arguing with Spaniards

[16:57:53 CDT(-0500)] <colinclark> right, Dr. Fruitbat?

[16:58:05 CDT(-0500)] <Bosmon> "That was, in fact, the previous century, Archchancellor"

[16:58:19 CDT(-0500)] <nanook_> Hahah

[16:58:22 CDT(-0500)] <colinclark> but I think it's pretty clear that defining synths should just be done by writing some JSON

[16:58:37 CDT(-0500)] <colinclark> playing them, on the other hand, will still, temporarily, have to involve writing some code

[16:58:42 CDT(-0500)] <colinclark> I'm pretty close, though

[16:58:44 CDT(-0500)] <Bosmon> Well sure

[16:58:51 CDT(-0500)] <Bosmon> Everything, temporarily, involves writing some code

[16:58:54 CDT(-0500)] <colinclark>

[16:59:28 CDT(-0500)] <colinclark> nanook_: what do you think of this crazy half-Fruitbat idea?

[16:59:29 CDT(-0500)] <nanook_> colinclark: "some kind of separation between defining a synth or set of synths and then playing it"

[16:59:36 CDT(-0500)] <nanook_> i don't understand that completely

[17:00:11 CDT(-0500)] <colinclark> Well, presumably you'd have some "synth" window, where a user could write plain old JSON

[17:00:20 CDT(-0500)] <colinclark> representing a set of synths that they'd like to define

[17:00:42 CDT(-0500)] <colinclark> they'd give them names so that others could explore what they'd done, etc.

[17:00:55 CDT(-0500)] <colinclark> and then you'd be able to take that JSON and create Infusion components with it

[17:01:02 CDT(-0500)] <colinclark> that represent "all the synths currently playing"

[17:02:02 CDT(-0500)] <nanook_> ahh.. ok. so i'll be creating the components myself

[17:02:14 CDT(-0500)] <colinclark> yup, you as The Playground

[17:02:25 CDT(-0500)] <nanook_> what they'll be giving me essentially is the synthDef

[17:02:29 CDT(-0500)] <colinclark> yes, exactly

[17:03:12 CDT(-0500)] <nanook_> also, evolving random code is kinda scary

[17:03:19 CDT(-0500)] <nanook_> err eval-ing

[17:03:54 CDT(-0500)] <colinclark> yes

[17:03:56 CDT(-0500)] <colinclark> exactly

[17:04:05 CDT(-0500)] <colinclark> especially when someone else wrote it, and you want to try it out

[17:04:20 CDT(-0500)] <colinclark> in the model where the Playground is a kind of community for sharing instruments

[17:04:44 CDT(-0500)] <colinclark> In that case, we essentially can't have people submitting arbitrary code

[17:22:41 CDT(-0500)] <colinclark> is this seeming generally reasonable, nanook_?

[17:23:25 CDT(-0500)] <nanook_> colinclark: yup! this works

[17:23:29 CDT(-0500)] <nanook_> i was just trying it out

[17:23:32 CDT(-0500)] <colinclark> cool, that's awesome

[17:23:35 CDT(-0500)] <colinclark> sorry to distract you

[17:23:36 CDT(-0500)] <colinclark>

[17:24:28 CDT(-0500)] <nanook_> no no. thats alright.

[17:24:38 CDT(-0500)] <nanook_> was talking to thealphanerd on the other channel too

[17:24:44 CDT(-0500)] <nanook_>