[07:11:00 CDT(-0500)] <tokran> hello this is Eric from the TU Dresden

[07:15:12 CDT(-0500)] <boyan> Hi Eric, and welcome to the channel!

[09:17:35 CDT(-0500)] <michelled> cindyli: did you say you had a branch you wanted me to look at?

[09:18:20 CDT(-0500)] <cindyli> michelled: should be ready soon. The big icon issue is fixed. but i noticed when text size is maximized, the icon overlaps with the checkbox besides it. looking into that.

[09:21:01 CDT(-0500)] <michelled> thx cindyli

[09:21:09 CDT(-0500)] <cindyli> np

[09:25:26 CDT(-0500)] <michelled> anastasiac, cindyli: a11y-uio is updated to master. Also, I think we can start closing JIRAs now. If an issue is fixed on the a11y-uio staging site, then lets close it.

[09:25:52 CDT(-0500)] <anastasiac> ok, michelleld

[09:30:03 CDT(-0500)] <anastasiac> michelled, what if the issue is fixed in the a11y-uio branch, but not yet on the a11y-uio staging site?

[09:30:20 CDT(-0500)] <michelled> anastasiac: leave it open until we see it on the staging site

[09:30:46 CDT(-0500)] <michelled> anastasiac: I don't know how Andrey has set it up - we might need to ask him to update staging from time to time

[09:30:50 CDT(-0500)] <anastasiac> k. If it's on the staging site, maybe we should remove it from the iteration page too, michelled?

[09:31:46 CDT(-0500)] <michelled> anastasiac: if that makes it easier it's fine. The only reason I leave the issues on there for the week is for the sense of accomplishment

[09:31:58 CDT(-0500)] <michelled> I think it's good for transparency too

[09:32:02 CDT(-0500)] <anastasiac> ok

[09:32:23 CDT(-0500)] <cindyli> michelled: the branch for FLOE-63 is ready for review: https://github.com/cindyli/OER-Commons/tree/FLOE-63

[09:32:29 CDT(-0500)] <michelled> thx cindyli

[09:32:33 CDT(-0500)] <cindyli> np

[09:58:18 CDT(-0500)] <cindyli> jameswy and jvass, i wanna clarify the table of contents mentioned in this jira: http://issues.fluidproject.org/browse/FLOE-76

[09:58:38 CDT(-0500)] <cindyli> it's the TOC in the authoring edit and preview page, right?

[10:01:56 CDT(-0500)] <michelled> cindyli: I can clarify that - we talked about it in person

[10:02:06 CDT(-0500)] <michelled> it's not the authoring toc

[10:02:06 CDT(-0500)] <cindyli> that's great, michelled

[10:02:26 CDT(-0500)] <cindyli> so, UIO toc?

[10:02:28 CDT(-0500)] <michelled> it's the TOC that you see everywhere else when you set the TOC option to on in UIO

[10:02:34 CDT(-0500)] <cindyli> ok, got you

[10:04:01 CDT(-0500)] <michelled> cindyli: FLOE-63 looks good

[10:04:13 CDT(-0500)] <michelled> cindyli: there is one more place where the arrow is an issue though

[10:04:22 CDT(-0500)] <cindyli> ok, where?

[10:04:23 CDT(-0500)] <michelled> it's the pull down beside the logged in user name at the top

[10:04:34 CDT(-0500)] <cindyli> ah. ok

[10:05:18 CDT(-0500)] <michelled> anastasiac: I'm seeing some real issues with the authoring steps in IE8 - the layout is broken and hovering is horrible

[10:05:31 CDT(-0500)] <anastasiac> oh, that's not good

[10:05:41 CDT(-0500)] <michelled> anastasiac: I know you worked on the steps before - could you take a look at it after you're done what you are working on?

[10:05:57 CDT(-0500)] <anastasiac> will do - could you file a JIRA?

[10:06:45 CDT(-0500)] <michelled> sure

[10:11:31 CDT(-0500)] <cindyli> michelled, anastasiac, i also noticed the broken layout when i was testing with IE8, but seems it was caused by the shifting of the title field. Fixing that might fix the layout issue. but michelled might noticed other things that cause the layout falls apart.

[10:12:07 CDT(-0500)] <anastasiac> ok

[10:12:47 CDT(-0500)] <cindyli> this is the related jira, anastasiac: http://issues.fluidproject.org/browse/FLOE-61

[10:12:57 CDT(-0500)] <anastasiac> thanks, cindyli

[10:13:00 CDT(-0500)] <cindyli> np

[10:15:56 CDT(-0500)] <michelled> anastasiac: I opened this one because it seems slightly different than what cindyli saw: http://issues.fluidproject.org/browse/FLOE-77

[10:17:10 CDT(-0500)] <anastasiac> ok, I've linked the two in JIRA, just in case

[10:19:55 CDT(-0500)] <michelled> cindyli: for FLOE-76 - the background should not fill the whole width of the screen - it should just surround the actual TOC

[10:20:19 CDT(-0500)] <cindyli> ok. thanks, michelled

[10:23:45 CDT(-0500)] <michelled> np

[10:34:56 CDT(-0500)] <avtar> fluid-everyone: i'm on a call with nebula so here's my standup/connections update. currently working on two issues with nebula engineers, 1. the authentication service is not responding to requests and 2. only one of the controllers' ip addresses is being returned from their dns service. we had to ship their management laptop to them last week so i might have to be at the data centre to manually retrieve info for troubleshooting purpos

[10:34:57 CDT(-0500)] <avtar> also, i was using this tool http://theforeman.org to provision machines in the smaller cluster in a vm, hoping to have enough time after the nebula tasks to set foreman up on a dedicated, physical host at 100 mccaul

[10:51:39 CDT(-0500)] <anastasiac> cindyli, regarding the 'steps' icons in IE8, did you see the same problem that michelled sees (she put a screenshot on FLOE-77)

[10:51:58 CDT(-0500)] <cindyli> trying, anastasiac

[10:53:32 CDT(-0500)] <cindyli> interesting, i don't see it, anastasiac

[10:53:57 CDT(-0500)] <anastasiac> ok, cindyli, thanks. I don't either, so maybe michelled's setup is the problem

[10:54:09 CDT(-0500)] <michelled> anastasiac, cindyli: can you update to the latest a11y-uio just in case there's something that recently got committed?

[10:54:09 CDT(-0500)] <anastasiac> cindyli, do the icons actually work for you?

[10:54:29 CDT(-0500)] <cindyli> anastasiac: you mean by clicking them or the hover styling

[10:54:37 CDT(-0500)] <anastasiac> clicking to go to another step

[10:54:38 CDT(-0500)] <cindyli> the hover styling is a icon switch

[10:55:02 CDT(-0500)] <cindyli> no, clicking doesn't take me to another step

[10:55:16 CDT(-0500)] <anastasiac> ok, well, that's a bug

[10:55:36 CDT(-0500)] <anastasiac> doesn't work in IE9, either

[10:55:41 CDT(-0500)] <anastasiac> ok, I'm on it

[13:03:17 CDT(-0500)] <cindyli> michelled: the fix for user profile icons is ready to review: https://github.com/cindyli/OER-Commons/tree/FLOE-63

[13:03:35 CDT(-0500)] <michelled> thx cin

[13:18:34 CDT(-0500)] <Justin_o> yura1: for a fluid.render.condition expander can do you know if i can use a function for the condition, and if so what arguments does it pass I'm?

[13:18:39 CDT(-0500)] <Justin_o> in

[13:21:46 CDT(-0500)] <yura1> Justin_o: you would specify your own args

[13:21:59 CDT(-0500)] <Justin_o> yura1: do you have an example of it?

[13:22:17 CDT(-0500)] <yura1> YA ONE SEC

[13:22:22 CDT(-0500)] <yura1> ya one sec :

[13:22:22 CDT(-0500)] <Justin_o> thanks

[13:24:24 CDT(-0500)] <yura1> https://github.com/collectionspace/ui/blob/master/src/main/webapp/defaults/js/CreateTemplateBox.js#L107-113

[13:24:27 CDT(-0500)] <yura1> Justin_o: ^

[13:25:06 CDT(-0500)] <Justin_o> yura1: thanks.. that's pretty straightforward

[13:25:31 CDT(-0500)] <yura1> np

[13:47:17 CDT(-0500)] <jhung1> justin_o: I have pushed up changes to decapod-ui to my bitbucket repo.

[13:48:36 CDT(-0500)] <Justin_o> jhung: thanks.. i have a bunch of changes in mine as well.. have you pulled those down yet?

[13:48:44 CDT(-0500)] <Justin_o> made a bunch today

[13:48:59 CDT(-0500)] <jhung> yep. I pulled and merged those justin_o

[13:49:11 CDT(-0500)] <Justin_o> jhung: excellent, thanks

[14:43:27 CDT(-0500)] <jhung> justin_o: it doesn't look like the user needs to hold the calibration pattern. Therefore it can lay flat - this also means no more timer!

[14:44:17 CDT(-0500)] <Justin_o> jhung: oh that's good

[14:44:21 CDT(-0500)] <Justin_o> should simplify things

[14:44:28 CDT(-0500)] <jhung> yep.

[15:05:10 CDT(-0500)] <Justin_o> jhung: pulled in your changes and pushed them up to my repo

[15:05:37 CDT(-0500)] <jhung> great justin_o

[17:33:47 CDT(-0500)] <colinclark> Bosmon: I should expect failing Image Reorderer tests until your fix for FLUID-4736 is in, right?

[17:38:13 CDT(-0500)] <Bosmon> yes

