[09:02:32 CDT(-0500)] <colinclark> hey kasper, welcome back!

[09:15:28 CDT(-0500)] <kasper> hey colinclark

[09:15:30 CDT(-0500)] <kasper> thanks a lot

[09:15:37 CDT(-0500)] <colinclark> How was surfing?

[09:15:45 CDT(-0500)] <kasper> absolutely awesome

[09:15:51 CDT(-0500)] <colinclark> that's so good

[09:15:54 CDT(-0500)] <colinclark> do you have any pictures?

[09:16:04 CDT(-0500)] <kasper> good waves and the Sri lankan people were very nice

[09:16:09 CDT(-0500)] <colinclark> that's awesome!

[09:16:25 CDT(-0500)] <kasper> I do, but they're on my camera atm.. will send you a link once I manage to upload some of them

[09:16:42 CDT(-0500)] <kasper> how have you been

[09:18:18 CDT(-0500)] <colinclark> I'd love to see them at some point

[09:18:22 CDT(-0500)] <colinclark> I've been good

[09:18:25 CDT(-0500)] <colinclark> nice to be back

[09:18:41 CDT(-0500)] <colinclark> It's been a quiet couple of weeks

[09:18:57 CDT(-0500)] <colinclark> Looks like there's a long AfA thread I missed this weekend

