fluid-work IRC Logs-2013-03-04

[10:53:21 CST(-0600)] <colinclark> Justin_o and michelled: How would you feel about the prospect of having our current Mammals Demo included as part of the Cloud4all "SP3 demonstrations" during the upcoming pilot testing?

[10:54:06 CST(-0600)] <colinclark> I think we could probably get away with not having it integrated directly with the GPII preferences server

[10:54:20 CST(-0600)] <colinclark> since I think that code has broken with recent changes both to the preferences server and the preferences format itself

[10:56:03 CST(-0600)] <Justin_o> colinclark: how would it be used exactly.. user testing? proof of concept? etc.

[10:56:15 CST(-0600)] <colinclark> I believe it would be shown as a demo

[10:57:01 CST(-0600)] <colinclark> I'm not fully clear on that

[10:57:01 CST(-0600)] <colinclark> I can show you volumes of paperwork describing the demos, but I'm not convinced I could actually explain to you what the demonstrations specifically entail

[10:57:09 CST(-0600)] <Justin_o> colinclark: i'll pass on reading volumes of paperwork

[10:57:19 CST(-0600)] <colinclark>

[10:57:45 CST(-0600)] <Justin_o> colinclark: it should be fine, as long as people understand that it isn't a 1.0 release or anything..

[10:57:59 CST(-0600)] <Justin_o> that there are still some bugs they might hit

[11:09:03 CST(-0600)] <colinclark> Ok, I think that part should be acceptable

[11:09:04 CST(-0600)] <colinclark> thanks, Justin_o

[11:09:50 CST(-0600)] <Justin_o> colinclark: great, thanks

[11:25:05 CST(-0600)] <colinclark> Justin_o: So is this the definitive demo? http://build.fluidproject.org/videoPlayer/videoPlayer/demos/Mammals.html

[11:31:01 CST(-0600)] <Justin_o> colinclark: yes, but that's live and built nightly i believe.. so when we make more changes later it will be modified.. we haven't set up a static demo yet

[11:31:09 CST(-0600)] <colinclark> ok

[11:31:13 CST(-0600)] <colinclark> Is that difficult?

[11:47:00 CST(-0600)] <Justin_o> colinclark: um.. probably not, will have to talk to avtar about it

[11:47:08 CST(-0600)] <colinclark> ok

[11:47:15 CST(-0600)] <colinclark> i'll let you know if it becomes a priority

[11:47:27 CST(-0600)] <Justin_o> colinclark: thanks

[13:15:53 CST(-0600)] <heidiv> Justin_o it seems to be that the YT overlay is interfering somehow

[13:17:35 CST(-0600)] <heidiv> i'll file a jira, but something to add to our known issues i guess

[13:17:59 CST(-0600)] <Justin_o> heidiv: thanks

[13:21:33 CST(-0600)] <heidiv> Justin_o http://issues.fluidproject.org/browse/VP-288

[13:23:12 CST(-0600)] <Justin_o> heidiv: i wonder if this is related http://issues.fluidproject.org/browse/VP-277

[13:23:50 CST(-0600)] <heidiv> hmm

[13:24:36 CST(-0600)] <heidiv> Justin_o jhung when the video player is focused is space supposed to start the vid?

[13:25:46 CST(-0600)] <heidiv> n/m, YT is using the flash player so i'm not surprised that doesn't work

[13:26:35 CST(-0600)] <heidiv> really seems like there is a YT play overlay happening that's blocking the click … so might be diff issue

[13:29:25 CST(-0600)] <Justin_o> heidiv: okay.. i wonder.. seems like we have a bunch of issues around using flash players in general

[13:32:04 CST(-0600)] <heidiv> Justin_o ya…

[14:17:43 CST(-0600)] <colinclark> Hot wiki page, yzen. Thanks for writing it!

[14:17:58 CST(-0600)] <yzen> colinclark: haha thanks

[14:26:19 CST(-0600)] <thealphanerd> hey colinclark

[14:26:26 CST(-0600)] <thealphanerd> howd the conference go?

[14:26:31 CST(-0600)] <colinclark> Justin_o: My impression in the past was the jQuery documentation site was mostly just a collection of custom code that couldn't easily be reused by other projects. Reading your update from the conference, I wondered if you had the sense that this has changed?

[14:26:39 CST(-0600)] <colinclark> thealphanerd: Quite good

[14:26:43 CST(-0600)] <colinclark> Now I'm in Austin for SXSW

[14:26:49 CST(-0600)] <thealphanerd> dope

[14:27:21 CST(-0600)] <Justin_o> colinclark: well sounds like they reuse their code across all of their sites now.. which i think they said was at about 20 or something like that

[14:27:48 CST(-0600)] <colinclark> Justin_o: Do you know whether it would be viable for us to pick it up and use it?

[14:28:14 CST(-0600)] <Justin_o> colinclark: i think it's more than just sharing code though, they have worked to define a way to allow for communal editing and etc while maintaining standards and preventing spam

[14:28:35 CST(-0600)] <colinclark> Right

[14:28:42 CST(-0600)] <colinclark> which is why I'm curious about our ability to use it

[14:28:53 CST(-0600)] <Justin_o> colinclark: not sure.. perhaps we could adapt their distro and other bits… apparently the lead developer from Wordpress helped them make it