[17:46:14 CDT(-0500)] <colinclark> Bosmon: This FLUID-4711 change to visitComponentChildren() seems to echo the same style of issue were discussing on Skype today in regards to trundlers

[17:46:41 CDT(-0500)] <colinclark> It seems, rather than being directional, that it is now all path-based

[17:50:09 CDT(-0500)] <Bosmon> Yes, that's right

[17:50:18 CDT(-0500)] <Bosmon> It is a kind of "anticipatory refactoring"

[18:02:17 CDT(-0500)] <colinclark> Bosmon: Do we have any examples in the wild of other implementations of a path composer?

[18:02:32 CDT(-0500)] <colinclark> I see in the code today it looks like fluid.composePath() pretty much the sole strategy

[18:03:40 CDT(-0500)] <colinclark> Hey thealphanerd, let me know if you need a hand with your ARIA and/or polyphony work at all

[18:03:50 CDT(-0500)] <colinclark> despite having to bail on our meeting, I'm happy to help if you get stuck on anything

[18:05:13 CDT(-0500)] <thealphanerd> colinclark: no problem

[18:05:16 CDT(-0500)] <thealphanerd> will definitely need the help

[18:05:22 CDT(-0500)] <thealphanerd> I'm going to be off the map until monday

[18:05:26 CDT(-0500)] <thealphanerd> but then its nose to the screen

[18:05:34 CDT(-0500)] <colinclark> Where are you off to for the long weekend?

[18:05:40 CDT(-0500)] <thealphanerd> Electric Eclectics

[18:05:40 CDT(-0500)] <thealphanerd>

[18:05:42 CDT(-0500)] <thealphanerd> you coming

[18:05:43 CDT(-0500)] <thealphanerd> ?

[18:05:43 CDT(-0500)] <colinclark> oh right!

[18:05:45 CDT(-0500)] <colinclark> Can't

[18:05:48 CDT(-0500)] <thealphanerd> pfft

[18:05:51 CDT(-0500)] <colinclark> Darcie took the car

[18:05:53 CDT(-0500)] <thealphanerd>

[18:05:58 CDT(-0500)] <thealphanerd> I know some people going

[18:06:08 CDT(-0500)] <thealphanerd> but you would probably have to go for the entire weekend if you hitched a ride with them

[18:06:17 CDT(-0500)] <colinclark> yeah, I have to stick around and look after this cat

[18:06:17 CDT(-0500)] <thealphanerd> I'd offer but we are leaving early and going to muskoka

[18:06:23 CDT(-0500)] <thealphanerd> is the cat ok?

[18:06:24 CDT(-0500)] <colinclark> no worries

[18:06:27 CDT(-0500)] <colinclark> Tell me how it goes

[18:06:28 CDT(-0500)] <thealphanerd> sounded like a semi emergency

[18:06:34 CDT(-0500)] <colinclark> No, it wasn't

[18:06:42 CDT(-0500)] <colinclark> Just not fully planned out because of Darcie's canoe trip

[18:07:02 CDT(-0500)] <colinclark> He's got cancer, but he's been sticking it out pretty good for a while

[18:07:12 CDT(-0500)] <colinclark> he just needs shots every few weeks

[18:08:02 CDT(-0500)] <colinclark> Hey, thealphanerd, if you get a chance at some point, can you check your Windows 7 version of Firefox?

[18:08:23 CDT(-0500)] <colinclark> Best as I can tell, I was running an older version--Firefox 13, which contained the bug that was causing the "unresponsive script" dialog to pop up

[18:08:48 CDT(-0500)] <thealphanerd> I have tested

[18:08:48 CDT(-0500)] <colinclark> When I upgraded to Firefox 14, I could no longer see it happening with either the AMMM or any of my Flocking demos and compositions

[18:08:53 CDT(-0500)] <thealphanerd> unresponsive script is gone afaik

[18:08:59 CDT(-0500)] <colinclark> that's a relief

[18:08:59 CDT(-0500)] <thealphanerd> but latency is suck

[18:09:03 CDT(-0500)] <colinclark> yeah

[18:09:20 CDT(-0500)] <thealphanerd> btw Julius Smith says that he is impressed by the piano

[18:09:25 CDT(-0500)] <colinclark> nice!

[18:09:26 CDT(-0500)] <thealphanerd> never expected such small latency in browser

[18:09:27 CDT(-0500)] <thealphanerd>

[18:09:29 CDT(-0500)] <colinclark> lol

[18:09:33 CDT(-0500)] <colinclark> I'm deeply flattered

[18:09:42 CDT(-0500)] <thealphanerd>

[18:09:43 CDT(-0500)] <colinclark> as should you be

[18:09:49 CDT(-0500)] <thealphanerd> this has been an amazing experience

[18:09:59 CDT(-0500)] <colinclark> You've been awesome

[18:10:04 CDT(-0500)] <thealphanerd> I just have to start to push myself to get stuff together for the final deadline

[18:10:09 CDT(-0500)] <colinclark> I can wait to see the arpeggiator and polyphony

[18:10:14 CDT(-0500)] <colinclark> can't wait

[18:10:17 CDT(-0500)] <colinclark> can't wait

[18:10:17 CDT(-0500)] <colinclark>

[18:10:35 CDT(-0500)] <colinclark> Let me ask you this question:

[18:10:54 CDT(-0500)] <colinclark> Would it make sense for me to just roll polyphony straight into Flocking while you're away at EE?

[18:11:02 CDT(-0500)] <thealphanerd> ujmmm

[18:11:03 CDT(-0500)] <thealphanerd> yeah

[18:11:04 CDT(-0500)] <thealphanerd>

[18:11:05 CDT(-0500)] <thealphanerd> lol

[18:11:05 CDT(-0500)] <colinclark> Or would you rather try it?

[18:11:07 CDT(-0500)] <colinclark> up to you

[18:11:12 CDT(-0500)] <thealphanerd> implement it if you can

[18:11:15 CDT(-0500)] <colinclark> I was leaving it for you, but I can whip something up this weekend

[18:11:18 CDT(-0500)] <colinclark> okay, will do

[18:11:21 CDT(-0500)] <thealphanerd> truthfully I have so many things I would like to do

[18:11:25 CDT(-0500)] <thealphanerd> that I can fill my time either way

[18:11:33 CDT(-0500)] <colinclark> Filters will have to wait for another weekend

[18:11:40 CDT(-0500)] <colinclark> Sorry Julius

[18:12:22 CDT(-0500)] <colinclark> I'll see how it goes--if you get some progress on ARIA and then on the arpeggiator, things'll get pretty interesting

[18:12:33 CDT(-0500)] <colinclark> and we can maybe give Jennison a call and see if he'd like to try it out then

[18:12:39 CDT(-0500)] <colinclark> Jennison and Johnny, perhaps

[18:18:47 CDT(-0500)] <thealphanerd> definitely

[18:18:53 CDT(-0500)] <thealphanerd> I think the arpeggiator will be pretty easy

[18:18:58 CDT(-0500)] <thealphanerd> a hook or something

[18:19:03 CDT(-0500)] <thealphanerd> on note on

[18:19:24 CDT(-0500)] <thealphanerd> I still feel like I need a lot of guidence for the aria stuff though

[18:19:27 CDT(-0500)] <thealphanerd> unfortunately

[18:20:12 CDT(-0500)] <colinclark> in the end, it's not going to be as hard as you think

[18:20:20 CDT(-0500)] <colinclark> it should go fairly smoothly

[18:20:24 CDT(-0500)] <thealphanerd> I agree

[18:20:29 CDT(-0500)] <thealphanerd> just hard to find good documentation

[18:22:25 CDT(-0500)] <colinclark> I think it's going to be pretty easy

[18:22:39 CDT(-0500)] <colinclark> The hardest part will be to determine what a screen reader user wants to hear when they're also trying to make music

[18:22:46 CDT(-0500)] <colinclark> I just did a quick check of the ARIA documentation, as I said I would

[18:22:56 CDT(-0500)] <colinclark> And, if we want to go with the traditional model, it's really easy

[18:23:07 CDT(-0500)] <colinclark> Just give each of your keys the attribute role="button"

[18:23:11 CDT(-0500)] <thealphanerd> done

[18:23:25 CDT(-0500)] <colinclark> and create another list of labels somewhere, styling it so it's not visible

[18:23:39 CDT(-0500)] <colinclark> I'd probably literally just make a list like this:

[18:23:56 CDT(-0500)] <colinclark> <ol><li>A1</li><li>A#1</li>…</ol>

[18:24:05 CDT(-0500)] <colinclark> Give each of those <li>s an id

[18:24:29 CDT(-0500)] <colinclark> Then give each of your keys another attribute: aria-labelledby="<id of the label>"

[18:24:39 CDT(-0500)] <colinclark> So, then each key on the piano will be a button

[18:24:47 CDT(-0500)] <thealphanerd> in aria land

[18:24:52 CDT(-0500)] <colinclark> and you'll associate it with a separate, invisible label in ARIA land

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

[18:25:10 CDT(-0500)] <thealphanerd> so would the best way to do this be to make a hidden div inside piano?

[18:25:23 CDT(-0500)] <thealphanerd> trailing after the svg?

[18:25:24 CDT(-0500)] <colinclark> And then a screen reader user will be able to focus each key and they will hear, say, "A#4 button"

[18:25:24 CDT(-0500)] <colinclark> Yes, that's probably where I'd put it

[18:25:33 CDT(-0500)] <colinclark> in the main piano container, after the SVG

[18:25:34 CDT(-0500)] <colinclark> yup

[18:25:51 CDT(-0500)] <colinclark> Now, my sense is that this might annoy an AT user--but if you implement this, we can actually test it with a few people