[09:22:22 CDT(-0500)] <kasper> colinclark: yeah - I've made it through most of my mails by now .. except for the SP2 one which contains what I imagine you're referring to (looks like it's a SP1/AfA and occassionally SP2 crossposting )

[09:22:42 CDT(-0500)] <colinclark> yeah, the cross posting is driving me nuts

[10:21:35 CDT(-0500)] <Justin_o> fluid-everyone: does anyone know if there were any changes to the change applier in those recent commits?

[10:22:12 CDT(-0500)] <colinclark> Justin_o: You mean the recent framework changes?

[10:22:24 CDT(-0500)] <colinclark> Specific ones, or just generally "has the ChangeApplier changed recently?"

[10:25:23 CDT(-0500)] <Justin_o> colinclark: i guess recently in general.. My current version of infusion in decapod is from several months ago, and can't remember if i had been using guards when i last tested a newer version of infusion

[10:31:26 CDT(-0500)] <colinclark> Justin_o: I pushed three requests last week

[10:31:47 CDT(-0500)] <colinclark> One included your fix to the Renderer

[10:32:03 CDT(-0500)] <colinclark> The second involved the change to merge policies that enabled us to fix the broken Reorderer tests

[10:33:49 CDT(-0500)] <colinclark> And the third was the fix for the issue yura saw in the framework where clearComponent() was destroying injected components

[10:33:58 CDT(-0500)] <colinclark> which caused problems for "new Kettle"

[10:47:00 CDT(-0500)] <Justin_o> colinclark: okay.. thanks for the update.. i took a quick look at the commits in github, but didn't' notice anything obvious

[10:48:34 CDT(-0500)] <colinclark> Justin_o: Your plan of a test case and a JIRA ticket for the issue sounds like a good one

[10:49:02 CDT(-0500)] <Justin_o> colinclark: thanks.. i hope to have that in later this afternoon

[10:49:31 CDT(-0500)] <colinclark> let me know if I can help at all

[13:55:02 CDT(-0500)] <anastasiac> Bosmon, are you there?

[14:00:45 CDT(-0500)] <athena> is fluid 1.4 compatible with jquery 1.7?

[14:00:59 CDT(-0500)] <colinclark> hey athena

[14:01:04 CDT(-0500)] * athena waves

[14:01:15 CDT(-0500)] <colinclark> jQuery keeps changing their APIs… every new release, a new compatibility-breaking API change

[14:01:42 CDT(-0500)] <athena> hard to keep up, i imagine

[14:01:59 CDT(-0500)] <colinclark> Latest unreleased version of Infusion adds support for jQuery 1.7.2

[14:02:23 CDT(-0500)] <athena> is that a major change from 1.4?

[14:02:32 CDT(-0500)] <colinclark> hmm

[14:02:39 CDT(-0500)] <colinclark> Well, there's a lot in there that has changed

[14:02:44 CDT(-0500)] <colinclark> and hasn't been through a full QA cycle

[14:02:51 CDT(-0500)] <athena> gotcha

[14:02:55 CDT(-0500)] <colinclark> but interestingly, a number of people are already using it

[14:03:10 CDT(-0500)] <athena> sounds worth trying out

[14:03:13 CDT(-0500)] <colinclark> CollectionSpace and Decapod both use a 1.5 prerelease

[14:03:17 CDT(-0500)] <athena> but trying out, not putting into tomorrow's release

[14:03:22 CDT(-0500)] <colinclark> yes

[14:03:35 CDT(-0500)] <colinclark> We are starting to do some planning around an Infusion 1.5 release

[14:03:43 CDT(-0500)] <athena> nice

[14:03:47 CDT(-0500)] <colinclark> We'll of course support the latest jQuery and jQuery UI

[14:03:52 CDT(-0500)] <athena> always good to hear about progress

[14:04:00 CDT(-0500)] <colinclark> We keep chipping away

[14:04:11 CDT(-0500)] <colinclark> Here's the commit that introduced jQuery 1.7 support: https://github.com/fluid-project/infusion/commit/c85bcf84058414579872ab40fb99f7442dcae772

[14:04:18 CDT(-0500)] <athena> awesome, thanks

[14:04:34 CDT(-0500)] <colinclark> Looks like we also had to link to a prerelease version of jQuery UI

[14:04:41 CDT(-0500)] <athena> ahh

[14:05:35 CDT(-0500)] <colinclark> It looks like even the latest release of jQuery UI still depends on jQuery 1.4?

[14:07:50 CDT(-0500)] <athena> lol

[14:07:59 CDT(-0500)] <athena> interesting

[14:08:03 CDT(-0500)] <athena> we've been using 1.6 for a while

[14:08:19 CDT(-0500)] <athena> in the process of updating jquery mobile and adding backbone.js

[14:08:32 CDT(-0500)] <athena> but looks like both of those can live with 1.6 as long as it's the latest rev

[14:40:49 CDT(-0500)] <thealphanerd> colinclark: you around?

[14:40:58 CDT(-0500)] <colinclark> i am, yes

[14:42:24 CDT(-0500)] <thealphanerd> a little late to chat now?

[14:46:02 CDT(-0500)] <colinclark> I can't chat over Skype at the moment

[14:46:04 CDT(-0500)] <colinclark> but I could type here

[14:50:46 CDT(-0500)] <thealphanerd> soo

[14:50:53 CDT(-0500)] <thealphanerd> I figured out what is going on with the .on() thing

[14:50:56 CDT(-0500)] <thealphanerd> for some reason

[14:51:13 CDT(-0500)] <thealphanerd> infusion is killing the method

[14:51:31 CDT(-0500)] <thealphanerd> once the infusion script has been included… jquery no longer has the .on() method

[14:51:35 CDT(-0500)] <thealphanerd> does that make any sense?

[14:56:02 CDT(-0500)] <thealphanerd> does infusion heavily modify jquery?

[15:07:57 CDT(-0500)] <colinclark> no

[15:08:03 CDT(-0500)] <colinclark> Not at all, not even a little bit

[15:08:08 CDT(-0500)] <colinclark> Not even the slightest

[15:08:11 CDT(-0500)] <thealphanerd> so does it make any sense?

[15:08:14 CDT(-0500)] <colinclark> No

[15:08:20 CDT(-0500)] <colinclark> Does your build of Infusion include jQuery?

[15:08:29 CDT(-0500)] <colinclark> And are you trying to include a newer version of jQuery with it?

[15:08:33 CDT(-0500)] <thealphanerd> I don't think so… but maybe it does

[15:08:52 CDT(-0500)] <colinclark> What version of Infusion are you using?

[15:08:58 CDT(-0500)] <colinclark> Did you make a custom build somehow?

[15:09:04 CDT(-0500)] <thealphanerd> OHHH its does have jquery in there

[15:09:09 CDT(-0500)] <thealphanerd> this is making so much sense now

[15:09:18 CDT(-0500)] <thealphanerd> I've been having all these freaking weird edge cases

[15:09:26 CDT(-0500)] <colinclark>

[15:09:35 CDT(-0500)] <colinclark> So, where did you get your build of Infusion?

[15:09:38 CDT(-0500)] <colinclark> Did you make it from the Builder?

[15:09:39 CDT(-0500)] <thealphanerd> I have infusion 1.4 i think

[15:09:42 CDT(-0500)] <colinclark> ok

[15:09:57 CDT(-0500)] <colinclark> As I was saying to athena earlier, Infusion 1.4 didn't ship with jQuery 1.7.x

[15:10:11 CDT(-0500)] <thealphanerd> btw as an aside… in jquery 1.7 all event binders call on .on()

[15:10:17 CDT(-0500)] <colinclark> You'll have to get a prerelease from Git

[15:10:25 CDT(-0500)] <colinclark> thealphanerd: yes, that's right

[15:10:47 CDT(-0500)] <thealphanerd> so rolling back jquery was breaking code relying on .on()

[15:11:02 CDT(-0500)] <thealphanerd> this explains so many things

[15:11:30 CDT(-0500)] <colinclark> So, making a build of Infusion from source is a bit annoying

[15:11:46 CDT(-0500)] <colinclark> and I have to confess that our nightly build of the Builder is currently broken

[15:11:51 CDT(-0500)] <colinclark> It's on my to do list to fix it this week

[15:11:55 CDT(-0500)] <thealphanerd> lol

[15:12:05 CDT(-0500)] <colinclark> To make it easy, I think someone here can probably make you a build

[15:12:07 CDT(-0500)] <thealphanerd> so should I grab the latest source from git?

[15:12:17 CDT(-0500)] <thealphanerd> or just wait?

[15:12:17 CDT(-0500)] <thealphanerd> {color}

[15:12:28 CDT(-0500)] <colinclark> Hey anastasiac, are you set up to make Ant builds of Infusion at the moment?

[15:12:41 CDT(-0500)] <anastasiac> yes, colinclark, I can do that

[15:13:01 CDT(-0500)] <colinclark> Any chance you could make thealphanerd a quick framework build of the latest code from master?

[15:13:06 CDT(-0500)] <thealphanerd>

[15:13:11 CDT(-0500)] <thealphanerd> pretty please with cherries and such

[15:13:15 CDT(-0500)] <colinclark> thealphanerd: Do you want it to include jQuery?

[15:13:16 CDT(-0500)] <anastasiac> np - just framework and nothing but?

[15:13:25 CDT(-0500)] <thealphanerd> don't include jQuery

[15:13:38 CDT(-0500)] <thealphanerd> I'm going to reference to the official google ajax repository

[15:16:47 CDT(-0500)] <colinclark> anastasiac: Sorry to distract you

[15:16:54 CDT(-0500)] <anastasiac> np!

[15:17:01 CDT(-0500)] <thealphanerd> colinclark: speaking of building

[15:17:27 CDT(-0500)] <thealphanerd> is there an easy way to minify a number of scripts ? right now I'm doing it manually in the command line

[15:17:38 CDT(-0500)] <thealphanerd> cat foo.js | jsmin > bar.min.js

[15:17:42 CDT(-0500)] <colinclark> It's a good question

[15:17:48 CDT(-0500)] <colinclark> I'm a little behind on these things

[15:17:48 CDT(-0500)] <anastasiac> thealphanerd, did you want the Infusion build to be minified, or not?

[15:17:57 CDT(-0500)] <thealphanerd> nope

[15:17:59 CDT(-0500)] <anastasiac> k

[15:18:00 CDT(-0500)] <thealphanerd> but thank you for the offer

[15:18:08 CDT(-0500)] <colinclark> but most people seem to use something called Grunt

[15:18:12 CDT(-0500)] <colinclark> a Node.js build tool

[15:18:24 CDT(-0500)] <colinclark> I am starting to plot out our plan for Infusion's new build system

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

[15:19:03 CDT(-0500)] <colinclark> I think we will actually use a little piece of the GPII

[15:19:17 CDT(-0500)] <anastasiac> thealphanerd, your Infusion build is in the e-mail. Let me know if there are any problems with it

[15:19:18 CDT(-0500)] <colinclark> called "lifecycle actions"

[15:19:19 CDT(-0500)] <colinclark> quite possibly in tandem with Grunt

[15:20:17 CDT(-0500)] <thealphanerd> interesting… just digging through grunt right now

[15:21:10 CDT(-0500)] <thealphanerd> anastasiac: got it!!! thank you very much

[15:21:15 CDT(-0500)] <anastasiac> np

[15:21:54 CDT(-0500)] <colinclark> I'll likely do something similar for Flocking

[15:23:40 CDT(-0500)] <thealphanerd> colinclark: I'm throwing all sorts of errors now

[15:23:44 CDT(-0500)] <thealphanerd> mostly for autoInit

[15:24:12 CDT(-0500)] <colinclark> thealphanerd: We still haven't had that conversation about how to file good bug reports

[15:24:26 CDT(-0500)] <colinclark> thealphanerd: Do you have a favourite paste tool?

[15:24:35 CDT(-0500)] <thealphanerd> pastebin

[15:24:40 CDT(-0500)] <thealphanerd> ?

[15:24:52 CDT(-0500)] * thealphanerd smells of noob

[15:24:55 CDT(-0500)] <colinclark> lol

[15:24:56 CDT(-0500)] <colinclark>

[15:25:05 CDT(-0500)] <colinclark> You might start by firing us a paste bin containing the error message you're seeing

[15:25:17 CDT(-0500)] <colinclark> and a snippet of code where it is occurring

[15:26:54 CDT(-0500)] <thealphanerd> http://pastebin.com/NLuBnKth

[15:27:12 CDT(-0500)] <thealphanerd> I think it has to do with how I defined my components

[15:27:16 CDT(-0500)] <thealphanerd> every component is failing now

[15:28:09 CDT(-0500)] <colinclark> ah yes

[15:28:16 CDT(-0500)] <colinclark> I believe all components need grades

[15:28:26 CDT(-0500)] <thealphanerd> wat?

[15:28:30 CDT(-0500)] <thealphanerd>

[15:28:34 CDT(-0500)] <thealphanerd> I'll check the documentation

[15:28:37 CDT(-0500)] <colinclark> Do you have a gradeNames option in your defaults for each component?

[15:29:08 CDT(-0500)] <thealphanerd> yup

[15:29:51 CDT(-0500)] <thealphanerd> http://pastebin.com/WM7DDrm0

[15:30:09 CDT(-0500)] <colinclark> fascinating

[15:36:18 CDT(-0500)] <colinclark> Just for my own curiosity, can you give them empty preInit and finalInit functions?

[15:36:41 CDT(-0500)] <colinclark> just preInitFunction: "fluid.identity" should do the trick

[15:37:16 CDT(-0500)] <thealphanerd> well I have pre / post init functions

[15:37:19 CDT(-0500)] <thealphanerd> should I rename them?

[15:37:43 CDT(-0500)] <colinclark> no

[15:38:02 CDT(-0500)] <colinclark> just add finalInit in that case

[15:38:03 CDT(-0500)] <thealphanerd> as well the first error regarding "cannot read property 'keyCode' of undefined" is being thrown without using any infusion stuff

[15:38:46 CDT(-0500)] <colinclark> ah

[15:38:51 CDT(-0500)] <colinclark> it's missing jQuery UI

[15:39:10 CDT(-0500)] <thealphanerd> ahhh

[15:39:16 CDT(-0500)] <colinclark> Infusion's keyboard accessibility plugin depends on jQuery UI core

[15:39:22 CDT(-0500)] <colinclark> AC built you a completely bare framework build

[15:39:36 CDT(-0500)] <colinclark> which means you need to satisfy all its dependencies

[15:39:45 CDT(-0500)] <colinclark> Forget my previous and distracted advice

[15:40:49 CDT(-0500)] <thealphanerd> I think that fixed it

[15:40:54 CDT(-0500)] <colinclark> thealphanerd: You need this file

[15:40:56 CDT(-0500)] <thealphanerd> just needed to include jqueryui

[15:41:04 CDT(-0500)] <colinclark> or your preferred version

[15:41:25 CDT(-0500)] <thealphanerd> which file?

[15:42:14 CDT(-0500)] <colinclark> sorry

[15:42:17 CDT(-0500)] <colinclark> forgot to paste it

[15:42:35 CDT(-0500)] <colinclark> https://github.com/fluid-project/infusion/blob/master/src/webapp/lib/jquery/ui/js/jquery.ui.core.js

[15:42:41 CDT(-0500)] <colinclark> i'm distracted by a meeting

[15:43:15 CDT(-0500)] <colinclark> you might need a handful of others. This is the dependency file in Infusion for jQuery UI, which describes the files we depend on: https://github.com/fluid-project/infusion/blob/master/src/webapp/lib/jquery/ui/jQueryUICoreDependencies.json

[15:43:16 CDT(-0500)] <thealphanerd> is that better than https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.21/jquery-ui.min.js ?

[15:43:39 CDT(-0500)] <thealphanerd> including the jquery / jquery ui from ajax.googleapis.com fixed everything

[15:43:39 CDT(-0500)] <colinclark> thealphanerd: it's probably smaller--presumably that is a full build of jQuery UI with all the widgets

[15:43:53 CDT(-0500)] <colinclark> which is great if you need them

[15:43:59 CDT(-0500)] <colinclark> good to hear it

[15:44:29 CDT(-0500)] <thealphanerd> which would you suggest to go with?

[15:44:36 CDT(-0500)] <colinclark> Well, it really depends

[15:44:53 CDT(-0500)] <colinclark> If you figure you might eventually use any of the jQuery UI widgets, this might be convenient

[15:45:00 CDT(-0500)] <colinclark> otherwise, the general approach is to be as minimal as possible

[15:45:08 CDT(-0500)] <colinclark> only linking in the stuff you actually use

[15:56:36 CDT(-0500)] <colinclark> hey thealphanerd, when are you going to try flock.synth.polyphonic()?

[15:57:00 CDT(-0500)] <thealphanerd> the plan is tomorrow

[15:57:08 CDT(-0500)] <thealphanerd> right now I'm trying to get the touch stuff working

[15:57:11 CDT(-0500)] <thealphanerd> especiialy multi-touch

[15:57:15 CDT(-0500)] <colinclark> How will users play multiple notes?

[15:57:39 CDT(-0500)] <thealphanerd> well the hope would be multi-touch would enable them to play multiple notes

[15:57:54 CDT(-0500)] <thealphanerd> but it is very possible that flocking won't work on mobile

[15:57:58 CDT(-0500)] <colinclark> How does your multitouch library work with the mouse?

[15:58:04 CDT(-0500)] <colinclark> It works fine on mobile...

[15:58:12 CDT(-0500)] <colinclark> but there is virtually no audio support on mobile

[15:58:23 CDT(-0500)] <NickMayne> Hey

[15:58:28 CDT(-0500)] <colinclark> So, I have managed to get it to work on some random Android tablet

[15:58:36 CDT(-0500)] <colinclark> In Firefox

[15:58:41 CDT(-0500)] <colinclark> Hey NickMayne

[15:58:57 CDT(-0500)] <NickMayne> Howdy @colinclark

[15:59:03 CDT(-0500)] <colinclark> Chrome on Android doesn't include the Web Audio API

[15:59:17 CDT(-0500)] <colinclark> and it looks like Firefox does, but it's very device specific

[15:59:26 CDT(-0500)] <thealphanerd> chrome on android isn't rendering properly anyways

[16:00:03 CDT(-0500)] <colinclark> once iOS 6 comes out, I guess we'll have a bit better support

[16:00:51 CDT(-0500)] <colinclark> Android Chrome chokes on SVG or something, thealphanerd?

[16:01:00 CDT(-0500)] <thealphanerd> I really don't know

[16:01:08 CDT(-0500)] <thealphanerd> because I havn't used developer tools on android before

[16:01:20 CDT(-0500)] <thealphanerd> but the android chrome only renders the first piano on automm.com

[16:01:32 CDT(-0500)] <thealphanerd> could be svg

[16:01:33 CDT(-0500)] <thealphanerd> could be infusion

[16:01:59 CDT(-0500)] <colinclark> blame it on Infusion

[16:02:35 CDT(-0500)] <colinclark> So, thealphanerd, why do multitouch if you don't think the AMMM will run on mobile?

[16:03:08 CDT(-0500)] <thealphanerd> because I want the piano / grid components to be flexible for other projects

[16:03:14 CDT(-0500)] <thealphanerd> specifically for osc controllers

[16:03:46 CDT(-0500)] <thealphanerd> once the aria stuff is in place to it could make an inclusive osc / midi controller that can interface with all sorts of audio engines

[16:10:41 CDT(-0500)] <colinclark> thealphanerd: This is just me...

[16:10:52 CDT(-0500)] <colinclark> but I might focus on your core feature set first

[16:11:02 CDT(-0500)] <colinclark> i.e. making it inclusive

[16:11:34 CDT(-0500)] <thealphanerd> that is a fair point

[16:11:39 CDT(-0500)] <thealphanerd> we are getting close to the pencils down dae

[16:11:45 CDT(-0500)] <thealphanerd> and that is a primary feature

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

[16:12:19 CDT(-0500)] <colinclark> Finding a few strategies for being able to actually play it with a means other than the mouse

[16:13:21 CDT(-0500)] <colinclark> and then the arpeggiator

[16:13:32 CDT(-0500)] <thealphanerd> colinclark: that was something i was thinking about

[16:13:36 CDT(-0500)] <thealphanerd> with the arpeggiator

[16:13:44 CDT(-0500)] <thealphanerd> how should the timing be handled

[16:13:46 CDT(-0500)] <thealphanerd> between notes

[16:14:05 CDT(-0500)] <thealphanerd> and how do I manage that timing while keeping the project async

[16:16:33 CDT(-0500)] <colinclark> There are a couple ways

[16:17:04 CDT(-0500)] <colinclark> I guess the first thing is to figure out exactly what you want it to do

[16:17:07 CDT(-0500)] <colinclark> and how you want it to be controlled

[16:17:26 CDT(-0500)] <colinclark> You could write an arpeggiator unit generator

[16:17:39 CDT(-0500)] <colinclark> or you could use the "conductor"

[16:17:49 CDT(-0500)] <colinclark> which currently is barely in existence

[16:18:34 CDT(-0500)] <colinclark> but will at least call a function for you at a regular interval

[16:18:43 CDT(-0500)] <colinclark> It runs inside a web worker, so it's relatively stable

[16:18:55 CDT(-0500)] <colinclark> not necessarily absolutely rock solid

[16:18:58 CDT(-0500)] <colinclark> but as close as one can get

[16:19:23 CDT(-0500)] <thealphanerd> well I guess the quewstion becomes if it is going to live in infusion land or flcokign land (same ole problem(

[16:19:40 CDT(-0500)] <thealphanerd> because if it were to live in flocking land, it could prove difficult to get visual feedback

[16:20:00 CDT(-0500)] <colinclark> There's no reason, like your piano, that it can't bridge both worlds

[16:20:10 CDT(-0500)] <thealphanerd> that's true I guess

[16:20:17 CDT(-0500)] <thealphanerd> so you think the arpeggiator should be a ugen?

[16:20:33 CDT(-0500)] <colinclark> It really depends

[16:21:19 CDT(-0500)] <colinclark> A UGen really shouldn't do any presentational work

[16:22:10 CDT(-0500)] <colinclark> Which raises the question, "how do I know when a note is playing so that I can show something in the UI?"

[16:22:18 CDT(-0500)] <colinclark> And there's some room for flexibility here

[16:22:31 CDT(-0500)] <colinclark> but it's very costly to do anything in the main processing thread

[16:22:57 CDT(-0500)] <colinclark> So, from the perspective of making the sounds of the arpeggiator, it's actually cheapest and most efficient and time-stable if you do it in a UGen

[16:23:22 CDT(-0500)] <colinclark> but if you have lots of rich GUI ideas to go with it, I suspect using conductor.schedulePeriodic() is better

[16:23:46 CDT(-0500)] <colinclark> But I think we might be able to experiment with something in between

[16:24:48 CDT(-0500)] <colinclark> I have been meaning to implement a scheduler UGen that would have more stability than the current Worker-based conductor

[16:25:18 CDT(-0500)] <colinclark> I just can't tell whether or not an asynchronous implementation of this would have hard-to-predict latency

[16:25:33 CDT(-0500)] <colinclark> only way to know is to try

[16:25:45 CDT(-0500)] <colinclark> easiest way for you to try is to use conductor.schedulePeriodic()

[16:25:47 CDT(-0500)] <colinclark> so do that

[16:29:15 CDT(-0500)] <thealphanerd> made a note of it

[16:29:20 CDT(-0500)] <thealphanerd> will take a stab before thursday

[16:35:05 CDT(-0500)] <colinclark> If you look at some of the dorky examples I've got in the demo playground, you'll see things that should give you exactly what you want

[16:35:17 CDT(-0500)] <colinclark> in fact, have a look at the "Polyphonic Synth" demo

[16:35:38 CDT(-0500)] <colinclark> which annoyingly plays an arpeggiated major chord over and over again

[16:37:55 CDT(-0500)] <colinclark> thealphanerd: https://github.com/colinbdclark/Flocking/blob/synth-groups/demos/interactive/html/playground.html#L477-541

[16:41:45 CDT(-0500)] <thealphanerd> taking a peak

[16:42:17 CDT(-0500)] <thealphanerd> btw flocking synths can now be updated via a model rioght?

[16:42:30 CDT(-0500)] <colinclark> indeed

[16:42:50 CDT(-0500)] <colinclark> you can see it being done here with the "change" property

[16:42:59 CDT(-0500)] <colinclark> it's a slightly contrived example, but it's a very very early start at coming up with a declarative way of representing musical events

[16:45:10 CDT(-0500)] <colinclark> But I imagine your arpeggiator would probably have something a lot like this

[16:45:27 CDT(-0500)] <thealphanerd> ahhh

[16:45:32 CDT(-0500)] <colinclark> a list of noteOn "changes"

[16:45:37 CDT(-0500)] <colinclark> and another list of noteOff changes

[16:46:08 CDT(-0500)] <colinclark> And it would presumably listen to those events as they are fired by your components

[16:46:31 CDT(-0500)] <colinclark> and schedule them with your polyphonic synth

[16:46:34 CDT(-0500)] <thealphanerd> and then I guess fire events to highlight un highlight ntoes

[16:47:11 CDT(-0500)] <colinclark> Hopefully another component might even do that for it

[16:47:17 CDT(-0500)] <colinclark> i.e. your piano and grid

[16:47:27 CDT(-0500)] <colinclark> or the "highlighter" component you haven't yet made

[16:47:43 CDT(-0500)] <colinclark> you might need some kind of slightly more fine grained events

[16:48:04 CDT(-0500)] <colinclark> i.e. a distinction between notes that a user has initiated and ones that happen otherwise

[16:48:29 CDT(-0500)] <colinclark> in other words onKeyPress and onKeyRelease which then fire noteOn/noteOff

[16:48:39 CDT(-0500)] <colinclark> so you could do things like render the keys the user pressed differently

[16:48:57 CDT(-0500)] <colinclark> or indeed not infinitely arpeggiate your arpeggiator's notes

[16:49:44 CDT(-0500)] <thealphanerd> yeah… I'm definitely going to have to rethink some of the logic here

[16:51:27 CDT(-0500)] <colinclark> So, I'll highlight a couple of key things for using the synth.polyphonic

[16:52:02 CDT(-0500)] <colinclark> All the interesting stuff is in the options: https://github.com/colinbdclark/Flocking/blob/synth-groups/flocking/flocking-core.js#L1151-1167

[16:52:29 CDT(-0500)] <colinclark> The most notable are the "noteSpecs" and "amplitudeKey" options

[16:52:56 CDT(-0500)] <colinclark> The "noteSpecs" structure defines the meaning of noteOn() and noteOff() for your particular synth def

[16:53:20 CDT(-0500)] <colinclark> you can define any input paths that you'd like to change every time noteOn and noteOff are fired

[16:53:48 CDT(-0500)] <colinclark> by default, it should work with your current synthDef--it will set and unset a gate input at the path "env.gate"

[16:54:19 CDT(-0500)] <colinclark> The "amplitudeKey" option is used when you want an amplitudeNormalizer strategy

[16:54:35 CDT(-0500)] <colinclark> it tells the polyphonic synth how to set the volume of your voices

[16:54:44 CDT(-0500)] <colinclark> again, it should work out of the box for you

[16:54:53 CDT(-0500)] <colinclark> maxVoices should be fairly apparent

[16:55:19 CDT(-0500)] <colinclark> there is currently only one amplitudeNormalizer implementation...

[16:55:34 CDT(-0500)] <colinclark> and all it does is set each voice's amplitude to 1.0 / maxVoices

[16:57:32 CDT(-0500)] <thealphanerd> so would I be wanting to replace my current calls to be using noteSpecs.on and off ?

[17:02:21 CDT(-0500)] <colinclark> well, that's the nice thing

[17:02:51 CDT(-0500)] <colinclark> you just replace your current calls to input(…) to noteOn() and noteOff() calls

[17:03:26 CDT(-0500)] <colinclark> these methods are "input-like" in that you can give them a "change object"

[17:03:44 CDT(-0500)] <colinclark> (I'm using so many quotes here because I'm still not sure about terminology, given this stuff is less than 24 hours old)

[17:03:50 CDT(-0500)] <colinclark> so your current call

[17:04:28 CDT(-0500)]

<colinclark> input(

Unknown macro: {"env.gate"}

) now just becomes noteOn(

Unknown macro: {"carrier.freq"}

)

[17:05:57 CDT(-0500)] <colinclark> For the mouse-based interaction, I guess you could make keys "sticky" when the user shift-clicks them

[17:06:18 CDT(-0500)] <colinclark> it's a pretty familiar idiom, and it would only involve a few extra lines

[17:06:52 CDT(-0500)] <colinclark> I was actually sort of thinking that the "traditional" keyboard interaction might work the same way

[17:07:01 CDT(-0500)] <colinclark> in addition to having letter key bindings

[17:11:42 CDT(-0500)] <thealphanerd> shift sticky is a good idea

[17:11:48 CDT(-0500)] <thealphanerd> that wouldn't be hard to do either

[17:11:53 CDT(-0500)] <thealphanerd> just make shift trigger a boolean

[17:16:45 CDT(-0500)] <colinclark> I think you'd probably just extend your current click handler to look for the shift key

[17:17:26 CDT(-0500)] <colinclark> well

[17:17:27 CDT(-0500)] <colinclark> yeah

[17:17:32 CDT(-0500)] <colinclark> I guess you'd need a bit of state

[17:17:38 CDT(-0500)] <colinclark> for each key

[17:17:47 CDT(-0500)] <colinclark> to remember if it's currently sticking

[17:17:54 CDT(-0500)] <colinclark> in your model

[17:20:10 CDT(-0500)] <thealphanerd> that's what i'd dot

[17:20:12 CDT(-0500)] <thealphanerd> isShit

[17:20:19 CDT(-0500)] <thealphanerd> isShift = false

[17:20:32 CDT(-0500)] <thealphanerd> set an event handler for keypress… filter shift

[17:20:50 CDT(-0500)] <thealphanerd> check for boolean before doing note off

[17:21:18 CDT(-0500)] <thealphanerd> maybe keep an array of all notes currently playing

[17:21:30 CDT(-0500)] <thealphanerd> have unshift iterate through and note off them

[17:21:42 CDT(-0500)] <thealphanerd> wonder if shift + arpeggitor could cause weird edgecases

[17:22:06 CDT(-0500)] <colinclark> isShit definitely === false

[17:23:03 CDT(-0500)] <colinclark> I guess you could design your arpeggiator for polyphony

[17:24:47 CDT(-0500)] <thealphanerd> but if you have shift being held

[17:24:50 CDT(-0500)] <thealphanerd> well polyphony is going

[17:24:59 CDT(-0500)] <thealphanerd> would you want the notes to release/

[17:25:00 CDT(-0500)] <colinclark> I guess the Juno-6 and 60 had one, back in the analog days

[17:25:31 CDT(-0500)] <colinclark> That's the cool part of your project

[17:25:35 CDT(-0500)] <colinclark> you get to design for it

[17:25:49 CDT(-0500)] <colinclark> so I can imagine maybe it's something like a sustain pedal

[17:26:05 CDT(-0500)] <colinclark> so your arpeggiator might start droning when shift is down

[17:26:13 CDT(-0500)] <colinclark> or maybe it would just arpeggiate as normal

[17:26:51 CDT(-0500)] <colinclark> another big reason why you'll need a distinction between someone actually pressing a key and noteOn

[17:27:34 CDT(-0500)] <thealphanerd> indeed

[17:32:16 CDT(-0500)] <thealphanerd> colinclark: so i'll start sussing out the logic tomorrow… and hopefully will have a polyphony / arpeggiator for htursday, that way we can spend the rest of the next week working out aria stuff

[17:32:27 CDT(-0500)] <colinclark> that'd be wicked

[17:32:31 CDT(-0500)] <thealphanerd> and then do some refactoring prior to pencils down

[17:32:37 CDT(-0500)] <colinclark> sounds like a plan

[17:32:48 CDT(-0500)] <thealphanerd> and then we'll just keep going

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

[17:32:55 CDT(-0500)] <colinclark> just ping me here if you get stuck using synth.polyphonic

[17:33:03 CDT(-0500)] <colinclark> who knows if it even works?

[17:33:07 CDT(-0500)] <thealphanerd> hahah

[17:33:45 CDT(-0500)] <thealphanerd> btw did you ever take a peak at the open sourced moog google doodle?

[17:33:53 CDT(-0500)] <colinclark> i did, yes

[17:34:03 CDT(-0500)] <colinclark> not as much time as i would have liked, but i read some of it when I was in Linz

[17:38:10 CDT(-0500)] <thealphanerd> fair enough

Browser not supported