[14:29:40 CST(-0600)] <Justin_o> colinclark: i don't think we can use it for everything. I'm not sure that we'd want to use it for places where most of our contributions come from non-techie individuals.. those who don't want to or are inexperienced using git

[14:30:34 CST(-0600)] <colinclark> Justin_o: Sure. So we'd continue to use MediaWiki for general-audience contributions like, say, the Inclusive Learning Design Handbook. But for Infusion documentation, I wonder if it would be viable.

[14:31:32 CST(-0600)] <colinclark> What's new with you, thealphanerd?

[14:31:49 CST(-0600)] <thealphanerd> swamped with work

[14:31:53 CST(-0600)] <thealphanerd> trying to keep up

[14:32:03 CST(-0600)] <thealphanerd> I got a chance to talk with yann from grame again

[14:32:10 CST(-0600)] <thealphanerd> and he is definitely interested in collaborating

[14:32:33 CST(-0600)] <thealphanerd> I'll send out an email to both of you to arange a skype meeting

[14:32:41 CST(-0600)] <colinclark> That sounds great

[14:32:53 CST(-0600)] <colinclark> Did you follow my last set of comments on OSC?

[14:32:53 CST(-0600)] <thealphanerd> I think I want to work out some of the osc details with you

[14:33:14 CST(-0600)] <thealphanerd> I did indeed… I need to take some time and really draw out where you want to take it

[14:33:24 CST(-0600)] <thealphanerd> and what I'm thinking would be good to accomplish

[14:33:50 CST(-0600)] <thealphanerd> I was thinking something along the lines of architecture files (like done in skype) might be a good solution

[14:34:04 CST(-0600)] <colinclark> ?

[14:34:16 CST(-0600)] <Justin_o> colinclark: yes.. that's what I think

[14:34:43 CST(-0600)] <colinclark> I was thinking it might be very helpful if you tried to sketch out some concrete examples for your "user interface binding markup" idea, thealphanerd.

[14:34:44 CST(-0600)] <Justin_o> colinclark: we might also want to decide on somewhere to store graphics and things like that, although the documentation will probably be light on those

[14:35:11 CST(-0600)] <colinclark> Like, create a few synths, and sketch a few UIs (even just on paper), and then illustrate how they need to be bound together

[14:35:19 CST(-0600)] <thealphanerd> that's a good idea

[14:35:45 CST(-0600)] <colinclark> I suspect that issue of adding OSC support is largely separate from the idea of synth <> UI bindings

[14:35:51 CST(-0600)] <colinclark> brb

[15:03:29 CST(-0600)] <colinclark> thealphanerd: Sorry, I'm back

[15:03:34 CST(-0600)] <thealphanerd> sigh

[15:03:56 CST(-0600)] <colinclark> I can imagine the conversation with Yann might go particularly well if you can illustrate your ideas with examples

[15:04:03 CST(-0600)] <thealphanerd> indeed

[15:04:05 CST(-0600)] <colinclark> plus, it'll be fun

[15:04:14 CST(-0600)] <thealphanerd> also I think the synth <> ui binding

[15:04:16 CST(-0600)] <thealphanerd> and the osc support

[15:04:24 CST(-0600)] <thealphanerd> are much more integrated than you were implying

[15:04:37 CST(-0600)] <thealphanerd> well it will be and won't be.

[15:04:52 CST(-0600)] <colinclark>

[15:04:55 CST(-0600)] <thealphanerd> I think it would be the same basic model representation… just different ways of inturpreting the model

[15:05:33 CST(-0600)] <colinclark> I don't disagree with that idea at all, in principle. I just can't quite picture it without some concrete examples that unite the two

[15:05:48 CST(-0600)] <thealphanerd> definitely… and I'll try and find time sooner than later to sketch that out

[15:05:53 CST(-0600)] <thealphanerd> but I've been drowning over here

[15:05:56 CST(-0600)] <colinclark> no worries at all

[15:05:58 CST(-0600)] <colinclark> I know the feeling

[15:06:07 CST(-0600)] <thealphanerd> I have to implement a crash reporter this week

[15:06:10 CST(-0600)] <thealphanerd> and a heap next week

[15:06:21 CST(-0600)] <thealphanerd> plus finish a ton of dsp homework I am behind on

[15:06:28 CST(-0600)] <thealphanerd> and finish my bike wheel installation

[15:06:46 CST(-0600)] <colinclark> That'll be cool to see--I hope you'll have some documentation