[18:26:02 CDT(-0500)] <colinclark> It might be annoying, because they'd keep hearing the labels while they were playing sound

[18:26:09 CDT(-0500)] <colinclark> let's try it the traditional way and see what people say

[18:26:33 CDT(-0500)] <colinclark> if that doesn't work, we'll simply put a giant aria-describedby attribute on the Piano's main container--the one we're going to put in the tab order

[18:26:45 CDT(-0500)] <colinclark> and create a hidden <div> that contains a full description of the piano

[18:27:20 CDT(-0500)] <colinclark> Something like "This is a piano keyboard, starting with A1 and ending with C200. To navigate it, press the arrow keys to select a note and press Spacebar or Enter to play the sound."

[18:27:23 CDT(-0500)] <colinclark> or whatever

[18:27:34 CDT(-0500)] <colinclark> So, really, it's pretty easy

[18:27:55 CDT(-0500)] <colinclark> then we just have the (hopefully) fairly minor challenge of making each SVG element focusable--but it looks like these things take focus programmatically, which is great

[18:28:28 CDT(-0500)] <thealphanerd> yeah that looked like it wasn't too bad

[18:28:38 CDT(-0500)] <thealphanerd> but it raises a question

[18:28:47 CDT(-0500)] <thealphanerd> as to how to specifically deal with focus with multiple keyboards

[18:28:49 CDT(-0500)] <thealphanerd> ALSO

[18:28:53 CDT(-0500)] <Bosmon> colinclark - there are two path composers

[18:28:57 CDT(-0500)] <thealphanerd> I was thinking about introducing a sustain button

[18:29:10 CDT(-0500)] <Bosmon> There is the one in the core framework which does no escaping, and the slow one in DataBinding.js which we use a lot in GPII

[18:29:17 CDT(-0500)] <colinclark> aha!

[18:29:24 CDT(-0500)] <colinclark> yes, I remember we discussed this

[18:29:37 CDT(-0500)] <Bosmon> For now I am going with the model that no component name can contain a period, since I can't see a great reason why they should

[18:29:45 CDT(-0500)] <colinclark> Yes, I saw that comment

[18:29:50 CDT(-0500)] <colinclark> I think it's a reasonable restriction

[18:29:59 CDT(-0500)] <Bosmon> But if we can unify the two implementations into a single, supersmart one some day, presumably we would want to centralise on that one

[18:30:10 CDT(-0500)] <colinclark> thealphanerd: Some kind of toggle switch that's analogous to a sustain pedal on a synthesizer?

[18:30:19 CDT(-0500)] <Bosmon> I've already forgotten the name of that framework which we saw a regex-based escaper in

[18:30:23 CDT(-0500)] <colinclark> Bosmon: Great

[18:30:28 CDT(-0500)] <Bosmon> Was it handlebars or something like that?

[18:30:46 CDT(-0500)] <colinclark> No, I think it was actually the build tool...

[18:30:47 CDT(-0500)] <colinclark> Grunt?

[18:30:48 CDT(-0500)] <colinclark> yes

[18:31:02 CDT(-0500)] <Bosmon> Oh yes

[18:31:03 CDT(-0500)] <Bosmon> Grunt

[18:31:03 CDT(-0500)] <colinclark> Why is visitComponents private in FluidIoC.js?

[18:31:10 CDT(-0500)] <Bosmon> hah

[18:31:12 CDT(-0500)] <thealphanerd> colinclark: kinda… thinking just something that would disable noteoff

[18:31:22 CDT(-0500)] <Bosmon> Great question, especially since I've just been talking to Travis about private functions

[18:31:26 CDT(-0500)] <colinclark>

[18:31:41 CDT(-0500)] <colinclark> it's pretty trivial, I was just curious since it really does stand out alone

[18:31:49 CDT(-0500)] <thealphanerd> also colinclark I was curious how hard it would be to implement glide?

[18:31:57 CDT(-0500)] <colinclark> thealphanerd: Easy

[18:32:02 CDT(-0500)] <Bosmon> It was such a vague implementation in the early days I was positively ashamed of it

[18:32:09 CDT(-0500)] <colinclark> You stick a flock.ugen.xLine on the frequency

[18:32:17 CDT(-0500)] <Bosmon> What it actually does has already changed several times over the course of the framework

[18:32:38 CDT(-0500)] <Bosmon> Until we had our "yellow squares" scoping diagram, our scoping rules were pretty unclear

[18:32:55 CDT(-0500)] <colinclark> thealphanerd: So instead of directly updating the frequency of your carrier input, you'd update the start and end inputs of an xLine

[18:33:05 CDT(-0500)] <Bosmon> There are a few more private functions in the file too

[18:33:12 CDT(-0500)] <thealphanerd> cool.. I'll experiment with that

[18:33:40 CDT(-0500)] <colinclark> thealphanerd: I'll probably improve that API a bit based on thinking more about the Web Audio API's "audio params"

[18:33:57 CDT(-0500)] <colinclark> but again, I expect that we'll create objects that make these kinds of things invisible to ordinary synth builders

[18:34:08 CDT(-0500)] <colinclark> the UGen abstraction is VERY low level

[18:34:10 CDT(-0500)] <colinclark> but very composable

[18:34:18 CDT(-0500)] <colinclark> having been more or less useful since, what, 1958?

[18:34:38 CDT(-0500)] <colinclark> Bosmon: yes, and they seem to alternate between the various styles of defining functions

[18:34:52 CDT(-0500)] <colinclark> I enjoyed reading makeGingerStrategy(), Bosmon

[18:35:09 CDT(-0500)] <colinclark> And then reading the old Spring ticket you filed in 2006

[18:35:21 CDT(-0500)] <Bosmon> hahaha

[18:35:26 CDT(-0500)] <colinclark> and then seeing the error message "Please reorganise your dependencies so that they no longer contain circular references"

[18:37:57 CDT(-0500)] <colinclark> thealphanerd: Here's what Julius says about the history: https://ccrma.stanford.edu/~jos/kna/Historical_View_Synthesizer_Development.html

[18:38:54 CDT(-0500)] <colinclark> thankfully, unlike Max Mathews, we can use a bit more descriptive input names than P1, P2, P3…

[18:39:01 CDT(-0500)] <colinclark> Amazingly, CSound programmers still work this way

[18:40:18 CDT(-0500)] <thealphanerd> interesting

[18:40:45 CDT(-0500)] <colinclark> "Apparently, Music V was born at least three decades too soon to be accepted as the PostScript of the music world. Instead, we got MIDI (Musical Instrument Digital Interface)."

[18:40:54 CDT(-0500)] <colinclark> Julius seems a bit disappointed

[18:41:28 CDT(-0500)] <thealphanerd> colinclark: have you made many npm modules?

[18:41:35 CDT(-0500)] <colinclark> I have not

[18:41:45 CDT(-0500)] <colinclark> but I'm fairly certain Bosmon and yura have

[18:41:47 CDT(-0500)] <colinclark> For Infusion

[18:43:06 CDT(-0500)] <Bosmon> thealphanerd - yes, we have a basic "node driver" for Infusion

[18:43:18 CDT(-0500)] <Bosmon> It isn't in npm yet, since we are still debating our release strategy

[18:43:24 CDT(-0500)] <thealphanerd> how does namspacing work nicely with exports?

[18:43:31 CDT(-0500)] <Bosmon> A really excellent question

[18:43:38 CDT(-0500)] <Bosmon> Let me just finish this call I'm on and I'll explain

[18:43:43 CDT(-0500)] <colinclark> lol

[18:43:47 CDT(-0500)] <Bosmon> But we have made a thing called "fluid.require"

[18:45:03 CDT(-0500)] <thealphanerd> now would it be easy to use infusion / fluid.require as a template to make infusion based npm modules?

[18:45:35 CDT(-0500)] <thealphanerd> colinclark / Bosmon: phortran is a wizard buddy of mine working on his first node app for interfacing with the monome

[18:45:52 CDT(-0500)] <phortran> hey guys

[18:45:53 CDT(-0500)] <colinclark> cool

[18:45:54 CDT(-0500)] <thealphanerd> we're trying to figure out how to properly set stuff up while remaining true to thatism / namespace

[18:45:58 CDT(-0500)] <colinclark> hi phortran

[18:46:06 CDT(-0500)] <phortran> thanks for taking the time to help out

[18:46:08 CDT(-0500)] <Bosmon> thealphanerd - what an awesome endeavour

[18:46:10 CDT(-0500)] <phortran> pretty new to this stuff

[18:46:12 CDT(-0500)] <thealphanerd> colinclark: phortran is the original author of pages… one of the best monomes out there

[18:46:26 CDT(-0500)] <phortran> aww shucks

[18:46:32 CDT(-0500)] <thealphanerd> https://github.com/dinchak/node-serialosc

[18:46:36 CDT(-0500)] <thealphanerd> this is where we are so far

[18:46:58 CDT(-0500)] <colinclark> Bosmon: This is a monome, by the way: http://monome.org/here/12-256-1.jpg

[18:47:12 CDT(-0500)] <thealphanerd> oh new monome

[18:47:13 CDT(-0500)] <thealphanerd> mmmm

[18:47:30 CDT(-0500)] <Bosmon> fun

[18:47:33 CDT(-0500)] <thealphanerd> but we want to build this code base modularly enough that we can interface many devices

[18:47:39 CDT(-0500)] <thealphanerd> not just them monome

[18:47:46 CDT(-0500)] <Bosmon> So, the core Fluid value is that "everything has a unique, stable public name"

[18:47:58 CDT(-0500)] <Bosmon> Which is completely at odds with the node/npm packaging idiom

[18:48:02 CDT(-0500)] <colinclark> This is quite a different approach to the node module system

[18:48:03 CDT(-0500)] <colinclark> yes

[18:48:04 CDT(-0500)] <Bosmon> This is why we made fluid.require

[18:49:40 CDT(-0500)] <Bosmon> fluid.require operates a single "context" which consists of the (V8) context object which is used to load the Fluid framework

[18:49:57 CDT(-0500)] <Bosmon> It then exposes fluid.require to all clients, which allows them to load their code into the same context

[18:50:22 CDT(-0500)] <Bosmon> And it of course assumes that everyone follows the standard Fluid guidelines on using properly namespaced, global names to identify their code

[18:51:50 CDT(-0500)] <colinclark> thealphanerd: To clarify, most people wouldn't follow these Fluid guidelines...

[18:52:05 CDT(-0500)] <colinclark> unless they want to use Infusion and especially the IoC features that make such loosely-coupled apps

[18:52:13 CDT(-0500)] <colinclark> like, say, your stuff

[18:52:45 CDT(-0500)] <thealphanerd> well I see a serious advantage to designing this way

[18:53:03 CDT(-0500)] <thealphanerd> and I usehd phortran to start trying to program in a similar way

[18:53:16 CDT(-0500)] <thealphanerd> to find out that the code won't really work in npm

[18:53:17 CDT(-0500)] <thealphanerd> lol

[18:53:59 CDT(-0500)] <colinclark> Bosmon: Can you think of any examples within the GPII code that might be useful to see how it works in action?

[18:54:25 CDT(-0500)] <phortran> lol, luckily sounds like a fairly easy solution, i take it i'm going to need: https://github.com/fluid-project/infusion ?

[18:54:37 CDT(-0500)] <colinclark> yup

[18:54:55 CDT(-0500)] <Bosmon> The node driver file is called fluid.js

[18:54:55 CDT(-0500)] <thealphanerd> phortran: infusion is the framework I've been using for the automagic music maker

[18:54:56 CDT(-0500)] <colinclark> we're not yet publishing it as an NPM module until we cut a stable 1.5 release

[18:56:20 CDT(-0500)] <Bosmon> You can see that it has a standard npm packagine

[18:57:34 CDT(-0500)] <thealphanerd> you can install via npm by pointing to a git repo though can't you

[18:57:52 CDT(-0500)] <colinclark> really? I didn't know that

[18:58:10 CDT(-0500)] <thealphanerd> https://npmjs.org/doc/install.html

[18:58:13 CDT(-0500)] <thealphanerd> you can install tarballs

[18:58:29 CDT(-0500)] <thealphanerd> or git repos

[18:58:48 CDT(-0500)] <thealphanerd> and I think you can specify that in the package.json file too

[18:59:13 CDT(-0500)] <thealphanerd> looks like you can even specifiy specific commits or tags

[19:00:40 CDT(-0500)] <thealphanerd> yup… you can set dependencies as either http://... url's or git… urls (which can point directly to github)

[19:01:33 CDT(-0500)] <colinclark> Bosmon: FLUID-4711 is in

[19:01:47 CDT(-0500)] <colinclark> I also tested it with the options merging fix just to ensure that we've got happy tests

[19:01:54 CDT(-0500)] <colinclark> So I'll move on to that one now

[19:02:30 CDT(-0500)] <phortran> sorry.. phonecall.. i did try installing via npm from the repo but no luck there, but i'll just grab that fluid.js for now

[19:05:16 CDT(-0500)] <thealphanerd> phortran: npm install git://github.com/fluid-project/infusion.git

[19:05:20 CDT(-0500)] <thealphanerd> works for me

[19:05:57 CDT(-0500)] <colinclark> Bosmon: I find myself more compelled to carve out some time to revisit our Builder and build system one of these days

[19:06:20 CDT(-0500)] <colinclark> After having done this whole round of conversations with the team, I'm thinking we need to start the process of planning for that Infusion 1.5 release

[19:06:29 CDT(-0500)] <colinclark> We might not necessarily get to ship it until the fall

[19:06:34 CDT(-0500)] <colinclark> but it seems like it's getting to be time

[19:06:48 CDT(-0500)] <Bosmon> colinclark - thanks so much

[19:06:53 CDT(-0500)] <Bosmon> For 4711

[19:06:57 CDT(-0500)] <colinclark> I don't know how that timeline fits with your plans for framework tasks

[19:06:58 CDT(-0500)] <Bosmon> Yes, a node-based builder will become pretty urgent

[19:08:31 CDT(-0500)] <thealphanerd> colinclark: that reminded me of something

[19:08:39 CDT(-0500)] <thealphanerd> should I implement some sort of build system for automm?

[19:08:56 CDT(-0500)] <thealphanerd> something to compile all the js files and run them through jsmin?

[19:09:11 CDT(-0500)] <phortran> thealphanerd: ah great, i had tried the https url, this one seems to be thinking hard at least

[19:09:17 CDT(-0500)] <phortran> there it goes.. nice

[19:14:34 CDT(-0500)] <thealphanerd> I gotta go for now guys

[19:14:36 CDT(-0500)] <thealphanerd> be back a bit later

[19:14:36 CDT(-0500)] <thealphanerd>

[19:14:40 CDT(-0500)] <thealphanerd> later

[19:18:23 CDT(-0500)] <colinclark> Bosmon: I find myself puzzled about the exact relationship between this "faulty fix" in FLUID-4736 and the issue of additive demands blocks in FLUID-4392

[19:18:32 CDT(-0500)] <colinclark> It's not vital for the review so if you are busy, no worries

[19:18:37 CDT(-0500)] <colinclark> otherwise, I am curious

[19:18:47 CDT(-0500)] <Bosmon> Well, everything connects together in the form of the "new merging algorithm"

[19:19:15 CDT(-0500)] <Bosmon> The main impediment to getting FLUID-4392 isn't so much registering the demands blocks which are to be additive, but figuring out what to do with them when you've got them....

[19:19:32 CDT(-0500)] <Bosmon> This relates to this issue that we need to be able to perform "simultaneous merging and expanding"

[19:19:40 CDT(-0500)] <phortran> got it working, thanks guys!! great work you're doing, take care

[19:19:50 CDT(-0500)] <colinclark> good to hear it, phortran!

[19:19:55 CDT(-0500)] <colinclark> let us know if you need any more help

[19:20:00 CDT(-0500)] <Bosmon> Although I guess it is possible to imagine a kind of "halfway implementation" that still does all expanding first, and all merging afterwards

[19:20:00 CDT(-0500)] <phortran> i appreciate it!

[19:20:39 CDT(-0500)] <colinclark> simultaneous merging and expanding blows my mind somewhat

[19:20:46 CDT(-0500)]

<Bosmon> But things are become extremely cumbersome in our lack of ability to understand what is referred to by "

Unknown macro: {arguments}

" or "

Unknown macro: {options}

" or whatever, in any particular context

[19:20:46 CDT(-0500)] <colinclark> do you have something in mind for the algorithm?

[19:20:56 CDT(-0500)] <Bosmon> KINGG already has a couple of JIRAs open about that where he doesn't get the results he expects

[19:21:07 CDT(-0500)] <colinclark> what sorts of results does he expect?

[19:21:22 CDT(-0500)] <Bosmon> Which are mainly a result of the very sloppy "ad hoc" bookkeeping in the system about where exactly it is up to in the merging/expanding process

[19:22:09 CDT(-0500)] <Bosmon> http://issues.fluidproject.org/browse/FLUID-4144

[19:22:11 CDT(-0500)] <Bosmon> Here is one of his JIRAs

[19:22:28 CDT(-0500)] <Bosmon> Oddly this looks like JURA made it

[19:22:54 CDT(-0500)] <Bosmon> Ok, here is the KING's one

[19:22:54 CDT(-0500)] <Bosmon> http://issues.fluidproject.org/browse/FLUID-4631

[19:23:02 CDT(-0500)] <Bosmon> So you can see we have a whole fistful of these things breeding

[19:23:10 CDT(-0500)] <Bosmon> There is another one from KING too somewhere

[19:25:01 CDT(-0500)] <Bosmon> So I guess I'd prefer to resolve all of these issues simultaneously

[19:25:14 CDT(-0500)] <Bosmon> Since dealing with any of them will involve touching all of the options merging/expansion pipeline

[19:27:55 CDT(-0500)] <colinclark> let me just make sure I understand these

[19:33:33 CDT(-0500)] <colinclark> As I follow the network of JIRA relationships, I'm starting to see some of my questions unfold

[19:33:46 CDT(-0500)] <colinclark> you do a nice job of relating issues

[21:54:38 CDT(-0500)] <thealphanerd> hey colinclark you still around?

[21:56:21 CDT(-0500)] <colinclark> hyup

[21:58:47 CDT(-0500)] <colinclark> what's up, thealphanerd?

[21:59:14 CDT(-0500)] <thealphanerd> so I was looking at some of the node code that uses infusion

[21:59:31 CDT(-0500)] <thealphanerd> https://github.com/fluid-project/node-jqUnit/blob/master/lib/jqUnit.js

[21:59:33 CDT(-0500)] <thealphanerd> like that

[21:59:35 CDT(-0500)] <thealphanerd> for example

[21:59:41 CDT(-0500)] <thealphanerd> and there are no closures being used

[22:00:28 CDT(-0500)] <thealphanerd> is it unneccessary to use anonymous functions when working with node?

[22:00:37 CDT(-0500)] <colinclark> well, it's less critical in a modularized world, yes

[22:00:50 CDT(-0500)] <colinclark> there isn't the same risk of leakage out into the global object