[15:06:59 CST(-0600)] <thealphanerd> all while trying to sort out summer job stuff (both where to work, and how to do so legally(

[15:07:11 CST(-0600)] <thealphanerd> colinclark: I already have some… it got covered make the make blog!

[15:07:26 CST(-0600)] <thealphanerd> http://blog.makezine.com/2013/02/19/sound-makers-unite-at-stanford/

[15:07:28 CST(-0600)] <colinclark> I've been sonifying the tides in San Diego with Flocking recently, which has turned out to be interesting. Though as Bosmon can attest, not yet as interesting as one would hope.

[15:08:57 CST(-0600)] <colinclark> these are really cool-looking instruments, thealphanerd

[15:09:01 CST(-0600)] <thealphanerd> colinclark: I think it would also be interesting to examine making an architecture file for faust -> flocking

[15:09:11 CST(-0600)] <colinclark> What is an architecture file?

[15:09:15 CST(-0600)] <thealphanerd> side bar

[15:09:23 CST(-0600)] <thealphanerd> julius is interested in sitting in on our meeting with yann

[15:09:43 CST(-0600)] <thealphanerd> so faust works with architecture files to go from faust -> your architecture

[15:10:39 CST(-0600)] <colinclark> I guess one of the things that might be equally interesting, if not more so, is to go the other way--i.e. from Flocking to Faust

[15:10:44 CST(-0600)] <thealphanerd> so julius was saying he wrote the ones for supercollider, that could compile faust code to a supercollider ugen or synthdef

[15:10:59 CST(-0600)] <colinclark> given that the whole goal of Flocking is to break out of the whole code generation paradigm

[15:11:17 CST(-0600)] <thealphanerd> colinclark: I was not aware of that goal...

[15:11:40 CST(-0600)] <Bosmon> colinclark - I thought it was perfectly interesting

[15:11:44 CST(-0600)] <thealphanerd> but I was thining an architecture file to flocking ugen would be a great way to port over a ton of lower level ugens that are currecntly missing

[15:11:47 CST(-0600)] <colinclark> It's right on the home page

[15:11:58 CST(-0600)] * thealphanerd rereads

[15:12:02 CST(-0600)] <colinclark> "Unlike comparable synthesis libraries, Flocking is declarative. Unit generators are wired together using a simple JSON-based syntax, making it easy to save and share your synthesis algorithms in plain text. Send your synths via Ajax, save them for later using HTML5 local data storage, or parse them into formats compatible with other synthesis engines."

[15:12:58 CST(-0600)] <colinclark> By being declarative, you can DO things with Flocking synthDefs that you couldn't typically do with code

[15:13:05 CST(-0600)] <thealphanerd> ahhh

[15:13:07 CST(-0600)] <colinclark> Such as easily transform it into other formats

[15:13:10 CST(-0600)] <thealphanerd> so I think there was a misunderstanding

[15:13:11 CST(-0600)] <colinclark> or author it using a GUI tool

[15:13:26 CST(-0600)] <thealphanerd> with an architecture file, one would not be compiling every time

[15:13:38 CST(-0600)] <thealphanerd> it would be more to generate js code that can run on the web audio api

[15:13:38 CST(-0600)] <colinclark> Without having to be stuck in the usual either/or dynamic--i.e. "Either GUI or code"

[15:13:49 CST(-0600)] <colinclark> Faust already does this

[15:13:51 CST(-0600)] <colinclark> right?

[15:13:54 CST(-0600)] <thealphanerd> yup

[15:14:00 CST(-0600)] <thealphanerd> so the idea would be to take it a step futher

[15:14:16 CST(-0600)] <thealphanerd> and have it generate code that can be dropped into the flocking name space

[15:15:13 CST(-0600)] <colinclark> I guess you mean that it could generate a Flocking unit generator?

[15:15:17 CST(-0600)] <thealphanerd> exactly

[15:15:50 CST(-0600)] <thealphanerd> with all the correct parts properly broken out

[15:18:17 CST(-0600)] <colinclark> That would be interesting to do, as would the reverse

[15:20:04 CST(-0600)] <thealphanerd> I'm not entirely sure the reverse would be easily implemented

[15:20:23 CST(-0600)] <thealphanerd> afaik faust is purely functional… everything is a signal

[15:20:35 CST(-0600)] <colinclark> How does that differ from Flocking?

[15:20:38 CST(-0600)] <thealphanerd> and it doesn't run by itself.. it needs to be compiled to another platform to be executed

[15:20:51 CST(-0600)] <colinclark> yes, exactly

[15:21:32 CST(-0600)] <thealphanerd> well I guess the latter would be easier to implement once the former is done

[15:21:39 CST(-0600)] <thealphanerd> go from faust -> flocking ugen

[15:21:54 CST(-0600)] <thealphanerd> then if the ugens originate from faust it shouldn't be hard to go from flocking -> fuast

[15:22:05 CST(-0600)] <thealphanerd> and use flocking to tie everything together

[15:22:07 CST(-0600)] <colinclark> I don't think that's the case

[15:22:43 CST(-0600)] <colinclark> The point is that a Flocking synthDef represents the "instructions to create an interconnected set of signals"

[15:22:54 CST(-0600)] <colinclark> it says nothing about how those unit generators are implemented

[15:23:28 CST(-0600)] <colinclark> So, have a look at one of the examples in the Flocking Playground: http://www.flockingjs.org/demos/interactive/html/playground.html

[15:23:42 CST(-0600)] <colinclark> And if you look at it closely, you'll notice that there's really nothing there except a set of names

[15:24:14 CST(-0600)] <thealphanerd> yup

[15:24:23 CST(-0600)] <colinclark> So take a line like this:

[15:24:29 CST(-0600)] <colinclark> ugen: "flock.ugen.sinOsc"

[15:24:44 CST(-0600)] <colinclark> This says nothing more than "give me a table-based sine wave oscillator"

[15:24:59 CST(-0600)] <colinclark> It never, for example, describes how the oscillator itself is implemented

[15:25:06 CST(-0600)] <colinclark> Moreover, unlike Faust, it's not code

[15:25:22 CST(-0600)] <colinclark> which means someone can pick it up and modify it

[15:25:32 CST(-0600)] <colinclark> since it is just JSON

[15:25:41 CST(-0600)] <colinclark> and follows a standard set of rules for interpreting it

[15:26:07 CST(-0600)] <colinclark> So, at least in principle, this enables someone to write a "translate" from this format to someone else's code

[15:26:14 CST(-0600)] <colinclark> e.g. Faust or SuperCollider or ChucK or whatever

[15:26:59 CST(-0600)] <thealphanerd> ok I'm following

[15:27:15 CST(-0600)] <colinclark> Of course, there is no current machinery to do any kind of translation of this sort

[15:27:25 CST(-0600)] <colinclark> but it's highly amenable to such things

[15:29:44 CST(-0600)] <colinclark> I guess the difference between Faust and Flocking, in principle, is that Faust attempts to be a "universal language," in the sense that it expects that all code starts in the Faust language, and then gets emitted using its code generators in some other language or runtime.

[15:30:13 CST(-0600)] <thealphanerd> colinclark: that is not to say there are not abstractions above faust

[15:30:48 CST(-0600)] <thealphanerd> edgar berdghal is working on a project called "synth-a-modler"… a visually based lanugage that compiles to faust

[15:31:08 CST(-0600)] <colinclark> Whereas Flocking-Bosmon will laugh at this somewhat, since I have been overusing the metaphor-attempts to be a "common meeting point" where a transparent, highly regular JSON structure can facilitate very different ways of creating synthesis algorithms, from graphical authoring tools to "live coding languages" to ordinary text editors (all going both directions)

[15:31:09 CST(-0600)] <thealphanerd> it is used for creating strings / haptics

[15:31:54 CST(-0600)] <thealphanerd> care to elaborate on "graphical authoring tools"

[15:32:13 CST(-0600)] <colinclark> Max and PD are the obvious examples

[15:32:24 CST(-0600)] <colinclark> except that they basically say "it's all or nothing"

[15:32:31 CST(-0600)] <colinclark> meaning, you either use their editor, or you don't use them at all

[15:32:48 CST(-0600)] <colinclark> Whereas Flocking takes the same sort of approach as Infusion

[15:32:58 CST(-0600)] <colinclark> where we envision an ecosystem of tools

[15:33:10 CST(-0600)] <colinclark> from GUI editors to new kinds of debuggers, etc.

[15:34:27 CST(-0600)] <thealphanerd> ahhh

[15:34:37 CST(-0600)] <thealphanerd> allowing you to create a visual tool that will then modify the json

[15:34:47 CST(-0600)] <thealphanerd> although funny enough… a max patch is a json

[15:36:43 CST(-0600)] <colinclark> I guess that's a Max 5 feature. That's very smart of them.

[15:37:11 CST(-0600)] <colinclark> The question is, can programs reasonably parse and work with the format, other than Max itself?

[15:37:36 CST(-0600)] <colinclark> hopefully they can

[15:39:17 CST(-0600)] <thealphanerd> I've edited them by hand

[15:39:20 CST(-0600)] <thealphanerd> so they are parsable

[15:39:55 CST(-0600)] <Bosmon> thealphanerd - that isn't really the kind of parseability we mean

[15:40:03 CST(-0600)] <Bosmon> The question is, what tooling is required to parse them

[15:40:08 CST(-0600)] <thealphanerd> ahhh

[15:40:19 CST(-0600)] <thealphanerd> well the big issue with the max json format is that every object has placement data

[15:40:26 CST(-0600)] <thealphanerd> as placement is used to determine order

[15:40:27 CST(-0600)] <colinclark> It's not a crazy format, but I imagine it gets unwieldy very fast

[15:40:30 CST(-0600)] <Bosmon> Ironically, making things machine-readable is actually much harder than making things human-readable

[15:40:33 CST(-0600)] <colinclark> yes, for exactly that reason, thealphanerd

[15:40:38 CST(-0600)] <colinclark> http://music.arts.uci.edu/dobrian/Music215W11/MaxPatches/Ex04-audioamplitude.maxpat

[15:40:53 CST(-0600)] <colinclark> You can see that there is so much presentation mixed with "logic"

[15:41:08 CST(-0600)] <colinclark> But this is much more progressive than the old days of Max, and likely PD still

[15:41:09 CST(-0600)] <thealphanerd> indeed… but with that being said presentation is indeed part of the logic

[15:41:13 CST(-0600)] <Bosmon> Much badness

[15:41:17 CST(-0600)] <Bosmon> Much bad wind, many flies

[15:41:31 CST(-0600)] <colinclark> I don't think that is the case, in reality, thealphanerd

[15:41:41 CST(-0600)] <colinclark> It's just that Max took the approach early on not to separate these concepts

[15:41:53 CST(-0600)] <colinclark> It's the biggest weakness right now of Faust, as I best as I can tell, too

[15:42:12 CST(-0600)] <thealphanerd> how so?

[15:42:18 CST(-0600)] <colinclark> I was telling Bosmon about a fascinating exchange I saw on the Faust mailing list today

[15:42:24 CST(-0600)] <colinclark> Which went roughly like:

[15:43:32 CST(-0600)] <colinclark> User: "I tried to use this Faust patch, but on my screen some of the UI widgets were place off the edge of the screen. My screen resolution is x by y pixels."

[15:43:58 CST(-0600)] <colinclark> Patch developer: "Oops, sorry. My screen resolution is x^2 by y^2, so I never noticed."

[15:44:13 CST(-0600)] <colinclark> Whereas, as you know well, the web provides a model for contending with these kinds of issues

[15:44:31 CST(-0600)] <colinclark> Specifically by providing a means for separating presentation

[15:44:54 CST(-0600)] <thealphanerd> well presentation is somewhat seperated

[15:45:04 CST(-0600)] <thealphanerd> you are not tied to a specific presentation mode with faust

[15:45:07 CST(-0600)] <colinclark> More interestingly, Faust's mixing of UI with DSP concerns has caused portability problems as they extend further from their "home base" of C++ and QT

[15:45:25 CST(-0600)] <colinclark> So if you look at the JavaScript generator, they say specifically that any patches with UI widgets in them likely won't work

[15:45:48 CST(-0600)] <colinclark> Whereas if they had done something more like what I think you are proposing

[15:45:58 CST(-0600)] <colinclark> which is to separate the connection between a synth and its UI

[15:45:58 CST(-0600)] <thealphanerd> I guess I need to look at the code a bit more… I was not under the impression that ui widgets were embedded in the code

[15:46:16 CST(-0600)] <colinclark> they could have much more sophisticated generators, including ones that use CSS, HTML, or something like, say, jQuery UI

[15:46:27 CST(-0600)] <colinclark> I can't load their online examples page at the moment

[15:46:31 CST(-0600)] <colinclark> otherwise we could take a look

[15:46:44 CST(-0600)] <thealphanerd> I think they are open to change though

[15:46:44 CST(-0600)] <colinclark> I could be wrong--this is just my impression from quickly scanning a few .dsp files

[15:46:57 CST(-0600)] <colinclark> I'm sure they are--more so now that they're trying to adapt to the web, I imagine

[15:47:01 CST(-0600)] <thealphanerd> colinclark: in the .dsp files there is the faust code, and the architecture model

[15:47:14 CST(-0600)] <colinclark> and please don't misinterpret me--it's not that I'm knocking Faust at all

[15:47:14 CST(-0600)] <thealphanerd> I was under the impression that the ui stuff was in the model

[15:47:22 CST(-0600)] <colinclark> just weighing the strengths and the weaknesses

[15:47:46 CST(-0600)] <thealphanerd> colinclark: definitely… appreciating the insight… I'm still fairly green with all of this

[15:48:55 CST(-0600)] <colinclark> To be clear, even Flocking suffers from some of this problematic mixing--hence the need to break out the "browser ugens" https://github.com/colinbdclark/Flocking/blob/infusion/flocking/flocking-ugens-browser.js

[15:49:23 CST(-0600)] <colinclark> but with time, there will be a much firmer separation throughout

[15:49:34 CST(-0600)] <thealphanerd> btw

[15:49:38 CST(-0600)] <thealphanerd> speaking of visuals

[15:49:49 CST(-0600)] <thealphanerd> I think we should explore d3 for data vis of the sound

[15:49:57 CST(-0600)] <colinclark> Cool

[15:50:04 CST(-0600)] <thealphanerd> have you looked at it much?

[15:50:11 CST(-0600)] <colinclark> There was a lot of D3 talk last week at the architecture meetings we had

[15:50:33 CST(-0600)] <colinclark> sgithens has started on an early prototype of a graphical authoring tool for "Kettle" components using, I think, D3

[15:50:53 CST(-0600)] <thealphanerd> let me find this one presentation I have that's great

[15:52:09 CST(-0600)] <thealphanerd> scottcheng.github.com/d3js-101/

[15:52:36 CST(-0600)] <thealphanerd> what is really neat is the way it can generate visuals based on incoming data streams

[15:54:24 CST(-0600)] <colinclark> Looks cool, the alphanerd

[15:55:01 CST(-0600)] <thealphanerd> but ok.. we are getting a bit off topic I think. So I think a good start would be for me to find a way to better represent my idea

[15:55:13 CST(-0600)] <thealphanerd> with some visual examples / code-examples

[15:55:33 CST(-0600)] <colinclark> Yup, I think that makes sense

[15:55:40 CST(-0600)] <colinclark> It will be very cool, I'm quite certain

[15:56:17 CST(-0600)] <thealphanerd> have you used osc much before?

[15:56:57 CST(-0600)] <colinclark> Mostly just in SuperCollider

[15:57:04 CST(-0600)] <colinclark> very little, really

[15:57:25 CST(-0600)] <colinclark> I spent a couple days studying the OSC documentation last week so that I could best understand the issues involved

[15:57:29 CST(-0600)] <thealphanerd> trying to look at your example

[15:57:47 CST(-0600)] <thealphanerd> the one thing I would say though… is I don't know if the "getter / setter" mentality really works for osc

[15:57:49 CST(-0600)] <thealphanerd> imho

[15:58:07 CST(-0600)] <colinclark> What do you mean, specifically?

[15:59:25 CST(-0600)] <thealphanerd> so you say in your last comment

[15:59:29 CST(-0600)] <thealphanerd> things that would be good for osc

[15:59:34 CST(-0600)] <thealphanerd> create a new named synth

[15:59:37 CST(-0600)] <thealphanerd> set and get input values

[15:59:41 CST(-0600)] <thealphanerd> send osc message to another process

[15:59:59 CST(-0600)] <colinclark> yes

[16:00:09 CST(-0600)] <thealphanerd> you also gave some examples of the adress

[16:00:18 CST(-0600)] <thealphanerd> "/s_new" / "s_free"

[16:00:27 CST(-0600)] <thealphanerd> now I would argue that these are not good uses of osc

[16:00:46 CST(-0600)] <thealphanerd> unless you are going to be looking at using the tcp version of osc… which is not widely supported

[16:00:51 CST(-0600)] <colinclark> That's the SuperCollider OSC messaging convention

[16:01:05 CST(-0600)] <thealphanerd> lol

[16:01:20 CST(-0600)] <colinclark> I'm not sure how UDP vs. TCP plays into it

[16:01:23 CST(-0600)] <thealphanerd> well the way I've looked at osc… mostly from monome… is that it is a data stread

[16:01:25 CST(-0600)] <thealphanerd> stream

[16:01:36 CST(-0600)] <colinclark> sure

[16:01:41 CST(-0600)] <colinclark> but what's in the stream?

[16:02:17 CST(-0600)] <thealphanerd> so when I think about what you would want to do with osc of a synth def I think of two very different cases

[16:02:26 CST(-0600)] <thealphanerd> input / output (set / get)

[16:02:37 CST(-0600)] <thealphanerd> but I view them as being the exact same messages

[16:02:40 CST(-0600)] <thealphanerd> just in different directions

[16:03:09 CST(-0600)] <colinclark> Can you unpack what you're thinking when you say "the exact same messages?"

[16:03:28 CST(-0600)] <thealphanerd> that there is no differentiation between the adress of a message to set and a message of state

[16:03:45 CST(-0600)] <thealphanerd> so if you were to say want to set the frequency of a synth you would feed it

[16:03:53 CST(-0600)] <thealphanerd> /synthname/freq 440

[16:04:14 CST(-0600)] <colinclark> yes, perhaps

[16:04:27 CST(-0600)] <colinclark> but the question is how you differentiate other actions that you might do on that particular node

[16:05:36 CST(-0600)] <colinclark> So, if the only thing you can ever do on a node is to get and set values on it, you're golden

[16:05:43 CST(-0600)] <colinclark> you can use this implicit style

[16:05:54 CST(-0600)] <colinclark> in REST, this would be exactly the sort URL convention you'd use

[16:06:05 CST(-0600)] <thealphanerd> so here is the thing I was saying about uses for osc

[16:06:09 CST(-0600)] <colinclark> because you have a separate way to express the action (e.g. GET/POST)

[16:06:15 CST(-0600)] <thealphanerd> now since osc is over udb you only have a single direction

[16:06:17 CST(-0600)] <thealphanerd> you get no response

[16:06:28 CST(-0600)] <thealphanerd> so if you are for example creating a synth… you have no way of knowing it worked

[16:06:36 CST(-0600)] <thealphanerd> unless you create a repsonse osc message

[16:06:41 CST(-0600)] <colinclark> yes, exactly

[16:06:43 CST(-0600)] <thealphanerd> and if you do that

[16:06:52 CST(-0600)] <thealphanerd> you are practically making a much jankier tcp

[16:07:07 CST(-0600)] <thealphanerd> in which case you are better off simply sending the restful request via tcp

[16:07:14 CST(-0600)] <colinclark> and that's exactly what anyone has to do in order to allow queries to be sent via OSC

[16:07:33 CST(-0600)] <colinclark> It's impossible to imagine that someone won't, at some time, want to be able to query the state of an OSC node

[16:07:50 CST(-0600)] <colinclark> So, you're right that typically one might avoid doing this

[16:07:59 CST(-0600)] <colinclark> and store state locally, or avoid storing state at all

[16:08:01 CST(-0600)] <thealphanerd> no if you want to query the nodes state

[16:08:02 CST(-0600)] <colinclark> for example, a controller

[16:08:06 CST(-0600)] <thealphanerd> there are other ways of doing it

[16:08:13 CST(-0600)] <colinclark> What are those ways, thealphanerd?

[16:08:30 CST(-0600)] <thealphanerd> so the way I've liked to do it in the past is having a frame buffer that sends out osc messages to a selected host

[16:08:58 CST(-0600)] <thealphanerd> so you could for example tell the osc server that you want a frame consisting of certain messages, at a specific frame rate

[16:09:06 CST(-0600)] <thealphanerd> then turn that message stream on and off

[16:09:27 CST(-0600)] <thealphanerd> so rather than polling you are turning on / off a stream of data

[16:09:54 CST(-0600)] <thealphanerd> and this is where I see the messages being identicle

[16:10:18 CST(-0600)] <colinclark> That sounds substantially less performant for cases where changes are periodic

[16:10:35 CST(-0600)] <thealphanerd> changes to the model?

[16:10:54 CST(-0600)] <thealphanerd> so the other possibility

[16:11:21 CST(-0600)] <colinclark> I probably should have used the word "occasional" rather than "periodic," to be clear

[16:11:22 CST(-0600)] <thealphanerd> is that rather than having a frame rate (which makes sense for certain things like polling sensors), that you want to have events trigger the messages

[16:11:59 CST(-0600)] <thealphanerd> colinclark: this would be the difference between wanting to know the state of a note being triggered rather than the state of an accelerometer

[16:12:36 CST(-0600)] <colinclark> Sure, that's fine for some cases

[16:12:49 CST(-0600)] <colinclark> but again, sometimes you just want to be able to say "hey, what's the frequency of this oscillator right now?"

[16:13:14 CST(-0600)] <colinclark> and if there's no means to do this, or equally problematically, each user has to roll their own ad-hoc bus for doing this, then that's a weakness

[16:13:49 CST(-0600)] <colinclark> To be clear, there's no reason not to support an OSC "event system"

[16:14:10 CST(-0600)] <thealphanerd> well there is also another possibility

[16:14:48 CST(-0600)] <thealphanerd> now if you are saying that someone might want the current state… well why then limit it to a particular synth def / variable

[16:15:11 CST(-0600)] <thealphanerd> you could have a message to get the entire state of the synthdef, and then parse it

[16:15:16 CST(-0600)] <colinclark> yes, exactly

[16:15:31 CST(-0600)] <colinclark> that's exactly how I interpret the semantics of a "container" in OSC

[16:15:45 CST(-0600)] <thealphanerd> ok so something that is worth exploring then is something that monome does as well (sorry broken fan boy record)

[16:15:52 CST(-0600)] <thealphanerd> each device registers its own server

[16:16:07 CST(-0600)] <thealphanerd> the server itself has a series of system messages that can be use to poll the current state

[16:16:13 CST(-0600)] <thealphanerd> and send that state to a desired address

[16:16:41 CST(-0600)] <colinclark> yes, I suspect that's the typical way that OSC "clients" implement this behaviour

[16:17:21 CST(-0600)] <thealphanerd> so you could in essence call the osc function on any synth def

[16:17:26 CST(-0600)] <colinclark> SuperCollider implements two things: an OSC UGen on the server, which can fire OSC messages to a client, and the OSCResponderNode on the client, which binds incoming OSC messages to functions in the language

[16:17:27 CST(-0600)] <thealphanerd> and get these default messages

[16:18:13 CST(-0600)] <colinclark> "these default message"--can you unpack this, just so I'm clear

[16:18:15 CST(-0600)] <colinclark> ?

[16:19:47 CST(-0600)] <thealphanerd> a series of default messages to poll the overall state of the synth def

[16:20:06 CST(-0600)] <colinclark> I think I understand, but keep going

[16:20:10 CST(-0600)] <thealphanerd> flocking itself could have a default server

[16:20:18 CST(-0600)] <thealphanerd> to poll and find out what synth defs and currently available

[16:20:33 CST(-0600)] <thealphanerd> we could potentially make use of mdns (avahi / bonjour) to broadcast services

[16:22:22 CST(-0600)] <colinclark> So, can you explain what you think the client would be asking the server for, in plain language?

[16:22:22 CST(-0600)] <thealphanerd> so in a hierarchy we could think of flocking server (default port) that is used to do admin stuff such as list synth defs / make synth def / destroy synth def

[16:22:51 CST(-0600)] <colinclark> Like, pretend I'm the Flocking server. What are the actions you'd want to ask me to do/

[16:23:12 CST(-0600)] <thealphanerd> so I could poll the flocking server and say "Hey what synths do you have running, and on what ports"

[16:23:35 CST(-0600)] <thealphanerd> and you get a list

[16:23:48 CST(-0600)] <thealphanerd> from that you say hey oscillating synth, what is your current state

[16:23:56 CST(-0600)] <colinclark> yes

[16:23:58 CST(-0600)] <colinclark> keep going

[16:24:09 CST(-0600)] <thealphanerd> and from there you can also update the state

[16:24:43 CST(-0600)] <thealphanerd> I think I need to draw this out

[16:24:49 CST(-0600)] <colinclark>

[16:24:53 CST(-0600)] <colinclark> I think this sounds really good

[16:25:01 CST(-0600)] <colinclark> I think that synths wouldn't run on ports

[16:25:07 CST(-0600)] <thealphanerd> I was just htinking that

[16:25:08 CST(-0600)] <colinclark> but rather, the Flocking server would

[16:25:11 CST(-0600)] <thealphanerd> they would have addresses

[16:25:30 CST(-0600)] <thealphanerd> although… you could run into problems with binding

[16:25:37 CST(-0600)] <thealphanerd> and it might be advantagious to have multiple ports

[16:25:53 CST(-0600)] <colinclark> What is the advantage, do you think?

[16:25:55 CST(-0600)] <thealphanerd> but I guess that is an output problem

[16:25:59 CST(-0600)] <thealphanerd> not an input problem

[16:26:06 CST(-0600)] <colinclark> I'd like to keep the messaging semantics as close to REST as possible, so that we can come up with other bindings in the future that are compatible (such as, well, a REST binding)

[16:26:20 CST(-0600)] <colinclark> So when I say "close to REST," I mean that we'd have a limited set of actions

[16:26:43 CST(-0600)] <colinclark> and use the address space to represent different resources (i.e. "things")

[16:27:00 CST(-0600)] <thealphanerd> I don't dissagree

[16:27:16 CST(-0600)] <colinclark> So, the server might have a container called "/synths," which if you "GET" it, you get the list of synths back

[16:27:42 CST(-0600)] <colinclark> Which is why, much as I would rather avoid it, I was thinking we'd have to model the address space as <thing>/<action>

[16:28:06 CST(-0600)] <thealphanerd> but with that being said… how many actions do you really have

[16:28:14 CST(-0600)] <colinclark> Hopefully only four

[16:28:20 CST(-0600)] <colinclark> or perhaps, really, only three

[16:28:26 CST(-0600)] <thealphanerd> I don't think that thing/action is neccessary

[16:28:43 CST(-0600)] <colinclark> I guess you could have a convention where the action was the first argument of the message?

[16:28:49 CST(-0600)] <thealphanerd> yup

[16:29:02 CST(-0600)] <colinclark> yes, that seems fine to me

[16:29:04 CST(-0600)] <thealphanerd> you can also parse messages differently depending on the argument type

[16:29:38 CST(-0600)] <thealphanerd> the problem with getters is that you need to have an ip / port to send to

[16:29:42 CST(-0600)] <thealphanerd> that is bound

[16:29:46 CST(-0600)] <thealphanerd> wait… not bound

[16:29:52 CST(-0600)] <thealphanerd> sorry about that

[16:30:05 CST(-0600)] <colinclark> Yeah, that part we'll need to roll ourselves

[16:30:08 CST(-0600)] <colinclark> as I assume everyone else does

[16:30:27 CST(-0600)] <thealphanerd> so i think there are really only two gets

[16:30:38 CST(-0600)] <colinclark> If I remember correctly, SuperCollider requires clients of "gets" to provide an IP address and port as part of the message

[16:30:41 CST(-0600)] <colinclark> but I may be wrong about that

[16:31:07 CST(-0600)] <thealphanerd> a "continious get" based on events

[16:31:21 CST(-0600)] <thealphanerd> and a "polling get" based on user request

[16:31:32 CST(-0600)] <colinclark> yes, when you mentioned that, i started to get interested

[16:31:41 CST(-0600)] <colinclark> I think what we can do is expose the Flocking scheduler as a node within the address space

[16:31:48 CST(-0600)] <colinclark> so you can schedule callbacks

[16:32:05 CST(-0600)] <colinclark> that should be pretty cool, and pretty straightforward

[16:32:32 CST(-0600)] <thealphanerd> so in a very basic way I think the "continious get" can be parsed from the exact same model we were discussing before

[16:32:46 CST(-0600)] <thealphanerd> the same model used for incoming osc / ui

[16:33:56 CST(-0600)] <thealphanerd> this would be useful for binding other environments to the changing state of a synth def

[16:34:12 CST(-0600)] <colinclark> seems reasonable to me

[16:34:19 CST(-0600)] <thealphanerd> turning these on and off could be worked into a message to the main server

[16:34:35 CST(-0600)] <thealphanerd> /synth/forward "ip" "port"

[16:35:43 CST(-0600)] <colinclark> yes, that sounds good

[16:35:45 CST(-0600)] <thealphanerd> and a list of forwards could be distributed in the model

[16:36:06 CST(-0600)] <colinclark> I guess we'll call them "message streams" or something

[16:36:08 CST(-0600)] <thealphanerd> you could also maybe do

[16:36:12 CST(-0600)] <colinclark> and actually model them as nodes, too

[16:36:21 CST(-0600)] <thealphanerd> /synth/node "name" "ip" "port"

[16:36:39 CST(-0600)] <thealphanerd> /synth/stop/node "name"

[16:36:53 CST(-0600)] <thealphanerd> or something… the messaging logistics can be sorted

[16:37:14 CST(-0600)] <thealphanerd> are you could do /synth/state "ip

[16:37:17 CST(-0600)] <thealphanerd> " "port"

[16:37:29 CST(-0600)] <thealphanerd> to send the current model of the synth to that ip and port

[16:42:32 CST(-0600)] <colinclark> Sorry, thealphanerd

[16:42:33 CST(-0600)] <colinclark> got booted from my room by the housekeeper

[16:42:38 CST(-0600)] <thealphanerd> haha

[16:42:41 CST(-0600)] <thealphanerd> tough life

[16:42:55 CST(-0600)] <colinclark> thealphanerd: I know you're busy, so no rush, but is there any chance you'd feel like documenting our discussion on the Github ticket?

[16:43:50 CST(-0600)] <thealphanerd> yeah… I'm going to dump the transcript and make some sense out of it

[16:43:58 CST(-0600)] <thealphanerd> I'll also mock up some diagrams on the white board

[16:44:07 CST(-0600)] <thealphanerd> and I'll embed those with the ticket

[16:44:13 CST(-0600)] <thealphanerd> might take me a bit to get to though

[16:45:24 CST(-0600)] <thealphanerd> I have to run now

[16:45:28 CST(-0600)] <thealphanerd> but I think this was a good talk

[16:45:36 CST(-0600)] <thealphanerd> thank you as always for taking the time!

[16:46:06 CST(-0600)] <colinclark> no rush

[16:46:08 CST(-0600)] <colinclark> it's always great to chat

[16:46:11 CST(-0600)] <colinclark> see you later!