[22:01:20 CDT(-0500)] <thealphanerd> does each module have its own global object?

[22:01:25 CDT(-0500)] <colinclark> So I think you'll find that code that is designed to run in both places-in the browser and in Node.js-will still use the anonymous closure

[22:01:37 CDT(-0500)] <colinclark> And Node.js-specific code will often omit it for convenience

[22:01:57 CDT(-0500)] <colinclark> thealphanerd: I guess you can think about it as if each module has its own global

[22:02:06 CDT(-0500)] <thealphanerd> ok cool

[22:02:15 CDT(-0500)] <thealphanerd> now another thing I was curious about

[22:02:30 CDT(-0500)] <thealphanerd> components in node land

[22:02:36 CDT(-0500)] <thealphanerd> is it done the same way?

[22:02:57 CDT(-0500)] <colinclark> Infusion components? Yup

[22:03:08 CDT(-0500)] <thealphanerd> just need ot require infusion

[22:03:19 CDT(-0500)] <colinclark> yeah, I think that's about it

[22:03:25 CDT(-0500)] <thealphanerd> cool cool col

[22:03:27 CDT(-0500)] <thealphanerd> NOW

[22:03:29 CDT(-0500)] <thealphanerd> few more

[22:03:30 CDT(-0500)] <thealphanerd>

[22:03:43 CDT(-0500)] <thealphanerd> since each module is claiming to have its own "global"

[22:03:53 CDT(-0500)] <thealphanerd> would you be able to create a namespacee in a module

[22:04:00 CDT(-0500)] <thealphanerd> and have other modules append or modify that namespace?

[22:04:17 CDT(-0500)] <colinclark> yeah, that's the point of fluid.require()

[22:04:24 CDT(-0500)] <thealphanerd> coool

[22:04:32 CDT(-0500)] <colinclark> is to preserve the semantics of a single, global hierarchy of names

[22:04:54 CDT(-0500)] <colinclark> Meaning you can use EL paths and the like

[22:05:02 CDT(-0500)] <colinclark> and have the framework be able to locate your components accordingly

[22:05:10 CDT(-0500)] <thealphanerd> which is f'n cool

[22:05:22 CDT(-0500)] <thealphanerd> this would then lead to the last question

[22:05:26 CDT(-0500)] <colinclark> indeed

[22:05:35 CDT(-0500)] <thealphanerd> how does one make a component with a flexible component tree

[22:05:45 CDT(-0500)] <colinclark> what do you mean?

[22:05:53 CDT(-0500)] <thealphanerd> well lets say that we are workign on pages

[22:05:58 CDT(-0500)] <thealphanerd> which is a device aggregator

[22:06:13 CDT(-0500)] <thealphanerd> so we'll have the serialosc module

[22:06:19 CDT(-0500)] <thealphanerd> which can be used to poll mdns stuff

[22:06:38 CDT(-0500)] <thealphanerd> but it will also register / deregister monomes as they appear on the network

[22:06:54 CDT(-0500)] <thealphanerd> and arc

[22:06:56 CDT(-0500)] <thealphanerd> and other devices

[22:07:09 CDT(-0500)] <thealphanerd> so when instantiated it should have no instances… and it should be flexible

[22:07:16 CDT(-0500)] <thealphanerd> or in the case of another project with sensors

[22:07:32 CDT(-0500)] <thealphanerd> the main component needs to scan the i2c bus to find what sensors are attached

[22:07:41 CDT(-0500)] <thealphanerd> and create a component tree based on that information

[22:07:59 CDT(-0500)] <Bosmon> THat's pretty awesome

[22:08:10 CDT(-0500)] <Bosmon> I've always wanted an i2c-to-component tree transducer

[22:08:21 CDT(-0500)] <thealphanerd> its what I'm working on right now

[22:08:26 CDT(-0500)] <thealphanerd> actually was working on it earlier today when we were chatting

[22:08:33 CDT(-0500)] <thealphanerd> with the raspi

[22:09:02 CDT(-0500)] <thealphanerd> got gps working over uart.. and dumping json files into node with the module bancroft

[22:09:05 CDT(-0500)] <colinclark>

[22:09:32 CDT(-0500)] <colinclark> i am barely keeping up with you guys

[22:09:35 CDT(-0500)] <thealphanerd> but so ideally you would have bottom level components for each sensor that would take care of polling the sensors and keeping an updated model

[22:09:54 CDT(-0500)] <colinclark> i think i'm still stuck in 1958 with max mathews

[22:10:16 CDT(-0500)] <thealphanerd> and then a higher level component that would poll all the sensors syncronously

[22:10:33 CDT(-0500)] <thealphanerd> but that higher level component would need to determine its component tree based on an i2c scan

[22:11:20 CDT(-0500)] <Bosmon> thealphanerd - the repetition structures in the rendere are a bit cranky, but they are usable

[22:11:22 CDT(-0500)] <thealphanerd> Bosmon: the other guys I'm working with are hacking the attiny to make any analog sensor into an i2c slave

[22:11:36 CDT(-0500)] <Bosmon> Probably yura is the one who has worked with them the most intensively, but also Justin_o has done a lot

[22:11:53 CDT(-0500)] <Bosmon> They're not really the way we want in the end, but they can be made to work and do what you want to do

[22:11:53 CDT(-0500)] <colinclark> I guess in this case, Bosmon, we're probably not rendering anything

[22:12:07 CDT(-0500)] <Bosmon> colinclark - how could he building a component tree, if he is not wanting to render anything?

[22:12:17 CDT(-0500)] <thealphanerd> Bosmon: it is all happening in node land

[22:12:24 CDT(-0500)] <thealphanerd> everything dumping into a model

[22:12:28 CDT(-0500)] <Bosmon> Well, sure... but surely there is some visible output of this : P

[22:12:35 CDT(-0500)] <thealphanerd> not in the node app

[22:12:46 CDT(-0500)] <Bosmon> But again yura is a good person to chat to

[22:12:49 CDT(-0500)] <colinclark> I think when thealphanerd says "component tree" he means a composition of components that has been assembled via IoC

[22:12:52 CDT(-0500)] <thealphanerd> the node app will have a restful api to get the json's

[22:13:00 CDT(-0500)] <thealphanerd> colinclark: exactly

[22:13:01 CDT(-0500)] <Bosmon> Since he has been working most closely on our "Infusion on express" node model

[22:13:06 CDT(-0500)] <Bosmon> Formerly known as KETTLE

[22:13:15 CDT(-0500)] <thealphanerd> ohhh la la

[22:13:21 CDT(-0500)] <thealphanerd> infusion on express

[22:13:21 CDT(-0500)] <colinclark> It sounds like he wants to have a component dynamically instantiate new components based on on the state of these various buses

[22:13:27 CDT(-0500)] <thealphanerd> exactly

[22:13:35 CDT(-0500)] <thealphanerd> colinclark: this could be useful in browser too though

[22:13:46 CDT(-0500)] <thealphanerd> you can have a bank of potential subcomponents

[22:14:13 CDT(-0500)] <thealphanerd> and part of the model would dictate what subcomponents are present

[22:15:38 CDT(-0500)] <Bosmon> thealphanerd - this is an interesting area

[22:15:43 CDT(-0500)] <Bosmon> Once that we haven't fully explored yet

[22:15:57 CDT(-0500)] <Bosmon> But there are clearly a lot of cases where "automatically generated component material" will be highly useful

[22:16:03 CDT(-0500)] <Bosmon> We are already running into a lot of this with our UIOptions component

[22:16:05 CDT(-0500)] <thealphanerd> indeed

[22:16:26 CDT(-0500)] <Bosmon> But the idea is that you would use the Model Transformations system which we just committed, to define a set of rules which transform your model into component configuration material

[22:16:28 CDT(-0500)] <thealphanerd> but also the ability to create / destroy an instance of a component

[22:16:32 CDT(-0500)] <Bosmon> Which you then go forward to instantiate

[22:18:25 CDT(-0500)] <thealphanerd> Bosmon: in regards to the i2c project. Do you have much experience with i2c? Have you used it with node?

[22:18:26 CDT(-0500)] <colinclark> thealphanerd: I can show you model transformation one of these days

[22:19:01 CDT(-0500)] <colinclark> it will now do a nice job of adapting the different "views" of your model between your Oscillator component and your Piano component… that'd give you a taste of how it works

[22:19:25 CDT(-0500)] <Bosmon> thealphanerd - never used it with node, no

[22:19:26 CDT(-0500)] <thealphanerd> fluid.model.transform.merge ???

[22:19:30 CDT(-0500)] <thealphanerd> what kind of merge is that?

[22:19:32 CDT(-0500)] <colinclark> and then you can start to imagine how you'd be able to transform the model of the bus state into a different type of model that represented the options to create a new component

[22:19:42 CDT(-0500)] <Bosmon> I have used it in a physical project

[22:20:09 CDT(-0500)] <thealphanerd> colinclark: that sounds really interesting.

[22:20:12 CDT(-0500)] <colinclark> does fluid.model.transform.merge even still exist?

[22:20:20 CDT(-0500)] <thealphanerd> Bosmon: there is no npm package as far as I can tell

[22:20:24 CDT(-0500)] <thealphanerd> http://wiki.fluidproject.org/display/docs/fluid.model.transformWithRules

[22:20:30 CDT(-0500)] <thealphanerd> under transformation expanders

[22:20:38 CDT(-0500)] <Bosmon> Those docs are incredibly old

[22:20:41 CDT(-0500)] <Bosmon> You will have to ignore them

[22:20:50 CDT(-0500)] <Bosmon> We have committed a completely new implementation of transformation last month

[22:20:54 CDT(-0500)] <colinclark>

[22:20:58 CDT(-0500)] <Bosmon> For which, sadly, you will largely have to read the source code

[22:20:58 CDT(-0500)] <colinclark> A much better one, I will say

[22:21:07 CDT(-0500)] <Bosmon> and the TEST CASES!

[22:21:33 CDT(-0500)] <thealphanerd> the tests will have lots of good stuff

[22:21:46 CDT(-0500)] <colinclark> I suspect that these docs will still largely work, if we updated "path" to "inputPath"

[22:21:47 CDT(-0500)] <thealphanerd> phortran already wrote a bunch of tests for that serialosc module

[22:21:48 CDT(-0500)] <Bosmon> https://github.com/fluid-project/infusion/blob/master/src/webapp/tests/framework-tests/core/js/ModelTransformationsTests.js

[22:21:51 CDT(-0500)] <Bosmon> Here, read these

[22:21:54 CDT(-0500)] <thealphanerd> https://github.com/dinchak/node-serialosc/blob/master/test/tests.js

[22:22:08 CDT(-0500)] <Bosmon> Helpfully, the test cases use the model transformation system itself, to transform test cases into other test cases

[22:22:37 CDT(-0500)] <Bosmon> The JSON block beginning at line 51 is a declarative specification of a set of test cases for the model transformation system

[22:22:44 CDT(-0500)] <Bosmon> Which, consisting of JSON, can be transformed into other forms

[22:23:57 CDT(-0500)] <colinclark> Here's a very simple example of a transformation rule set: https://github.com/GPII/universal/blob/master/gpii/node_modules/flowManager/test/data/solutions.reporter.payload.example.json#L118-133

[22:24:39 CDT(-0500)] <colinclark> And a presentation about Model Transformation here: http://wiki.fluidproject.org/download/attachments/1707985/Model+Transformations.ppt

[22:24:56 CDT(-0500)] <colinclark> We're getting into pretty subtle stuff, with no pre-made examples of the sort of thing you want to do, thealphanerd

[22:24:58 CDT(-0500)] <Bosmon> Oh yes, I forgot about the presentation

[22:25:00 CDT(-0500)] <colinclark> so it probably will take some time

[22:25:10 CDT(-0500)] <Bosmon> That's probably the only thing in the way of docs that we have

[22:25:23 CDT(-0500)] <colinclark> I'll teach you the basic whenever you've got some time--transforming the structure of one model into another

[22:25:31 CDT(-0500)] <Bosmon> Still, ALEXEY seemed to consider that a bunch of slides was sufficient to explain the principles behind IoC : P

[22:25:47 CDT(-0500)] <thealphanerd> colinclark: in the example above

[22:25:51 CDT(-0500)] <thealphanerd> what model is it transforming?

[22:26:01 CDT(-0500)] <thealphanerd> do you have a link to the defaults?

[22:26:45 CDT(-0500)] <Bosmon> What could be more straightforward than feline: {

[22:26:45 CDT(-0500)] <Bosmon> expander: {

[22:26:45 CDT(-0500)] <Bosmon> type: "fluid.model.transform.value",

[22:26:45 CDT(-0500)] <Bosmon> inputPath: "cat"

[22:26:45 CDT(-0500)] <Bosmon> }

[22:26:45 CDT(-0500)] <Bosmon> }

[22:26:48 CDT(-0500)] <Bosmon> : P

[22:26:50 CDT(-0500)] <colinclark> lol

[22:26:51 CDT(-0500)] <colinclark> erm

[22:26:53 CDT(-0500)] <colinclark> yes

[22:26:58 CDT(-0500)] <colinclark> thealphanerd: The best way to see that example is probably to look at the slides

[22:27:15 CDT(-0500)] <colinclark> I think we have a series of before and after slides

[22:27:23 CDT(-0500)] <Bosmon> You might like the testcase at line 795, since it is more conventionally readable

[22:27:41 CDT(-0500)] <Bosmon> The model it operates on is at line 23

[22:27:44 CDT(-0500)] <Bosmon> var source = { ....

[22:28:00 CDT(-0500)] <Bosmon> And its expected output is at line 858

[22:28:53 CDT(-0500)] <thealphanerd> farm animals?

[22:28:57 CDT(-0500)] <Bosmon> Yes, those

[22:29:09 CDT(-0500)] <colinclark> thealphanerd: When we play around with ModelTransformation a bit, you'll actually see that your "paramMap" in oscillator.js is very similar… only backwards. https://github.com/TheAlphaNerd/Piano/blob/master/js/oscillator.js#L48-55

[22:29:09 CDT(-0500)] <thealphanerd> I don't know how I feel about expanding a kangaroo

[22:29:10 CDT(-0500)] <Bosmon> If you consider a CATTT to be a kind of FARM ANIMAL

[22:29:23 CDT(-0500)] <Bosmon> My father grew up on a farm that had lots of CATTs

[22:29:24 CDT(-0500)] <colinclark> cats definitely count

[22:29:33 CDT(-0500)] <Bosmon> But they just happened to be there

[22:29:40 CDT(-0500)] <colinclark> i thought it was even, at some point, referred to as a "barn.cat"

[22:29:41 CDT(-0500)] <Bosmon> THey weren't specifically being farmed : P

[22:29:47 CDT(-0500)] <colinclark> lol

[22:29:51 CDT(-0500)] <Bosmon> barn.cat rather than farm.goat?

[22:30:03 CDT(-0500)] <Bosmon> Oh yes

[22:30:06 CDT(-0500)] <Bosmon> barn.cat is still there

[22:30:08 CDT(-0500)] <Bosmon> Line 897

[22:30:18 CDT(-0500)] <Bosmon> It takes the first CATT that it comes across

[22:30:29 CDT(-0500)] <Bosmon> Whether it is a barn cat or an ordinary CATTT

[22:30:34 CDT(-0500)] <colinclark> I imagine that cats, by their very nature, are fairly resilient to being farmed

[22:30:39 CDT(-0500)] <Bosmon> And unilaterally decides that it must be a barn.cat after all

[22:31:22 CDT(-0500)] <thealphanerd> didn't milk them?

[22:31:22 CDT(-0500)] <Bosmon> Later on your farm.cat takes the option of having 2 lots of bowl.fish....

[22:31:28 CDT(-0500)] <thealphanerd> farm.cat.mil()

[22:31:34 CDT(-0500)] <colinclark> thealphanerd: If you flipped your paramMap around, it would be a transformation rule set

[22:31:43 CDT(-0500)] <Bosmon> "components.fish.options.quantity": "numFish"

[22:31:49 CDT(-0500)] <thealphanerd> well lets be honest here

[22:31:53 CDT(-0500)] <thealphanerd> that's your paramMap

[22:31:58 CDT(-0500)] <colinclark> and now that Flocking supports setting multiple input values at once, you can literally take one model, transformation, and set it as the value to another component

[22:32:12 CDT(-0500)] <colinclark> well, I was going somewhere with it

[22:32:15 CDT(-0500)] <thealphanerd> can I just send it a model of the changes I want done?

[22:32:28 CDT(-0500)] <Bosmon> That's sort of what a transformation map is

[22:32:39 CDT(-0500)] <thealphanerd> so an object

[22:32:40 CDT(-0500)] <thealphanerd> {}

[22:32:41 CDT(-0500)] <Bosmon> Although the convention is that it "starts from nothing"

[22:32:48 CDT(-0500)] <colinclark> yeah, you give fluid.model.transform(): 1. your model and 2. your transform rules

[22:32:51 CDT(-0500)] <colinclark> and it gives you a new model back

[22:32:55 CDT(-0500)] <Bosmon> So you don't have to worry about how to make things "go away" that you want to go missing from your model

[22:33:04 CDT(-0500)] <colinclark> and the rules represent, as you say, a kind of model of the changes you want

[22:33:05 CDT(-0500)] <Bosmon> It builds up a new model, piece by piece, based on your old model

[22:33:10 CDT(-0500)] <thealphanerd> this is like crockfords options

[22:33:16 CDT(-0500)] <colinclark> models everywhere

[22:33:33 CDT(-0500)] <thealphanerd> do you have to set a default model differently than normal?

[22:33:43 CDT(-0500)] <colinclark> a default model?

[22:33:55 CDT(-0500)] <Bosmon> Well, to be clear, in our component setup, the thing we call the "model" is just a subset of the overall options

[22:34:10 CDT(-0500)] <Bosmon> And on the other hand, the thing we call "model transformations" can transform things other than models

[22:34:11 CDT(-0500)] <colinclark> but one that means something particular

[22:34:22 CDT(-0500)] <Bosmon> It's just a set of looser, or stricter uses of the same term

[22:34:31 CDT(-0500)] <Bosmon> "model transformations" can transform any body of JSON-like material to any other body

[22:34:48 CDT(-0500)] <colinclark> I guess, today, it could probably transform almost any non-thatist object

[22:34:51 CDT(-0500)] <Bosmon> The thing we call the "model" of a component is a particular piece of its options configuration that is "even more model-like", if that makes any sense

[22:35:02 CDT(-0500)] <colinclark> with expectations not unlike fluid.copy()

[22:35:05 CDT(-0500)] <Bosmon> In particular, we imagine its value changing over the lifetime of the component

[22:35:14 CDT(-0500)] <Bosmon> The rest of its options we imagine remaining fixed

[22:35:53 CDT(-0500)] <Bosmon> colinclark - surely there are huge bodies of other things we couldn't transform, in addition to that-ist ones

[22:35:56 CDT(-0500)] <Bosmon> For example, this-ist ones : P

[22:36:23 CDT(-0500)] <thealphanerd> colinclark: in terms of changing of adding components

[22:36:32 CDT(-0500)] <Bosmon> Although of course, we could transform them.... we just couldn't "successfully transform" them

[22:36:34 CDT(-0500)] <colinclark> well, I guess you could imagine some kinds of this-is transformations, Bosmon

[22:36:41 CDT(-0500)] <Bosmon> The resulting pile of values and function handlers would be useless

[22:36:49 CDT(-0500)] <colinclark> lol

[22:36:54 CDT(-0500)] <colinclark> thealphanerd: yes, go ahead, sorry

[22:36:58 CDT(-0500)] <thealphanerd> its ok

[22:37:02 CDT(-0500)] <thealphanerd> I'm enjoying listening

[22:37:13 CDT(-0500)] <thealphanerd> but so in the case of an oscillaor

[22:37:21 CDT(-0500)] <thealphanerd> so we have a synth

[22:37:24 CDT(-0500)] <Bosmon> thealphanerd - the key point is that we (you) would transform the CONFIGURATION leading to the components, rather than the components themselves

[22:37:50 CDT(-0500)] <Bosmon> This configuration, before it has been instantiated, is definitely "model-like" material

[22:37:53 CDT(-0500)] <thealphanerd> then you would need to refresh though right?

[22:38:10 CDT(-0500)] <Bosmon> Well, you might refresh... or you might just throw away everything and reinstantiate it again

[22:38:21 CDT(-0500)] <thealphanerd> but in the case of audio

[22:38:23 CDT(-0500)] <thealphanerd> you can't just throw it away

[22:38:24 CDT(-0500)] <Bosmon> There's no reason why your code shouldn't be "stateless" as well as your REST endpoints : P

[22:38:36 CDT(-0500)] <Bosmon> What stops it?

[22:39:00 CDT(-0500)] <Bosmon> I guess I'm not too familiar with the way flocking is set up

[22:39:08 CDT(-0500)] <Bosmon> Especially since it doesn't instantiate "components" in the Infusion sense

[22:39:10 CDT(-0500)] <thealphanerd> this is where I was going… so colin, how could I go about adding or removing new synths without having to restart flocking

[22:39:19 CDT(-0500)] <thealphanerd> Bosmon: fari enough

[22:39:25 CDT(-0500)] <Bosmon> But I imagine there is some kind of "hole" you can throw configuration down in order to get it honoured in terms of becoming an implementation

[22:39:28 CDT(-0500)] <thealphanerd> Bosmon: have you ever written bindings for c++ before?

[22:39:36 CDT(-0500)] <Bosmon> thealphanerd - sadly, yes

[22:39:47 CDT(-0500)] <colinclark> sorry, i'm catching up

[22:39:50 CDT(-0500)] <Bosmon> It isn't a very happy thing to do

[22:39:55 CDT(-0500)] <colinclark> i was putting in some coffee beans to roast

[22:40:02 CDT(-0500)] <thealphanerd> colinclark: roasting… fancy

[22:40:10 CDT(-0500)] <colinclark> adding or removing synths

[22:40:29 CDT(-0500)] <colinclark> So we talked about the "environment" being this still-slightly fuzzy object representing the sound system

[22:40:47 CDT(-0500)] <colinclark> and that it has an array of "nodes"--typically synths

[22:40:49 CDT(-0500)] <thealphanerd> Bosmon: in regards to c++ bindings… I am worried I might have to implement something to get i2c working on node

[22:41:00 CDT(-0500)] <colinclark> the environment has a set of methods you can use to add and remove synths

[22:41:02 CDT(-0500)] <Bosmon> thealphanerd - the npm package isn't up to it?

[22:41:11 CDT(-0500)] <thealphanerd> Bosmon: there is no npm package

[22:41:23 CDT(-0500)] <thealphanerd> colinclark: can you add / remove nodes like a linked list?

[22:41:25 CDT(-0500)] <colinclark> By default, unless you configure it otherwise, a synth is automatically added to the head of the environment's node list when you instantiate one

[22:41:27 CDT(-0500)] <Bosmon> Isn't it just a matter of slinging stuff over a serial bus and getting it back again?

[22:41:34 CDT(-0500)] <Bosmon> I heard you talking about the uart earlier

[22:41:34 CDT(-0500)] <colinclark> It's not a linked list

[22:41:36 CDT(-0500)] <colinclark> just an array

[22:41:44 CDT(-0500)] <thealphanerd> could it be a linked list?

[22:41:50 CDT(-0500)] <colinclark> you can literally use the familiar Array methods

[22:42:01 CDT(-0500)] <thealphanerd> so it can behave like a linked list?

[22:42:03 CDT(-0500)] <colinclark> or a few convenience methods on flock.evnviro

[22:42:09 CDT(-0500)] <colinclark> Well, I don't think it needs to be linked

[22:42:14 CDT(-0500)] <Bosmon> What's all this about a linked list

[22:42:21 CDT(-0500)] <thealphanerd> wellll… I was thinking about ableton

[22:42:25 CDT(-0500)] <colinclark> One synth shouldn't have a dependency on another

[22:42:28 CDT(-0500)] <thealphanerd> and moving tracks around

[22:42:41 CDT(-0500)] <colinclark> they're just there--and their order in the environment's node list determines how they are evaluated

[22:42:45 CDT(-0500)] <Bosmon> JavaScript Array is well-blessed with operations for moving things around

[22:42:48 CDT(-0500)] <Bosmon> As colinclark mentioned

[22:42:54 CDT(-0500)] <thealphanerd> I guess I was thinking in a effects chain

[22:42:57 CDT(-0500)] <Bosmon> But it doesn't need to be a linked list in order to enjoy these : P

[22:43:08 CDT(-0500)] <thealphanerd> where when you move where something is in the chain it changes the effect

[22:43:22 CDT(-0500)] <colinclark> thealphanerd: you should be able to do some pretty powerful effects chains just by moving synths around in the node list

[22:43:36 CDT(-0500)] <colinclark> remember that there are also "buses," which synths can read from and write to

[22:43:49 CDT(-0500)] <thealphanerd> that could be used for delays

[22:43:49 CDT(-0500)] <colinclark> giving them a fairly loosely-coupled way to pass samples around

[22:44:04 CDT(-0500)] <colinclark> so the environment's node list doesn't involve signals passing in sequence, necessarily

[22:44:17 CDT(-0500)] <colinclark> it's just an order by which the nodes should be told to generate their samples

[22:44:23 CDT(-0500)] <colinclark> their samples may get written to a bus

[22:44:28 CDT(-0500)] <colinclark> and then read to by another synth

[22:44:39 CDT(-0500)] <colinclark> Does that make sense?

[22:44:43 CDT(-0500)] <thealphanerd> it does

[22:44:48 CDT(-0500)] <colinclark> There's one very small, horrifying caveat

[22:44:53 CDT(-0500)] <thealphanerd> how you can do am or fm synthesis

[22:44:57 CDT(-0500)] <colinclark> I haven't implemented the bus reader

[22:45:04 CDT(-0500)] <colinclark> But that will come in a day or two

[22:45:14 CDT(-0500)] <Bosmon> The blessings of a Bachelor Weekend

[22:45:20 CDT(-0500)] <thealphanerd> a simple fm synth would be wicked

[22:45:23 CDT(-0500)] <Bosmon> You will do it, CATT to CATTT

[22:45:24 CDT(-0500)] <colinclark> lol

[22:45:25 CDT(-0500)] <colinclark> "blessings"

[22:45:34 CDT(-0500)] <colinclark> Well, AM and FM synth likely happens at the UGen level

[22:45:39 CDT(-0500)] <colinclark> rather than amongst synths

[22:45:47 CDT(-0500)] <colinclark> Though it's still possible there, too

[22:45:54 CDT(-0500)] <colinclark> So for AM synth, here's an example...

[22:46:07 CDT(-0500)] <colinclark> http://www.flockingjs.org/demos/latest-revision/demos/interactive/html/playground.html

[22:46:30 CDT(-0500)] <colinclark> You can see that the "mul" input is being modulated by another UGen

[22:46:31 CDT(-0500)] <Bosmon> wow!

[22:46:33 CDT(-0500)] <Bosmon> It actually runs!

[22:46:35 CDT(-0500)] <thealphanerd> oh yeah

[22:46:57 CDT(-0500)] <colinclark> Frequence modulation is there too

[22:47:03 CDT(-0500)] <thealphanerd> indeed it is

[22:47:05 CDT(-0500)] <thealphanerd> its all coming back to me

[22:47:08 CDT(-0500)] <colinclark> Bosmon: It's working for you on FF Windows?!?

[22:47:11 CDT(-0500)] <Bosmon> Slightly buzzy sinewave

[22:47:14 CDT(-0500)] <Bosmon> I ran it in Chrome

[22:47:22 CDT(-0500)] <colinclark> ah

[22:47:31 CDT(-0500)] <colinclark> I've had a few bugs that are fixed in a branch

[22:47:34 CDT(-0500)] <Bosmon> It sort of runs in FF too

[22:47:38 CDT(-0500)] <Bosmon> But is horribly laggy

[22:47:51 CDT(-0500)] <colinclark> Firefox on Windows has some pretty dismal buffer size issues

[22:47:51 CDT(-0500)] <Bosmon> Because of FF's appalling GC implementation

[22:47:54 CDT(-0500)] <colinclark> yes

[22:47:59 CDT(-0500)] <thealphanerd> so colinclark I could have a model transformation to turn on and off things like am and fm synthesis

[22:48:12 CDT(-0500)] <colinclark> Yeah, I guess you could

[22:48:16 CDT(-0500)] <Bosmon> Especially bad since it struggling with a 1.7GB process image again

[22:48:26 CDT(-0500)] <thealphanerd> colinclark: that could be interesting

[22:48:27 CDT(-0500)] <Bosmon> And no doubt numerous ZOMBIE COMPARTMENTs....

[22:48:43 CDT(-0500)] <colinclark> So, Bosmon tell me about your experience in both browsers, just so I know where I'm at?

[22:48:45 CDT(-0500)] <thealphanerd> that could be done for the oscillator type as well

[22:49:00 CDT(-0500)] <Bosmon> colinclark - the basic sound is the same in both browsers, a slightly buzzy sinewave

[22:49:03 CDT(-0500)] <Bosmon> In Chrome it runs smoothing

[22:49:09 CDT(-0500)] <colinclark> hmm

[22:49:10 CDT(-0500)] <Bosmon> In FF it cuts out for quite long periods

[22:49:19 CDT(-0500)] <Bosmon> But FF lags for me anyway horribly

[22:49:22 CDT(-0500)] <colinclark> okay, that's buffer underruns

[22:49:26 CDT(-0500)] <colinclark> that's fixed in the branch, I hope

[22:49:30 CDT(-0500)] <Bosmon> I mean, I can't even smoothly scroll windows

[22:49:33 CDT(-0500)] <colinclark> wow

[22:49:43 CDT(-0500)] <Bosmon> So it's not necessarily anything very bad with the impl

[22:49:53 CDT(-0500)] <Bosmon> I don't think any JS is capable of running smoothly in my FF

[22:50:08 CDT(-0500)] <colinclark> I'd love for you to run a few tests for me later in the weekend

[22:50:13 CDT(-0500)] <Bosmon> I'll be around

[22:50:13 CDT(-0500)] <colinclark> if you're around, Bosmon

[22:50:28 CDT(-0500)] <colinclark> So thealphanerd, tell me more about what you're thinking in terms of different types of synthesis?

[22:50:32 CDT(-0500)] <Bosmon> I guess I am up to 50 top-level FF windows already

[22:50:43 CDT(-0500)] <colinclark> Would you have, say, a menu or something of types of synthesis, which people could chose from?

[22:50:54 CDT(-0500)] <Bosmon> But before Chrome got its GDI bug, I could easily get > 100 frames

[22:51:01 CDT(-0500)] <colinclark> Or little patch cords and stuff, like my Korg MS-20?

[22:51:46 CDT(-0500)] <thealphanerd> I wans thinking differ UI for different options

[22:52:26 CDT(-0500)] <colinclark> I guess it might be interesting to perhaps combine the Infusion Renderer with Flocking SynthDefs

[22:52:46 CDT(-0500)] <colinclark> Transforming a SynthDef (which is a kind of model) into a Renderer component tree

[22:53:26 CDT(-0500)] <colinclark> Since a SynthDef represents a tree of unit generators, you can imagine it might map nicely onto a set of knobs and controls in the UI

[22:53:43 CDT(-0500)] <thealphanerd> indeed

[22:54:17 CDT(-0500)] <thealphanerd> you know what is interesting to think about

[22:54:19 CDT(-0500)] <thealphanerd> with using svg

[22:54:33 CDT(-0500)] <thealphanerd> you could get a designer to create your UI elements in illustrator

[22:54:41 CDT(-0500)] <thealphanerd> even fill it in based on a wireframe

[22:55:11 CDT(-0500)] <colinclark> yup

[22:55:29 CDT(-0500)] <colinclark> I think it's very promising

[22:55:33 CDT(-0500)] <thealphanerd> it would be really neat to make some infusion components

[22:55:49 CDT(-0500)] <thealphanerd> to make accessible gui elements that can manipulate component models

[22:55:53 CDT(-0500)] <colinclark> James even suspects that it will be a major player when dealing with this new world of different pixel densities

[22:55:59 CDT(-0500)] <colinclark> with Retina displays and the like

[22:56:05 CDT(-0500)] <thealphanerd> oh definitely

[22:56:13 CDT(-0500)] <colinclark> what sorts of components would you like to make, thealphanerd?

[22:56:19 CDT(-0500)] <thealphanerd> well knobs

[22:56:22 CDT(-0500)] <thealphanerd> color swatch

[22:56:23 CDT(-0500)] <thealphanerd> slider

[22:56:28 CDT(-0500)] <colinclark> knobs and sliders would be awfully nice

[22:56:37 CDT(-0500)] <thealphanerd> but so here is the thing

[22:56:45 CDT(-0500)] <thealphanerd> infusion would need some sort of svg component

[22:56:48 CDT(-0500)] <thealphanerd> to do all the rendering

[22:56:55 CDT(-0500)] <thealphanerd> and that would need to be used by the knob

[22:57:07 CDT(-0500)] <colinclark> well, I guess we've never considered it

[22:57:13 CDT(-0500)] <colinclark> but I'm not sure why the Renderer couldn't output SVG

[22:57:25 CDT(-0500)] <colinclark> there will undoubtedly be a few challenges

[22:57:37 CDT(-0500)] <colinclark> but I imagine it's possible

[22:57:44 CDT(-0500)] <colinclark> Bosmon: Have you ever tried it?

[22:58:40 CDT(-0500)] <thealphanerd> colinclark: I think it would be very intereting to design entire websites with svg

[22:59:10 CDT(-0500)] <thealphanerd> think legend of zelda for how you could explore a website

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

[22:59:37 CDT(-0500)] <colinclark>

[23:00:03 CDT(-0500)] <thealphanerd> sorry… I'm in a brainstormy mood. lots of talk, not much action

[23:00:08 CDT(-0500)] <colinclark> no no

[23:00:09 CDT(-0500)] <colinclark> it's cool

[23:00:19 CDT(-0500)] <colinclark> I guess my only niggling worry with SVG is performance

[23:00:42 CDT(-0500)] <colinclark> Canvas is sort of easy in that regard, because it typically just cuts a hole through the browser to the native OS's graphics layer

[23:00:50 CDT(-0500)] <colinclark> it's been fairly heavily optimized

[23:01:01 CDT(-0500)] <colinclark> whereas SVG has been sitting in most browsers for years, but probably not well-exercised

[23:01:04 CDT(-0500)] <thealphanerd> can you select canvas elements with jquery ?

[23:01:06 CDT(-0500)] <colinclark> Your piano looks super fast

[23:01:17 CDT(-0500)] <colinclark> Well, there are no elements IN a canvas

[23:01:24 CDT(-0500)] <colinclark> but you can select canvases themselves with jQuery, yes

[23:01:35 CDT(-0500)] <thealphanerd> that's where I lose interest though

[23:01:46 CDT(-0500)] <colinclark> where?

[23:01:52 CDT(-0500)] <thealphanerd> with canvas

[23:01:59 CDT(-0500)] <colinclark> in drawing shit programmatically on a canvas, you mean?

[23:02:00 CDT(-0500)] <thealphanerd> if you can't interactively manipulate the output

[23:02:04 CDT(-0500)] <colinclark> as opposed to having a DOM

[23:02:05 CDT(-0500)] <colinclark> yeah

[23:02:14 CDT(-0500)] <colinclark> Canvas is a non-retained mode drawing API

[23:02:16 CDT(-0500)] <colinclark> it's very low level

[23:02:19 CDT(-0500)] <colinclark> just pixels

[23:02:29 CDT(-0500)] <colinclark> Whereas SVG has an document model

[23:02:34 CDT(-0500)] <colinclark> that you can manipulate

[23:02:41 CDT(-0500)] <colinclark> I wonder in practice how SVG interacts with things like CSS2

[23:02:43 CDT(-0500)] <colinclark> 3

[23:02:43 CDT(-0500)] <thealphanerd> indeed

[23:02:59 CDT(-0500)] <colinclark> Like, can you use a CSS3 transition to move an SVG around the page?

[23:03:05 CDT(-0500)] <colinclark> I know that SVG has its own animation model, too

[23:03:20 CDT(-0500)] <thealphanerd> I'm not sure about moving

[23:03:27 CDT(-0500)] <thealphanerd> but I've faded them in and out with jquery

[23:03:31 CDT(-0500)] <thealphanerd> in the conosle

[23:03:44 CDT(-0500)] <colinclark> yeah, that's with JavaScript

[23:03:58 CDT(-0500)] <colinclark> CSS3 transitions and animations tend to be hardware accelerated these days

[23:04:00 CDT(-0500)] <colinclark> so very smooth

[23:04:03 CDT(-0500)] <thealphanerd> ahh

[23:04:04 CDT(-0500)] <thealphanerd> cool

[23:04:08 CDT(-0500)] <colinclark> It's definitely worth playing around with

[23:05:11 CDT(-0500)] <thealphanerd> https://blogs.adobe.com/webplatform/2012/03/30/svg-animations-css-animations-css-transitions/

[23:05:19 CDT(-0500)] <thealphanerd> looks like you can do css3 animations of svg

[23:22:31 CDT(-0500)] <colinclark> looks pretty awesome

[23:23:08 CDT(-0500)] <colinclark> well, the cat's back so I'm off to bed

[23:23:18 CDT(-0500)] <colinclark> really fun chatting with you, thealphanerd and Bosmon

[23:23:28 CDT(-0500)] <colinclark> enjoy EE, thealphanerd

[23:23:30 CDT(-0500)] <colinclark> see you on Tuesday

[23:23:30 CDT(-0500)] <thealphanerd> good night

[23:23:31 CDT(-0500)] <thealphanerd> adn thank you

[23:23:33 CDT(-0500)] <thealphanerd> see you tuesday

Browser not supported