#ofdev meeting april 30th 2012

[1:46pm] bilderbuchi: ;-)
[1:46pm] ofarturo: we could have a OFhistory with all the history and openFrameworks with the latest
[1:46pm] ofTheo: we just need to install all the libs in /usr/local right?
[1:46pm] elliotwoods: i wouldn't mind archiving the history now
[1:46pm] elliotwoods: i cant see why not rename existing as archive
[1:46pm] elliotwoods: and start in fresh repo
[1:46pm] gameover_: i know it's bad - but it's not too often you need to revert to a specific commit 2 years in the past
[1:46pm] bilderbuchi: fresh repo-different name. that's what i proposed already
[1:46pm] bilderbuchi: but it's another name
[1:46pm] damian0815: ofTheo: problem is that osx lacks a proper dynamic lib update mechanism.. no-one uses or understands 'frameworks'. windows is kind of worse
[1:47pm] bilderbuchi: OF2?
[1:47pm] elliotwoods: fresh repo
[1:47pm] elliotwoods: rename existing
[1:47pm] elliotwoods: why not?
[1:47pm] kylemcd: [just got a text msg from james george, his plane landed late, he'll be late]
[1:47pm] damian0815: ichy ichy
[1:47pm] ofarturo: ofTheo no with the source repo the libraries binaries will be uploaded somewhere and will be pulled to local with some script to the same place they are now
[1:47pm] bilderbuchi: why not - cause it won't be transparent for people using OF as a remote, if the address stays the same. they pull. inconsistencies with their local history. boom
[1:47pm] ofTheo: but somewhere not being GH?  I guess thats the whole point .
[1:48pm] kylemcd: ofarturo but the repo won't actually host the source right? maybe that's ok for oscpack, but not opencv...?
[1:48pm] bilderbuchi: yes. if we put all thebinaries into a GH repo, we just shift the problem.
[1:48pm] bilderbuchi: we could just uplaod to the OF-GH site, though
[1:48pm] damian0815: @bilderbuchi is right
[1:48pm] ofarturo: yes cause if not we wont' have history of external libraries and will be impossible to go back to 006 for example
[1:48pm] bilderbuchi: it allows additional uploads
[1:48pm] damian0815: i'm thinking about my ARMel projects from 1.5 years ago
[1:49pm] elliotwoods: @bilderbuchi - what happens then? they get an error
[1:49pm] elliotwoods: ?
[1:49pm] elliotwoods: so they can't pull
[1:49pm] damian0815: + the pain & confusion that would be associated with updating them
[1:49pm] ofarturo: but thinking of it the partial repo is perhaps an easier solution
[1:49pm] elliotwoods: that sounds reasonable enough
[1:49pm] kylemcd: i imagined it like this: we make a new repo that just has scripts for downloading + building libs,
[1:49pm] ofTheo: just saw this: http://stackoverflow.com/a/6635160/1339816
[1:49pm] bilderbuchi: i guess they pull and destroy their repo. at least that's implied everywhere. haven'T tried personally yet
[1:49pm] ofTheo: git annex
[1:50pm] kylemcd: then we build all those libs for each release, and post a download .zip in the downloads/ section of the repo
[1:50pm] kylemcd: like i did here when 2.3.1 was not yet in the OF repo https://github.com/kylemcdonald/ofxCv/downloads
[1:50pm] joshuajnoble: wow, git-annex
[1:50pm] damian0815: hey here's an idea
[1:50pm] damian0815: we make Develop a different repo
[1:50pm] elliotwoods: @ofTheo - is that only for saving local storage?
[1:50pm] kylemcd: and then the main OF repo has a script that downloads and unzips those libs
[1:50pm] damian0815: we import history from develop into master on a release
[1:50pm] bilderbuchi: i already read about git-annex. forgot about it, wasn't fitting my problem at the time. should probably read agiain :-)
[1:50pm] ofTheo: @elliotwoods - still reading :)
[1:50pm] damian0815: but develop is the repo that gets trashed and rebuild every release
[1:51pm] damian0815: so for day-to-day dev we can have one repo; master gets bigger and bigger and bigger but we don't work from it so it's less of a problem
[1:52pm] kylemcd: damian0815 if the releases are often, that sounds like a pain
[1:52pm] bilderbuchi: the problem isn't working from it, but committing binaries..
[1:52pm] ofTheo: it looks like it allows you to do version control on large files but only commit the symlink to the git repo
[1:52pm] elliotwoods: so we have 2 points : 1
[1:52pm] elliotwoods: 1 what to do with our history
[1:52pm] damian0815: if the problem isn't wroking from it, what's wrong if it gets bigger and bigger?
[1:52pm] elliotwoods: 2 what to do in the future
[1:53pm] elliotwoods: it sounds like delaying a problem
[1:53pm] elliotwoods: rather than fixing it
[1:53pm] bilderbuchi: damian: cause elliot complains if he has to DL OF in korea ;-)
[1:53pm] damian0815: hah
[1:53pm] damian0815: ok
[1:53pm] ofTheo: is there a way to clone without get the whole history?
[1:53pm] kylemcd: doesn't korea have like the worlds fastest internet?
[1:54pm] bilderbuchi: @theo yes but you can't work with it anymor
[1:54pm] ofTheo: can't we just make a custom clone link?
[1:54pm] bilderbuchi: i.e. no branching, pushing, etc
[1:54pm] bilderbuchi: elliott already did that i thinkg
[1:54pm] ofTheo: oh thats crazy
[1:54pm] elliotwoods: @kylemcd : yes, but not actually to anywhere outside korea :)
[1:54pm] kylemcd: yeah, it's called a "shallow clone"
[1:54pm] elliotwoods: everyone's on naver
[1:54pm] ofarturo: yes actually having binaries in repositories is not a good practice
[1:54pm] elliotwoods: i did that last time to work on a project htere
[1:54pm] ofTheo: we just need the mega ofOSXLibs.a ofWINLibs.a solution :)
[1:55pm] ofarturo: when we asked github for more space because we had the binaries they said we should just not have the binaries there
[1:55pm] bilderbuchi: so you carry a USB stick, now, elliott? :-D
[1:55pm] elliotwoods: anyway, it's not about me
[1:55pm] ofTheo: I know :)
[1:55pm] kylemcd: ofarturo lol
[1:55pm] ofTheo: but its so nice
[1:55pm] ofarturo: :D
[1:55pm] ofTheo: github should just partner with dropbox
[1:55pm] ofarturo: hahah
[1:55pm] bilderbuchi: it's because git can't compress them efficiently, as opposed to text contetn
[1:55pm] elliotwoods: let's just use dropbox
[1:55pm] elliotwoods: fuck git
[1:55pm] ofTheo: use symlinks internally and then let you do a fetch binary command
[1:55pm] jvcleave: svn
[1:56pm] elliotwoods: always up to date
[1:56pm] elliotwoods: (jk)
[1:56pm] gameover_: lol
[1:56pm] elliotwoods: 5GB repos
[1:56pm] ofTheo: worlds largest dropbox
[1:56pm] elliotwoods: hmm
[1:56pm] bilderbuchi: dropbox has interesting ramifications if used across OSes
[1:56pm] kylemcd: 1 we need to stick the libs somewhere not version controlled 2 we need to automate downloading them 3 we need to automate building them
[1:56pm] gameover_: new folder for every commit
[1:56pm] elliotwoods: but.... what about using something like dropbox for the libs
[1:56pm] bilderbuchi: i have some super weird problems with changed files I can't see
[1:56pm] ofarturo: at reactable we had an extern repo with the source for all the libraries and scripts to build them that repo can even be in OF/libs
[1:56pm] elliotwoods: we dont really care about history etc
[1:56pm] bilderbuchi: with dropbox&git
[1:56pm] elliotwoods: we just want a playground to build
[1:56pm] damian0815: kylemcd: +1 to all
[1:56pm] ofarturo: for most people you don't need a repo just a script that pulls the binaries from somewhere
[1:57pm] ofTheo: one thing I think we can agree on is that we can start storing libs somewhere else
[1:57pm] ofTheo: lets get that working
[1:57pm] kylemcd: 1 let's host it on openframeworks.cc 2 download automation with shell scripts or python 3 building automation with a new github version control
[1:57pm] ofzach: +1
[1:57pm] bilderbuchi: kylemcd: +1 to all
[1:57pm] ofarturo: yes we need that anyway
[1:57pm] damian0815: bilderbuchi: i have scenarios where i have ssh but i don't have internet, i need to be able to do this stuff without internet
[1:57pm] ofTheo: and then lets look at how to slim down GH
[1:57pm] bilderbuchi: yes
[1:57pm] kylemcd: er 3 building automation with a new GH repo
[1:57pm] bilderbuchi: +1 theo
[1:57pm] kylemcd: ok great, decisions made
[1:57pm] damian0815: bilderbuchi: which rules out drobpox
[1:57pm] kylemcd: let me make this note in the piratepad
[1:57pm] ofarturo: and once we have that removing the libraries from the source repo won't be so problematic
[1:58pm] elliotwoods: so the download script downloads the relevant libs
[1:58pm] elliotwoods: i mean
[1:58pm] elliotwoods: the version of the libs that match the commit
[1:58pm] bilderbuchi: yes@arturo,kyle, sonunds good
[1:58pm] elliotwoods: vvvv does this with hooks
[1:59pm] ofarturo: let's try to have a repo with all the external libraries + tools to build them once we see how that works we can decide to remove binaries
[1:59pm] bilderbuchi: yes, just don't have binaries in the repo, otherwise we just move the problem
[1:59pm] ofTheo: :)
[1:59pm] ofarturo: yes of course
[1:59pm] kylemcd: ok, just wrote notes at the bottom of the piratepad, can everyone check that it's describing things right?
[2:00pm] kylemcd: random question: does anyone using windows find it painful to run a python script?
[2:00pm] bilderbuchi: i dont get 3)
[2:00pm] bilderbuchi: why do we need this?
[2:00pm] bilderbuchi: would also work out of OF repo, no?
[2:00pm] elliotwoods: just make bash scripts
[2:00pm] kylemcd: #3 is important to maintain our collective knowledge of library-building, and in order to make it easier to automate building new libs
[2:01pm] gameover_: @kylemcd: it can be painful to install python - once it's there it's easy
[2:01pm] elliotwoods: https://github.com/elliotwoods/vvvv-sdk/blob/develop/scripts/fetch-binaries
[2:01pm] elliotwoods: no bother with python
[2:01pm] elliotwoods: just use bash
[2:01pm] elliotwoods: everyone's already got it
[2:01pm] kylemcd: but is bash running on windows? via cygwin or what?
[2:01pm] bilderbuchi: @3) ok
[2:01pm] ofarturo: ok can we move to 4?
[2:01pm] elliotwoods: yeahp
[2:01pm] elliotwoods: git requires a minimum system
[2:01pm] kylemcd: ok great
[2:01pm] kylemcd: done!
[2:01pm] kylemcd: next
[2:01pm] elliotwoods: eg cygwin/minisys
[2:01pm] gameover_: could we use the git command line on win - is that bash?
[2:02pm] kylemcd: #4. Query: Mechanism to document user-visible API changes for a changelog? (Christoph)
[2:02pm] elliotwoods: yes it is
[2:02pm] elliotwoods: check that url
[2:02pm] bilderbuchi: it's mingw normally matt
[2:02pm] gameover_: that would be ace!
[2:02pm] elliotwoods: that's the script run atuomatically in the vvvv repo
[2:02pm] bilderbuchi: afaik
[2:02pm] elliotwoods: under windows
[2:02pm] ofzach: goit command on windows is bash, and nice
[2:02pm] kylemcd: :)
[2:02pm] elliotwoods: + you have things like curl for downloading
[2:02pm] elliotwoods: so no troubles dragging down binaries
[2:03pm] gameover_: +1 to oF using the git command line instead of python ;-)
[2:03pm] kylemcd: christoph what was your thought on #4?
[2:03pm] ofarturo: 4: the documentation in the web should be able to do something like that with sme modifications
[2:03pm] kylemcd: ok, i removed the bit about python :)
[2:03pm] bilderbuchi: #4: yeah, i just wanted to know if we currently have/want an automated way to document user-visible changes to the API for a changelog
[2:03pm] ofarturo: right now it's marking new functions with the current version number
[2:03pm] bilderbuchi: or if someone slogs through one year of commit msgs for that?
[2:03pm] elliotwoods: wait
[2:03pm] elliotwoods: for 4
[2:03pm] elliotwoods: only 1 needs to be done
[2:04pm] ofarturo: yes if there could be some script to generate the changelog that would be useful
[2:04pm] kylemcd: elliotwoods yeah, you're correct
[2:04pm] elliotwoods: from commit messages?
[2:04pm] elliotwoods: or from diff
[2:04pm] bilderbuchi: idk how that would work though. was basically just curious how TAZ have been doing it in the past.
[2:05pm] kylemcd: in the past the changes have been few enough / contributed by a smaller number of people, so they can actually be listed by hand
[2:05pm] bilderbuchi: or 4 08:03:51 PM
[2:05pm] bilderbuchi: only 1 needs to be done
[2:05pm] bilderbuchi: no because the binaries are still in the history!
[2:05pm] kylemcd: the 007 changelog looked the hardest so far because it was coming from a lot of different places :)
[2:05pm] bilderbuchi: anyway, we'll discuss this on the list or whatever
[2:06pm] kylemcd: yeah, bottom line: it would be great to have that automated
[2:06pm] kylemcd: next
[2:06pm] bilderbuchi: ok. so do we have a plan for the future?
[2:06pm] bilderbuchi: ok. nvm then
[2:06pm] bilderbuchi: next
[2:06pm] kylemcd: #5. ofPath and curves (damian)
[2:06pm] damian0815: yeah
[2:06pm] damian0815: ofPath is weird
[2:06pm] damian0815: it should be less weird
[2:06pm] damian0815: everyone read my email right?
[2:06pm] kylemcd: yess
[2:06pm] damian0815: any complaints to my proposal for magic auto-bezier handles and smartness?
[2:07pm] damian0815: (easy to disable obviously)
[2:07pm] ofarturo: i think what keith suggested about having the option to choose between automatically add points to make it look good or being corrent for the algorithm is the way to go
[2:07pm] ofarturo: path.setAlwaysLookGood(true) :)
[2:07pm] damian0815: i was thinking
[2:07pm] bilderbuchi: i mostly agreed with the points keith made
[2:07pm] damian0815: path.curveTo( outPoint, bCalculateForNiceness=true )
[2:07pm] damian0815: and
[2:08pm] ofTheo: would keith's code be backwards compatible?
[2:08pm] ofarturo: yes
[2:08pm] ofTheo: nice
[2:08pm] ofarturo: if you disable alwaysLookGood it should be the same as it is now
[2:08pm] ofTheo: oh
[2:08pm] damian0815: similar for beziers, with optional different methods for automatically calculating in and out control points for continuity of curves
[2:08pm] damian0815: ofarturo: but what it is now is broken
[2:08pm] ofTheo: but if you are adding the extra points and run the new approach will it also handle that well?
[2:09pm] ofzach: I think it would be good if the default did what the system does now, and you can opt into magic
[2:09pm] ofTheo: + an example to show the difference
[2:09pm] ofTheo: might be good
[2:09pm] kylemcd: yeah, what would be the best way to "enable" this?
[2:09pm] kylemcd: ofEnableDamiansPaths()
[2:10pm] ofTheo: similar approach to arb?
[2:10pm] kylemcd: ofSetPathMode(OF_DAMIAN)
[2:10pm] damian0815: ofZach: newbies won't know there's a magic
[2:10pm] damian0815: hah
[2:10pm] imkeith: ofEnableSexy()
[2:10pm] ofzach: @damian0815 that's for examples and documentation
[2:10pm] damian0815: i think  OF_DAMIAN should be default
[2:10pm] damian0815: mmmm
[2:10pm] elliotwoods: ofxBeforeDamian
[2:11pm] ofTheo: for some stuff we have a global call and an object based call
[2:11pm] ofarturo: yes even with that enabled it won't broke most of the code only exceptional cases
[2:11pm] bilderbuchi: keith any thoughts?
[2:11pm] damian0815: when me + arturo were discussing this, arturo pointed out that ofPath is still new enough that we can change it
[2:11pm] damian0815: the big problem is that you can switch path types in the middle of a path definition
[2:11pm] damian0815: which you couldn't do with ofCurveVertex &co
[2:11pm] ofzach: if it's transparent to users, I'm ok with it
[2:11pm] ofarturo: te only cases where it changes is when you pass less points that catmull rom is expecting and things like that
[2:11pm] damian0815: i don't think many users actually rely on the broken behaviour
[2:12pm] ofarturo: so the rendering for most programs wont change
[2:12pm] ofzach: just the polygon example has double up points, etc.. maybe that needs to change ?
[2:12pm] kylemcd: i vote for making things better by default, even if there are some super obscure edge cases
[2:12pm] damian0815: if you say lineto - curveto - lineto
[2:12pm] damian0815: then it should be smooth and nice looking
[2:12pm] damian0815: i can't see anyone complaining about that
[2:12pm] ofzach: ok -- sounds ok to me
[2:12pm] damian0815: ofzach: yes doubling up points needs to change
[2:12pm] bilderbuchi: so if you want corners you can still easily get them?
[2:12pm] damian0815: yes
[2:13pm] bilderbuchi: not evryone likes smooothness :)
[2:13pm] bilderbuchi: fine then
[2:13pm] damian0815: pass false for the bAutoSmooth=true param
[2:13pm] jvcleave: any major addons effected? (thinking box2d)
[2:13pm] ofzach: and some people like mathematical correctness :)
[2:13pm] damian0815: pfft ;-)
[2:13pm] kylemcd: i don't think box2d uses ofPath right now
[2:14pm] kylemcd: ok, so we can give damian the go ahead on making ofPath nicer by default? :)
[2:14pm] ofarturo: i think nothing will break except some weird cases no one will be using curveTo get a line instead of a curve and live that in their code
[2:14pm] ofarturo: *leave*
[2:14pm] damian0815: unless graphcs lead wants to take it?
[2:14pm] damian0815: it's not my field
[2:14pm] imkeith: i think it makes sense so long as we document that curveTo is really bezier with auto-tangents
[2:14pm] damian0815: +1 keith
[2:14pm] imkeith: and that most ofPath operations will be as such
[2:15pm] bilderbuchi: and some people like mathematical correctness  -> that, too
[2:15pm] damian0815: curveTo will be catmull rom if there is enough data
[2:15pm] ofarturo: what if we had a new type of curve?
[2:15pm] imkeith: i think not
[2:15pm] damian0815: or bezierto with auto handles
[2:15pm] imkeith: i think catmull rom should be explicit
[2:15pm] gameover_: i wonder about making default = to nice curves
[2:15pm] imkeith: because it does not mean nice curves
[2:15pm] ofarturo: autoCurveTo?
[2:15pm] imkeith: in fact catmull roms are usually gross
[2:15pm] damian0815: catmullRomTo
[2:15pm] ofarturo: or autoBezierTo or bezierTo with less arguments
[2:16pm] damian0815: yeah
[2:16pm] gameover_: often when you're trying to leasrn about some new maths you want to see oF produce an example from somewhere else
[2:16pm] gameover_: so perhaps we could have an ofSetDefaultCurveToNice and the path.curve(..., nice = true) ???
[2:16pm] ofTheo: I would be against anything that might heavily break people's current usage - or anything that might be affected used for layout or UI
[2:17pm] gameover_: it's confusing for CS dudes and beginners likewise...
[2:17pm] ofTheo: but I think an example showing the two different ways would be helpful
[2:17pm] kylemcd: i think damian's approach is just to make changes to ofPath and curveTo, nothing too crazy, right?
[2:17pm] ofTheo: kind of like the screenshots posted to the dev list
[2:17pm] kylemcd: but now we're starting to discuss some crazier things?
[2:18pm] imkeith: i think its mostly just modifying the curveTo implementation to have toggleable auto-tangents
[2:18pm] ofTheo: I could see an example split down the middle, on the left shows how many points you technically need to use for catmull and on the right the easy mode  :)
[2:18pm] gameover_: umm...I think the changes seem really great - just think you should have to explicitly ask for any 'auto' action on a mathematical/graphing function
[2:19pm] damian0815: to me it's a naming issue: we're operating as though 'curveTo'  === 'catmullRomTo'
[2:19pm] bilderbuchi: +1 matt
[2:19pm] imkeith: if you want a CR, it could just be a separate API call, e.g. lineTo(); beginCR(); endCR(); lineTo()
[2:19pm] ofarturo: ok i think this needs some thinking i can try to hack a prototype, the main problem i see with the optional alwaysLookGood is that ofPath is super optimized for performance and adding a branching in every vertex added will affect performance in lots of other places
[2:19pm] damian0815: but what we _ought_ to be saying is that 'curveTo' === 'prettyLineThatPassesThroughMyPointsTo'
[2:19pm] imkeith: +1 damian
[2:19pm] imkeith: just about getting our names straight
[2:19pm] kylemcd: +1 damian, curveTo says nothing about catmull rom or bezier or anything
[2:20pm] imkeith: re 'auto action'
[2:20pm] imkeith: there's no escaping that
[2:20pm] gameover_: @arturo - then either it's #define NICE_CURVES or seperate function calls?
[2:20pm] imkeith: since you're saying "curve to"
[2:20pm] imkeith: which…means nothing
[2:20pm] imkeith: until you define curve
[2:20pm] ofarturo: @gameover yes i'm actually thinking on separate function calls
[2:21pm] kylemcd: maybe it makes sense for "curveTo" to just mean "pretty curve", and make anything else named after what it is? catmullRomTo bezierTo
[2:21pm] gameover_: +1 it's a naming thing autoCurveTo, crCurveTo, bezierCurveTo etc...
[2:22pm] gameover_: schnapps
[2:22pm] imkeith: it could even just be a default argument in bezierCurveTo instead of a #define NICE_CURVES
[2:22pm] imkeith: because maybe you want one nice and not the other
[2:22pm] bilderbuchi: +1: don't think #define is good here
[2:23pm] ofarturo: @kylemcd that makes sense problem is backwards compatibility
[2:23pm] damian0815: kylemcd: +1 in principle but it introduces funky border cases: lineTo then  catmullRomTo then curveTo -- what happens here?
[2:23pm] ofzach: fyi, curvet was based on p5 -- which is cat mull, but it doesn't have to be
[2:23pm] imkeith: bezierCurveTo(pt, auto_tangents = false)
[2:23pm] gameover_: yeah -1 define sorry for bringing it up
[2:23pm] imkeith: yah i mean
[2:23pm] imkeith: CR is great
[2:23pm] imkeith: because its simple
[2:23pm] imkeith: and easy
[2:23pm] kylemcd: damian in that case you're doin it wrong
[2:23pm] imkeith: you give it some points
[2:23pm] kylemcd: ;)
[2:23pm] imkeith: and it does a thing.
[2:23pm] damian0815: ofzach: but p5 paths don't supporting switching between types, which is the basic issue
[2:23pm] ofTheo: one other point to make is that catmull doesn't always look the same
[2:23pm] imkeith: it just might not be a sexy nice curves thing
[2:23pm] ofarturo: if we are going to break th rendering better to break the code so you can know what to change in your code
[2:24pm] ofarturo: can we go to the next point i think it's clear this needs some thinking better over a demo?
[2:24pm] kylemcd: ofarturo i think it's ok to break backwards compatibility with a relatively new feature, especially if it's not in the majority of use cases
[2:24pm] kylemcd: yeah definitely
[2:24pm] gameover_: + ofarturo
[2:24pm] kylemcd: let's just say "damian, give us what you got" and we can take it from there :)
[2:24pm] kylemcd: http://t0.gstatic.com/images?q=tbn:ANd9GcQn6gr5RrwyZdXArsBtGLUrwXWwY2pEsc0zw-3gvyZARchjJYgtZvWi3AjQ
[2:24pm] damian0815: hah ok
[2:25pm] kylemcd: #6. future of sound in oF (damian)
[2:25pm] gameover_: lol
[2:25pm] damian0815: yeah
[2:25pm] damian0815: have spoken with arturo briefly about this
[2:25pm] damian0815: we were talking an ofSoundBuffer object, like ofPixels for sound
[2:25pm] elliotwoods: nice!
[2:25pm] kylemcd: yessss please
[2:25pm] damian0815: things that currently have sound in them (incl. video) need to pass through ofSoundBuffer
[2:26pm] damian0815: and no more fmod
[2:26pm] elliotwoods: would this necessarilly result in duplication of data?
[2:26pm] ofarturo: no
[2:26pm] kylemcd: would it add latency?
[2:26pm] elliotwoods: all the sound libs can use external buffers?
[2:26pm] ofarturo: it can have a setExternalBuffer as ofPixels does
[2:26pm] gameover_: this would be excellent - especially if quicktime could pass through an ofSoundBuffer
[2:26pm] ofarturo: its just a wrapper + utils like getChannel()
[2:26pm] damian0815: i doubt QT can but we need to drop QT
[2:26pm] elliotwoods: ah ok, so ofSoundBuffer can wrap the other's buffer
[2:26pm] damian0815: +1 for AVFoundation on OSX
[2:26pm] damian0815: which enables this
[2:26pm] gameover_: quite hard to spatialize a movie as it stands
[2:27pm] ofarturo: the audioOut(float * output,...) will be audioOut(ofSoundBuffer & buffer)
[2:27pm] kylemcd: hah hah gameover_ i love that that is even a problem
[2:27pm] gameover_: @damian - actually I think it can, just need to have a buffer to aim the decoded audio too...
[2:27pm] elliotwoods: since audio is generally threaded. how would locking work?
[2:27pm] ofTheo: @damian what about the dsp chain ?
[2:27pm] gameover_: @kylemcd - it actually bothers me VERY often
[2:27pm] gameover_: :-)
[2:27pm] damian0815: can be lockfree
[2:27pm] ofarturo: @elliotwoods that's a different problem
[2:28pm] damian0815: the audiomulch guy has some great blog posts about achieving that
[2:28pm] elliotwoods: ok
[2:28pm] ofTheo: how do you see the ofSoundBuffer working within OF - say if you are playing a movie and triggering sound files?
[2:28pm] ofarturo: the idea is that usually you want notice for something like video
[2:28pm] damian0815: ofTheo: everything bounces down to an ofSoundMixer
[2:29pm] ofarturo: but you could get the video audio track in yoiur audioIn callback
[2:29pm] ofarturo: or send it to a mixer...
[2:29pm] ofTheo: got it
[2:29pm] damian0815: the mixer would be transparent unless you wanted it
[2:29pm] ofarturo: same for audio files
[2:29pm] damian0815: dsp would just plug in to the mixer like anything else
[2:29pm] gameover_: +1 ofSoundMixer!
[2:30pm] ofarturo: openal + sndfilelib can do that pretty easy
[2:30pm] elliotwoods: if something is generating, does it generate on request or by its own update?
[2:30pm] bilderbuchi: ofSoundmixer sounds awesome
[2:30pm] ofzach: maybe we need libSample rate too ?
[2:30pm] kylemcd: damian + arturo: maybe the first step would just be to do a quick draft of 1 the classes involved 2 how audio flows through it 3 any technical challenges?
[2:30pm] damian0815: the only issue is mp3 decoding, but i think the OSes can do this internally
[2:30pm] elliotwoods: ofSoundNode::orbit
[2:30pm] ofzach: I could see a lot of sampleRate issues if we mixing in different things
[2:31pm] ofTheo: so the idea is ofSoundPlayer ofSoundStream ofVideoPlayer all get piped to the mixer ?
[2:31pm] kylemcd: elliotwoods that sounds like unity3d...
[2:31pm] damian0815: ofTheo: es
[2:31pm] ofTheo: with option to get indivual callbacks?
[2:31pm] damian0815: yes
[2:31pm] ofarturo: yes we'll need some up/downsampling in some cases and i see this as a long term thing
[2:31pm] damian0815: ahhh.. what would the callbacks be for?
[2:31pm] damian0815: you could get tap into the sound streams if that's what you wanted
[2:31pm] gameover_: Yeah QT will take some work - the API being so easy to use and all ;-)
[2:32pm] elliotwoods: could you have multiple mixers (e.g. at different sample rates, in different addons)
[2:32pm] elliotwoods: ?
[2:32pm] damian0815: yes + yes
[2:32pm] ofarturo: i think first thing is ofSoundBuffer + ofSoundMixer, integrate that into the current rt sound system. later unified sound system
[2:32pm] ofTheo: @damian callbacks for manually processing the audio no?
[2:32pm] damian0815: ofTheo, right
[2:32pm] damian0815: that's basically a dsp node
[2:32pm] damian0815: so you'd insert yourself into the chain between video and mixer
[2:32pm] ofTheo: okay great.
[2:33pm] damian0815: api will need some thinking to make it intuitive yet tweakable
[2:33pm] elliotwoods: ofFbo::getSound(ofSoundBuffer &) const;
[2:34pm] damian0815: ?
[2:34pm] ofzach: ofFbo ?
[2:34pm] damian0815: you mean direct pixels to sound?
[2:34pm] ofTheo: great - so you'll be developing this in a branch ?
[2:34pm] ofTheo: is there a milestone ?
[2:34pm] damian0815: oh wait - glsl sound processing?
[2:34pm] kylemcd: it sounds like everyone is excited, and there aren't any serious issues that would make this impractical or unwanted, so it sounds like we just need some code or a more fleshed out design to talk about
[2:34pm] • damian0815
has had his mind blown
[2:35pm] ofTheo: :_
[2:35pm] ofTheo: :)
[2:35pm] ofTheo: agreed kylemcd
[2:35pm] elliotwoods: :)
[2:35pm] damian0815: ok sure
[2:35pm] damian0815: super
[2:35pm] kylemcd: great
[2:35pm] damian0815: will go ahead with something then.
[2:35pm] kylemcd: next!
[2:35pm] damian0815: next
[2:35pm] kylemcd: also, damian0815: https://github.com/kylemcdonald/AppropriatingNewTechnologies/tree/master/week4/GenerativeCodeExample
[2:35pm] kylemcd: generative bytebeat uploaded to a glsl shader and read out to the sound card :)
[2:35pm] kylemcd: it's fun, you would like it
[2:35pm] kylemcd: #7. using the wiki for documentation so people don't have to fork (kyle)
[2:36pm] gameover_: um I'm happy to drop #10, but I think I should talk about it before my eyes fall out if people are up for it
[2:36pm] gameover_: 4:36am
[2:36pm] damian0815: ouchhh
[2:36pm] kylemcd: ok, let's skip to it
[2:36pm] kylemcd: #10. ofSetPixelFormat (http://tinyurl.com/84pn7zh) (Matthew)
[2:36pm] gameover_: mostly the issues are in that post...
[2:37pm] gameover_: kyle and arturo had some concerns about getting to far into too many pixel types
[2:37pm] gameover_: there are a LOT
[2:37pm] gameover_: I have an excel spreadsheet I'm using to work through all the types
[2:37pm] gameover_: I'll post it to the dev-list
[2:38pm] gameover_: what I'm wondering is whether in the meantime we want just simple access to alpha channels for video
[2:38pm] gameover_: for 071
[2:38pm] gameover_: the rest I think is 072
[2:38pm] ofTheo: could that be done without too much fuss?
[2:38pm] elliotwoods: sounds decent
[2:38pm] ofTheo: I would say leave it all for 0072
[2:38pm] ofarturo: +1 oftheo
[2:39pm] kylemcd: +1 oftheo
[2:39pm] ofTheo: as I would be hesitant to do a change like this at the last minute
[2:39pm] kylemcd: yeah, we've already tested a bit
[2:39pm] kylemcd: let's say alpha for the next relase / 0072, and work towards more modes as needed?
[2:39pm] elliotwoods: well i guess
[2:39pm] gameover_: ok...I agree - but a few people have asked for alpha channels
[2:39pm] elliotwoods: anyone who wants this right now
[2:39pm] ofarturo: yes i also have it almost working for gstreamer, RGBA, BRGA and MONO but better to leave it for 0072 i think
[2:39pm] elliotwoods: can wait until the week after 0071
[2:40pm] kylemcd: we can generalize the code as necessary, rather then trying to over-design it from the beginning?
[2:40pm] ofzach: +1 to after 0071
[2:40pm] ofTheo: lets make it a priority though
[2:40pm] ofTheo: lots of testing
[2:40pm] ofTheo: etc
[2:40pm] ofTheo: also there is some related stuff
[2:40pm] gameover_: ok cool...there's a heap of testing...
[2:40pm] ofTheo: like being able to easy go from RGBA to RGB and Mono
[2:40pm] ofTheo: and back again
[2:41pm] gameover_: yep: at the moment the issue is that ofVideoPlayer and ofVideoGrabber can do all the pixel modes
[2:41pm] gameover_: ...and they are super good...
[2:41pm] ofzach: images that have 1024 pixel width :)
[2:41pm] ofarturo: :)
[2:41pm] ofTheo: oh man :)
[2:41pm] ofzach: (sorry !!)
[2:41pm] ofTheo: thats crazy - who'd want that?
[2:41pm] gameover_: but in order for it to make sense we need to change ofPixels and ofTexture - @oftheo those related things then become trivial
[2:42pm] ofTheo: great!
[2:42pm] ofTheo: should we look at the current PR - or is there more to do for that?
[2:43pm] gameover_: current PR is just the changes necessary to make ofVideoPlayer and ofVideoGrabber work
[2:43pm] ofTheo: maybe for 0072 we can make an example for alpha movies -
[2:43pm] ofTheo: would be good for testing etc
[2:43pm] kylemcd: sounds good
[2:43pm] gameover_: they work just fine with QT...but essentially ofTexture and ofPixels are 'broken' by me changing the reliance in ofTexture to know channel ordering
[2:43pm] kylemcd: we can test with an animated gif that has alpha ;)
[2:44pm] gameover_: for of072 I think we want alpha, bgra and 2yuv for video
[2:44pm] gameover_: bgra and 2yuv are LIFE CHANGING if you are using 1920 x 1080 video
[2:44pm] kylemcd: :)
[2:44pm] gameover_: :)
[2:45pm] ofzach: +1 to that…
[2:45pm] gameover_: also i think openGLES can support alpha channels etc
[2:45pm] gameover_: in a better way
[2:45pm] kylemcd: ok, let's move in that direction then -- any other comments on the video format stuff?
[2:45pm] ofTheo: great. -
[2:45pm] elliotwoods: there not a 16L Quicktime mode?
[2:45pm] elliotwoods: L167
[2:45pm] elliotwoods: L16
[2:46pm] gameover_: ?
[2:46pm] ofTheo: +1 ?
[2:46pm] ofTheo: :)
[2:46pm] gameover_: @elliotwoods sorry what is L16?
[2:46pm] bilderbuchi: austrian probationary driver's license?
[2:47pm] kylemcd: lool
[2:47pm] bilderbuchi: oh no, that's L17 :D
[2:47pm] ofarturo: i think we just need to be able to specify number of channels and bits per channel in ofPixels
[2:47pm] damian0815: "16-bit pixel format, all bits luminace." ?
[2:47pm] ofarturo: then we can give support for any format
[2:47pm] ofTheo: @ofarturo exactly
[2:47pm] ofTheo: I think it would be better to be agnostic and then rely on the user to supply the GL type
[2:47pm] ofarturo: not evey library will suport the same formats so ofPixels probably doesn't need to be aware of them all
[2:47pm] ofarturo: yep
[2:47pm] gameover_: @ofarturo - yes, but internally ofPixels needs to know what order the channels are stored in
[2:48pm] kylemcd: oftheo but gl types don't correspond to video types necessarily
[2:48pm] ofarturo: mmh i think just the application needs that
[2:48pm] gameover_: and for 2Yuv I have to think harder ;-)
[2:48pm] ofarturo: ofPixels probably needs pack or not packed
[2:48pm] ofarturo: number of channels and bits per channel so you can also retrieve a channel from it
[2:48pm] lia left the chat room. (Quit: lia)
[2:48pm] gameover_: whoa - ofVideoPlayer and ofVideoGrabber know what pixel formats they have...
[2:49pm] gameover_: ofPixelsType defines what you can ask for
[2:49pm] gameover_: ofPixels just needs to c=know channels, bit depth and order
[2:50pm] gameover_: ofImageType stays as is pretty much - except maybe needs an OF_IMAGE_DUO
[2:50pm] gameover_: (so you can have gray+alpha
[2:50pm] gameover_: for beginners they just use OF_IMAGE_TYPE
[2:50pm] gameover_: for advanced you use OF_PIXEL_TYPE
[2:50pm] gameover_: the rest is magic inside ofTexture and ofPixel
[2:51pm] gameover_: with some funky overloading of =
[2:51pm] gameover_: so that pixel ordering such as RGBA = BGRA
[2:51pm] elliotwoods: how would YUV2 work with ofPixels?
[2:51pm] gameover_: swaps automatically
[2:51pm] elliotwoods: i mean, you lose the concept of 'a pixel'
[2:51pm] gameover_: 2YUV...yes it's a problem but for now I'm dumping in a 4 channel ofPixel store
[2:52pm] kylemcd: ok, let's talk details more later
[2:52pm] elliotwoods: 4 channels = 2 pixels
[2:52pm] gameover_: yes
[2:52pm] kylemcd: next?
[2:52pm] gameover_: 1 macropixel
[2:52pm] elliotwoods: what about GL?
[2:52pm] elliotwoods: ext_422?
[2:53pm] gameover_: on mac yes ext 422
[2:53pm] gameover_: on PC - haven't solve it yet
[2:53pm] elliotwoods: :)
[2:53pm] elliotwoods: ok
[2:53pm] kylemcd: ok next :)
[2:53pm] gameover_: getting half res textures
[2:53pm] kylemcd: #7. using the wiki for documentation so people don't have to fork (kyle)
[2:53pm] kylemcd: this is a simple idea, back when we were working in detroit
[2:54pm] kylemcd: i was showing someone how to edit the documentation, and had to walk them through forking, editing, and submitting a PR
[2:54pm] bilderbuchi: but since then GH made it really easy to do his
[2:54pm] bilderbuchi: this
[2:54pm] bilderbuchi: couple clicks on the web interface
[2:54pm] kylemcd: right, the editing part is easier
[2:54pm] ofarturo: the problem with using a wiki is mainting it up to date from the source
[2:54pm] bilderbuchi: "fork and edit this file"
[2:54pm] elliotwoods: still fork PR though right?
[2:54pm] kylemcd: but you still have a "PR"
[2:54pm] bilderbuchi: "submit PR"
[2:55pm] bilderbuchi: but it does it automagically
[2:55pm] kylemcd: ofarturo can you explain
[2:55pm] elliotwoods: how about just make lots of admins on the repo?
[2:55pm] bilderbuchi: i think you don't even have to know about the PR
[2:55pm] ofarturo: right now we are using a script that parses the source code and adds new functions
[2:55pm] elliotwoods: edit directly in there?
[2:55pm] ofarturo: without removing the old ones
[2:55pm] kylemcd: oh right, but the trick is that i'm talking about using the GH wiki
[2:55pm] kylemcd: which is just markdown files, and is actually a git repo
[2:55pm] ofarturo: also if a function has moved from one file to another or if a function has gone from private to public...
[2:55pm] bilderbuchi: you are talking about ofSite, right?
[2:55pm] kylemcd: yes
[2:55pm] ofarturo: doing that with a plain wiki would be super hard
[2:56pm] elliotwoods: can ofSite 'pull' from that wiki?
[2:56pm] kylemcd: i'm talking about making the ofSite wiki just the documentation repository
[2:56pm] kylemcd: elliotwoods yes, theoretically
[2:56pm] ofarturo: and mainting the docs over vcersions if we don't have that would be super hard too
[2:56pm] kylemcd: the problem is more about the formatting / presentation on the wiki
[2:56pm] ofarturo: oh so separating ofSite in 2? kylemcd
[2:56pm] bilderbuchi: but.. doing it in the repo is super easy. have you tried lately?
[2:57pm] kylemcd: bilderbuchi yes i have, but the issue is the PR not the editing
[2:57pm] damian0815: why's that an issue?
[2:57pm] kylemcd: ofarturo yes so ofSite would have everything but the documentation. the docs would sit in the wiki repo
[2:57pm] bilderbuchi: there's just a button "propose file change" and that's it, no?
[2:57pm] elliotwoods: it means often you spend more time in git than you do editing the text at the moment
[2:57pm] kylemcd: damian it's an issue because it's an extra step to contribution
[2:57pm] bilderbuchi: even commit msg is pre-filled
[2:57pm] elliotwoods: ahh
[2:58pm] bilderbuchi: no no git needed.. just GH web interfae
[2:58pm] elliotwoods: yep yep, i meant forking/pring/politicing
[2:58pm] bilderbuchi: press once "fork and edit this file". edit. press "propose file change". done
[2:58pm] admsyn_ joined the chat room.
[2:58pm] bilderbuchi: edit in web interface, that is
[2:59pm] kylemcd: one sec i haven't seen that part
[2:59pm] admsyn left the chat room. (Ping timeout: 252 seconds)
[2:59pm] kylemcd: maybe that's new since i originally had this idea
[2:59pm] kylemcd: let me check
[2:59pm] damian0815: oh yeah i used that, it's super nice. it's really not an issue.
[2:59pm] bilderbuchi: thank you. yes kyle try it
[2:59pm] elliotwoods: trying now
[2:59pm] elliotwoods: yep
[3:00pm] elliotwoods: super easy
[3:00pm] kylemcd: oh wow this is awesome
[3:00pm] bilderbuchi: :-)
[3:00pm] bilderbuchi: good :-)
[3:00pm] bilderbuchi: so, "next"?
[3:00pm] kylemcd: we just need to update our instructions for contributing documentation
[3:00pm] bilderbuchi: :D
[3:00pm] kylemcd: next!
[3:00pm] damian0815: next!
[3:01pm] kylemcd: #8. code deprecation (elliot)
[3:01pm] ofarturo: yes code deprecation, cristoph has been looking at it
[3:01pm] elliotwoods: bilderbuchi : take the floor
[3:01pm] ofarturo: https://github.com/openframeworks/openFrameworks/issues/1216#issuecomment-5421913
[3:01pm] bilderbuchi: there's a cross-platform mechanism for this
[3:02pm] bilderbuchi: thx, arturo, I 've been whippping up something. if people want, we'll have a proper deprecation mechanism shortly
[3:02pm] bilderbuchi: it's just a #define.
[3:02pm] bilderbuchi: one thing: I need to know how to test for xcode4/clang/llvm
[3:02pm] bilderbuchi: and if this will work on ios/android.
[3:03pm] damian0815: __APPLE__
[3:03pm] ofarturo: i think it's almost there but the current syntax is a little weird there are some comments in the issue
[3:03pm] damian0815: http://stackoverflow.com/questions/1529031/what-c-preprocessor-conditional-should-i-use-for-os-x-specific-code
[3:03pm] bilderbuchi: i will to a PR shortly. yes I'll change the syntax arturor
[3:03pm] ofarturo: bilderbuchi i think the syntax in clang is the same as gcc
[3:03pm] ofarturo: __attribute__ ...
[3:03pm] bilderbuchi: yes i know, but will clang react on _gnuc__ i gues not
[3:03pm] ofzach: can we do this: [3:03pm] ofzach: http://clang.llvm.org/docs/LanguageExtensions.html#deprecated
[3:04pm] ofzach: (sorry if I misunderstand what you mean)
[3:04pm] bilderbuchi: we _are_ doing this zach
[3:04pm] ofzach: ah sorry
[3:04pm] bilderbuchi: i just need to get the ifdef to trigger on clang (not only on gcc and VS)
[3:04pm] ofzach: where are we doing it now ?
[3:04pm] bilderbuchi: no yet it's just in my issue, PR is yet to come
[3:05pm] bilderbuchi: i meant: the proposed method it doing exactly that
[3:05pm] elliotwoods: so it's OFDEPRECATED ?
[3:05pm] bilderbuchi: yes
[3:05pm] ofarturo: bilderbuchi http://stackoverflow.com/questions/1617877/how-to-detect-llvm-and-its-version-through-define-directives
[3:05pm] gameover_: ok i'm sleep deprecated - night all...see you on the flip side!
[3:05pm] ofarturo: see u!
[3:06pm] bilderbuchi: put that before a function/class/variable/type and you'll get a compiler warning
[3:06pm] elliotwoods: night @gameover_!
[3:06pm] ofzach: http://stackoverflow.com/questions/1617877/how-to-detect-llvm-and-its-version-through-define-directives
[3:06pm] bilderbuchi: arturo: thx, could have thought of SO
[3:06pm] bilderbuchi: damn
[3:06pm] ofzach: (sorry!)
[3:06pm] bilderbuchi: *hangs head in shame*
[3:06pm] elliotwoods: ok, so we decided compiler warning is what we ant
[3:06pm] gameover_ left the chat room.
[3:06pm] bilderbuchi: idk. it's what i went along with...
[3:06pm] ofTheo: OFDEPRECATED or OF_DEPRECATED
[3:06pm] ofTheo: ?
[3:06pm] kylemcd: gameover_ probably just died of too much OF
[3:06pm] elliotwoods: _
[3:07pm] bilderbuchi: theo: don't care, make a wish :-)
[3:07pm] elliotwoods: he's in australia, they're already on 0072 there
[3:07pm] kylemcd: hah hah
[3:07pm] ofTheo: OF_DEPRECATED or maybe something lower case?
[3:07pm] ofTheo: is it
[3:07pm] ofarturo: yes i guess OF_DEPRECATED is more similar to other defines
[3:07pm] ofTheo: a #define?
[3:07pm] ofarturo: OF_KEY... OF_IMAGE...
[3:08pm] bilderbuchi: OF_DEPRECATED it is then
[3:08pm] kylemcd: NEXT!
[3:08pm] ofarturo: ok next?
[3:08pm] damian0815: right, next!
[3:08pm] bilderbuchi: i'd stay uppercase
[3:08pm] damian0815: hungry!
[3:08pm] kylemcd: http://nataliepo.typepad.com/nataliepo/2010/06/next.html
[3:08pm] bilderbuchi: wait
[3:08pm] damian0815: HUNGRY!
[3:08pm] kylemcd: #9. default optimization levels for different platforms and IDEs
[3:08pm] bilderbuchi: nvm. deprecation usage discussion another time
[3:08pm] kylemcd: tooo late!
[3:08pm] kylemcd: did we figure this out on the list already?
[3:09pm] ofarturo: i think debug should be -o0
[3:09pm] kylemcd: i heard some crazy ideas, including having three levels: debug, debug optimized, release
[3:09pm] elliotwoods: that's me! :)
[3:09pm] ofarturo: if you want to debug in release you can always have debugging symbols in release too
[3:09pm] kylemcd: ofarturo what about people who complain that debug is slow?
[3:09pm] ofTheo: things have also changed with LLVM and newer xcode
[3:09pm] elliotwoods: i think IF people can't agree on debug
[3:09pm] ofarturo: that's what most programs do
[3:09pm] elliotwoods: then there's 2 definitons of debug
[3:09pm] elliotwoods: and we should respect those
[3:09pm] damian0815: if debug is -o0 we need to tell beginners that they should know the difference
[3:09pm] ofarturo: that's how the send this to apple feature in osx works
[3:09pm] kylemcd: elliot that's wise
[3:09pm] ofarturo: debug symbols in release
[3:10pm] ofzach: I have a lot of issues with LLVM / new Xcode and debug being way off
[3:10pm] ofTheo: yeah
[3:10pm] kylemcd: but just having some symbols isn't enough for real debugging
[3:10pm] ofTheo: old gcc could debug a lot better with -Os
[3:10pm] ofarturo: i mean debug: -O0 -g3
[3:10pm] ofarturo: release: -Os -g
[3:10pm] ofTheo: LLVM can be way off
[3:10pm] ofarturo: so you can also debug in release if you want
[3:10pm] kylemcd: oftheo what do you suggest for the different settings
[3:11pm] elliotwoods: ide's CAN debug in release, humans cant
[3:11pm] damian0815: if osx projects default to release then this isn't an issue right? in my experience beginners don't use the debugger
[3:11pm] ofarturo: to solve theo's problem with being able to debug during a demo or while an installation is running...
[3:11pm] ofTheo: I am okay with -O0 for debug
[3:11pm] kylemcd: true dat damian
[3:11pm] ofTheo: what is -Os vs -O2 like?
[3:11pm] kylemcd: i vote for arturo's solution
[3:12pm] kylemcd: plus "release" as the default mode
[3:12pm] ofTheo: I think we usually do -O3 for Release on xcode
[3:12pm] elliotwoods: depends totally on what you're doing
[3:12pm] ofzach: @kylemcd, damian I don't know -- debugger helps my students a lot
[3:12pm] elliotwoods: can be 1000x faster sometimes
[3:12pm] ofarturo: Os should be faster and probably smaller
[3:12pm] kylemcd: then when beginners realize they can use the power of the debugger, they can hop down into it
[3:12pm] damian0815: ofTheo it will depend on the CPU, -Os is better if the cpu cache is smaller
[3:12pm] damian0815: ofTheo: -O3 can be worse because code falls out of the cpu cache
[3:12pm] elliotwoods: only if march's wrong
[3:12pm] kylemcd: oftheo that same point was brought up in the ccc talk you sent me, about learning to trust the compiler
[3:13pm] elliotwoods: (i think)
[3:13pm] ofTheo: well we can set the march and mtune for xcode now ( thanks damian )
[3:13pm] damian0815: super!
[3:13pm] ofarturo: it depends a lot on the type of program you are dealing with
[3:13pm] ofTheo: I'm just worried about going from O3 to Os and everyone saying 0071 is slower
[3:14pm] ofarturo: i did some tests in linux for 007 and didn't notice any differece
[3:14pm] kylemcd: people already say OF is slower than cinder :) i'm not worried
[3:14pm] ofarturo: right now is -Os
[3:14pm] elliotwoods: if we really want speed fights, we should be talking SSE :)
[3:14pm] ofarturo: and i think the default in xcode 4 is now -Os from what i've seen in the posts in the dev list related to this
[3:14pm] elliotwoods: which i'd like to put on an agenda sometime
[3:15pm] kylemcd: elliotwoods, added to next agenda
[3:15pm] elliotwoods: cheers!
[3:15pm] ofTheo: @ofarturo but our default is currently O3
[3:15pm] bilderbuchi: you don't say cheers in that context. damian learned that the hard way on the last devcon :D
[3:15pm] ofTheo: ( 007 xcode release )
[3:16pm] elliotwoods: i say go with O3
[3:16pm] ofarturo: yes i think it doesn't make that much difference
[3:16pm] ofTheo: ok - well do -O0 for debug and stick to -O3 for release
[3:16pm] ofTheo: ( on xcode )
[3:16pm] ofTheo: + debug symbols
[3:16pm] ofarturo: next?
[3:16pm] kylemcd: i'm a little lost, can someone write down what settings we want to be using in the PP?
[3:16pm] damian0815: next? hungry... ?
[3:17pm] bilderbuchi: hunger? i want to go out!
[3:17pm] kylemcd: thanks arturo
[3:17pm] bilderbuchi: (beer)
[3:17pm] kylemcd: #11. related to code deprecation - ofPoint = issue. http://bit.ly/KmphsR ( want Zach and Arturo's take on it - theo )
[3:17pm] jvcleave: curious about the ccc talk- any someone post to pad if they get a chance?
[3:17pm] kylemcd: jvcleave it's a great talk, but i lost the link. oftheo?
[3:17pm] ofTheo: I think #11 is decided but lets leave it till 0072 ?
[3:17pm] ofarturo: i think we already convinced theo before in the issues comments :)
[3:17pm] ofTheo: will find it ( one sec )
[3:18pm] ofTheo: basically the option is: [3:18pm] ofarturo: https://github.com/openframeworks/openFrameworks/pull/1205#issuecomment-5420508
[3:18pm] kylemcd: wow, i thought theo would never concede on this one :)
[3:18pm] ofTheo: 1) merge PR and possibly produce errors for existing code
[3:18pm] ofTheo: 2) fix the operator to behave in the old way + damian's PR + mark the operator overload as deprecated
[3:18pm] damian0815: kylemcd: it took that fugly bug he uncovered to do it ;-)
[3:18pm] ofTheo: this would mean no errors
[3:18pm] ofTheo: just warnings
[3:19pm] damian0815: i vote 1)
[3:19pm] damian0815: because that bug is really bad
[3:19pm] bilderbuchi: yeah, deprecation is wrong here I think
[3:19pm] kylemcd: yeah i vote 1 too
[3:19pm] ofarturo: +1 for 1
[3:19pm] ofzach: + for 1
[3:19pm] bilderbuchi: deprecation like I'm currently designing, i mean... only warnings is not strong enough in this case
[3:19pm] ofTheo: I personally think everyone is insane. :) myScale = 1.0; is very sexy
[3:19pm] ofTheo: but I'll live with it
[3:19pm] ofTheo: :)
[3:19pm] bilderbuchi: +1 for 1
[3:19pm] kylemcd: :)
[3:19pm] ofzach: myScale.set(1.0) is still nice
[3:20pm] kylemcd: myScale = 1 would be even sexier, because then you're taking advantage of two casts! ;)
[3:20pm] ofTheo: but do we want to merge this for 0071?
[3:20pm] kylemcd: let's do 0072
[3:20pm] kylemcd: no more 0071 changes
[3:20pm] damian0815: 0072
[3:20pm] ofTheo: agreed
[3:20pm] ofzach: I think 72 is fine
[3:20pm] kylemcd: ok! NEXT!
[3:20pm] elliotwoods: this still allows you to set a vec
[3:20pm] elliotwoods: wait!
[3:20pm] kylemcd: hah hah
[3:20pm] ofarturo: ok but there's a bug with this somewhere in the core as it is right now no?
[3:20pm] kylemcd: you have to say UNNEXTABLE!!
[3:21pm] damian0815: no
[3:21pm] kylemcd: is there?
[3:21pm] damian0815: not a bug
[3:21pm] elliotwoods: finally {
[3:21pm] ofarturo: we should at least fix that
[3:21pm] elliotwoods: }
[3:21pm] ofTheo: yes
[3:21pm] ofTheo: there is
[3:21pm] kylemcd: oftheo explain? what's wrong?
[3:21pm] ofTheo: currently there is a bug because the operator overload was commented out
[3:21pm] ofarturo: ok so just change those to vec.set(0,0,0)
[3:21pm] elliotwoods: so can we init an ofVec to 4.0f?
[3:21pm] ofTheo: so as of 0071
[3:21pm] elliotwoods: argh? what a mess. we need a function
[3:21pm] ofTheo: anyone doing myVec = 1.0;
[3:21pm] elliotwoods: vec.set(float)
[3:21pm] elliotwoods: at the very least
[3:22pm] elliotwoods: i am yes
[3:22pm] ofTheo: will be setting myVec.x = 1.0;
[3:22pm] elliotwoods: wait, i'm not then :)
[3:22pm] elliotwoods: but i want to !
[3:22pm] damian0815: ah right
[3:22pm] damian0815: yes that's a bug
[3:22pm] elliotwoods: obvious example: [3:22pm] elliotwoods: you want a uniform scale
[3:22pm] kylemcd: no, i think that's definitely a bug
[3:22pm] elliotwoods: currently it's ofScale( ofVec3f(4,4,4) );
[3:22pm] elliotwoods: (you can drop the ofVec3f there)
[3:23pm] damian0815: right yeah ofEasyCam, first code chunk in https://github.com/damiannz/openFrameworks/commit/28d3155da395641c087a3b19dec305f364d1a887
[3:23pm] elliotwoods: it should be something at least like ofScale( ofVec3f(4) )
[3:23pm] kylemcd: ofScale(4 * ofVec3f::one() )
[3:23pm] damian0815: kylemcd: pfft
[3:23pm] ofTheo: I find ofScale(4) very sexy ;)
[3:23pm] elliotwoods: it should be there anyway
[3:23pm] bilderbuchi: nonono i shudder..
[3:23pm] ofarturo: we can have ofScale(float)
[3:23pm] bilderbuchi: brr
[3:24pm] kylemcd: ofTheo agreed, but that's different than ofVec3f(4)
[3:24pm] elliotwoods: but this happens in lots of places
[3:24pm] elliotwoods: either we change all the functions to accept floats, or make vectors initialisable from floats
[3:24pm] kylemcd: yes, but it's not always the same
[3:24pm] elliotwoods: how is it in glsl?
[3:24pm] kylemcd: scaling is an example where you want all the components to be the same most of the time
[3:24pm] elliotwoods: float4 myFantasticCastMachine = (float4) 0; ?
[3:24pm] kylemcd: translation is an example where you want them to be zeros if not specified
[3:25pm] kylemcd: in glsl it uses the same value for all of them
[3:25pm] kylemcd: so vec3(1) == vec3(1, 1, 1)
[3:25pm] elliotwoods: why not have that
[3:25pm] elliotwoods: vectors should be agile little bastards
[3:25pm] elliotwoods: we should be talking about making vec1.xy = vec2.yx work
[3:25pm] ofTheo: vec3(1) == vec3(1, 1, 1) is in damians fix no?
[3:25pm] elliotwoods: it doesn't 'make sense' but it sure as hell is useful
[3:25pm] kylemcd: i don't have any problem with a constructor actually
[3:25pm] kylemcd: it's just the = operator
[3:25pm] ofzach: +1 to all this
[3:26pm] damian0815: the big issue here is one of spotting bugs when reading the code. ofPoint p = ( 1, 2 ); looks like perfectly acceptable code, but you end up with p.x=1 and p.y=0 and it's next to impossible to debug
[3:26pm] kylemcd: make it act more like glsl, just get rid of the operator=float
[3:26pm] damian0815: ofTheo: yes
[3:26pm] elliotwoods: i think that's the most sensible
[3:26pm] ofTheo: today is a sad day
[3:26pm] elliotwoods: just make the cast 'verbose'
[3:26pm] damian0815: 'explicit'
[3:26pm] elliotwoods: haha
[3:27pm] elliotwoods: yep : that's the one
[3:27pm] kylemcd: theo i'll get you a beer if you want
[3:27pm] kylemcd: ;)
[3:27pm] ofTheo: I'll need two :)
[3:27pm] bilderbuchi: +1 to damian
[3:27pm] kylemcd: hah hah
[3:27pm] elliotwoods: haha
[3:27pm] ofTheo: anyway - lets agree - merge PR in 0072
[3:27pm] kylemcd: you got it
[3:27pm] ofzach: haha ok
[3:27pm] kylemcd: ok great
[3:27pm] kylemcd: next!
[3:27pm] kylemcd: and last!
[3:27pm] kylemcd: #12. getting more addons into the core
[3:27pm] elliotwoods: ooh
[3:27pm] ofarturo: i don't think it's a good idea per se
[3:27pm] damian0815: which ones?
[3:27pm] • damian0815
votes for ofxProfile
[3:27pm] elliotwoods: all of them
[3:28pm] elliotwoods: git pull ofxAddons
[3:28pm] ofarturo: addons are great, modular, don't compromise the api....
[3:28pm] ofTheo: haha
[3:28pm] kylemcd: oftheo originally brought it up with ofxKinect
[3:28pm] ofTheo: I think xml or something like that could be in the core - but that is seperate
[3:28pm] ofarturo: ah you mean having addons as official or putting addons in the core code?
[3:28pm] bilderbuchi: I'm with arturo I think.
[3:28pm] kylemcd: err sorry
[3:28pm] kylemcd: yes ofarturo
[3:28pm] ofTheo: yeah I just meant include ofxKinect with the release
[3:28pm] ofzach: agree json / xml in the core is very useful
[3:28pm] ofarturo: ah ok
[3:28pm] ofTheo: but not much else
[3:28pm] kylemcd: i mean moving more contributed addons into the core addons
[3:29pm] kylemcd: moving core addons into the OF core is another issue
[3:29pm] ofTheo: right
[3:29pm] kylemcd: xml is the only one right now, really
[3:29pm] elliotwoods: do we mention ofxaddons in that folder? e.g. a txt file with the url?
[3:29pm] kylemcd: we're talking about stuff like ofxkinect, ofxbox2d
[3:29pm] jvcleave: I liked ofxKinect as it works on everything and I see it up there with ofxOpenCv and ofArduino
[3:29pm] bilderbuchi: idea: probably we can extend the PG in the future to automatically fetch addons. then the transaction cost of not having addons in the release distro is nil.
[3:29pm] ofTheo: yeah I would say ofxKinect - would be very helpful
[3:29pm] ofTheo: its a big selling point
[3:29pm] ofzach: +1 to ofxKinect
[3:29pm] elliotwoods: @bilderbuchi +1
[3:30pm] bilderbuchi: it's just a wget or git pull away
[3:30pm] ofarturo: +1 ofxKinect
[3:30pm] admsyn_: bilderbuchi: +1 to PG addon downloading
[3:30pm] damian0815: armel?
[3:30pm] elliotwoods: (curl+1)
[3:30pm] elliotwoods: ofxKinect+1
[3:30pm] ofTheo: the issue is for a lot of newby OF ers git pull or wget means nothing
[3:30pm] jvcleave: ofxKinect works on Armel
[3:30pm] elliotwoods: PG addons integration+1
[3:30pm] damian0815: ohhh raaddd!
[3:30pm] damian0815: radradrad!
[3:30pm] elliotwoods: @ofTheo - auto from PG
[3:30pm] elliotwoods: it calls the curl
[3:30pm] bilderbuchi: theo: yes, but if they only have to click on "fetch ofxKinect" this is not an issue, right?
[3:31pm] bilderbuchi: cause they use the PG to create projects naynway
[3:31pm] bilderbuchi: anyway*
[3:31pm] elliotwoods: we'd need to use something else on windows
[3:31pm] elliotwoods: as you wouldn't be in the minisys when running PG
[3:31pm] ofTheo: sure! but right now PG is not really ready for primetime.
[3:31pm] elliotwoods: +3 ofxKinect
[3:31pm] ofarturo: yes let's include ofxKinect even if it's only in the download by now so the repo is a different one
[3:31pm] kylemcd: well there's only one issue with ofxKinect in the core
[3:31pm] bilderbuchi: yes. but maybe hold your horses on importing lots of addons until we can judge this method first, i say
[3:32pm] elliotwoods: it also hints towards whether depth cameras in general demand more core support
[3:32pm] ofTheo: sure!
[3:32pm] kylemcd: which is that dan wilcox would be sad
[3:32pm] bilderbuchi: also: more binaries in the core. just saying :D
[3:32pm] ofTheo: dan won't be sad
[3:32pm] elliotwoods: what would he say?
[3:32pm] ofTheo: will do it as a sub module
[3:32pm] elliotwoods: ahhh
[3:32pm] jvcleave: hate to bring it up but does having Kinect in the name do any harm?
[3:32pm] elliotwoods: double develeopment repos
[3:33pm] ofTheo: no not really
[3:33pm] ofTheo: msft made an addon for OF as well :)
[3:33pm] kylemcd: he just wrote "ALso, please don't tell me ofxKinect is going into the main OF repo ..."
[3:33pm] bilderbuchi: arg submodules. have their own issues, no? elliott brought some up iirc
[3:33pm] ofarturo: yes we can decide on how to do it later let's just include it in the package by now
[3:33pm] ofTheo: @kyle - tell him its not
[3:33pm] ofTheo: I'll hand download it and add it into the final zip if I have to :)
[3:33pm] damian0815: lia sez 'oFTheo' stands for 'Oh Father Theo'
[3:34pm] kylemcd: lool
[3:34pm] ofTheo: we can have a clean room
[3:34pm] kylemcd: oftheo so the idea is to keep it out of the OF github, but download it into the release?
[3:34pm] ofzach: one float theo
[3:34pm] bilderbuchi: Oh father or old father?
[3:34pm] damian0815: hah
[3:34pm] ofTheo: where one computer does ofxKinect and an other does OF core
[3:34pm] ofTheo: :)
[3:34pm] bilderbuchi: yeah i'm fine with that (in the release but not in the repo)
[3:34pm] ofzach: sounds good but 0072 ?
[3:34pm] ofTheo: middle name is Farwell :)
[3:35pm] elliotwoods: 0071 if ofxKinect is stable
[3:35pm] ofarturo: btw isFrameNew is broken in ofxKinect
[3:35pm] ofarturo: i'll send a pr tomorrow
[3:35pm] ofTheo: I think 0072 no? or is it really stable at the moment?
[3:35pm] kylemcd: i feel like i fixed that once
[3:35pm] ofTheo: I have some patches for it
[3:35pm] ofzach: I think 0072 let's make sure it's primetime
[3:35pm] ofarturo: this was one moth ago + or -
[3:35pm] kylemcd: ok but the general feeling is to distribute more addons with OF, but not add them to the repo
[3:35pm] damian0815: yes
[3:36pm] ofarturo: yep
[3:36pm] kylemcd: so definitely ofxKinect, maybe others like ofxBox2d or ofxMidi
[3:36pm] ofTheo: yeah sounds good. I have some great code which has the kinect reconnect until it gets the image coming in.
[3:36pm] bilderbuchi: ok
[3:36pm] ofTheo: no to ofxBox2d
[3:36pm] kylemcd: hah hah
[3:36pm] ofTheo: unless todd's actually got it not to crash :)
[3:36pm] kylemcd: maybe we need to spend a week this summer doing ofxBox2d2
[3:36pm] kylemcd: and write it from scratch? :)
[3:36pm] bilderbuchi: what do we think about maintenance duty? if we bundle it with the release, wil lpeople expect us to maintain it?
[3:37pm] elliotwoods: let's seriously evaluate chris's idea though
[3:37pm] ofTheo: sounds like a party kylemcd :)
[3:37pm] ofTheo: lets use ofxKinect as a test?
[3:37pm] bilderbuchi: I'll file an issue about PG addon auto-download later
[3:37pm] kylemcd: yeah, +1 oftheo
[3:37pm] bilderbuchi: (i.e. tomorrow)
[3:37pm] elliotwoods: great
[3:37pm] elliotwoods: (i did mean in the future)
[3:37pm] kylemcd: alright, i think this meeting is over?
[3:38pm] damian0815: 2 hrs 40 mins. can we do this more often, so it's not so epic?
[3:38pm] elliotwoods: booo
[3:38pm] bilderbuchi: next meeting when?
[3:38pm] kylemcd: may 26th
[3:38pm] elliotwoods: it's already time for the next meeting?
[3:38pm] ofzach: I think time limits on the topics might help
[3:38pm] kylemcd: ofzach that's super smart
[3:38pm] ofzach: overflow can run into email thread
[3:38pm] bilderbuchi: time limits are not enforceable i fear
[3:38pm] ofTheo: we could get jamie's bot to enforce it
[3:39pm] elliotwoods: kick ban?
[3:39pm] ofzach: theo will make an app that types NEXT when you smile
[3:39pm] ofTheo: ha
[3:39pm] bilderbuchi: yeah but is that productive?
[3:39pm] bilderbuchi: cut smth off mid-discussion?
[3:39pm] ofTheo: :)
[3:39pm] bilderbuchi: lol
[3:39pm] elliotwoods: -1 for time limits
[3:39pm] kylemcd: maybe? we can try next time and see what happens
[3:39pm] elliotwoods: +1 for strategy
[3:39pm] damian0815: -1 for time limts
[3:39pm] ofTheo: *= -1 for time limits
[3:39pm] ofzach: I think a certain amount of conversation could lead to email threads...
[3:39pm] kylemcd: if it feels less productive or cramps our style, we'll toss it out
[3:39pm] bilderbuchi: won't be around next time, so tell me how it went :D
[3:40pm] damian0815: kk lunch !
[3:40pm] elliotwoods: timelimits = ofVec3f(-1)
[3:40pm] ofTheo: I think 10 mins per topic is more than enough
[3:40pm] bilderbuchi: Maybe we just have to be more rigorous on when to split off into emails
[3:40pm] damian0815: bye all!
[3:40pm] ofTheo: :)
[3:40pm] kylemcd: discussing 0071 took about 30 min
[3:40pm] ofTheo: thanks everyone!!
[3:40pm] ofTheo: ah
[3:40pm] ofarturo: yep bye! we have a flight in a couple of hours and haven't had lunch yet
[3:40pm] kylemcd: i think we couldn't have done it faster
[3:40pm] elliotwoods: ciao irc friends!
[3:40pm] kylemcd: see ya :)
[3:40pm] ofarturo: see uQ
[3:40pm] kylemcd: i'll post the log later
[3:40pm] bilderbuchi: cya! cheers!
[3:40pm] kylemcd: NEXT!
[3:40pm] ofTheo: ofExit
[3:40pm] kylemcd: ;)
[3:41pm] bilderbuchi: I'll down a pint to OF
[3:41pm] kylemcd: ofNext()
[3:41pm] ofzach: ciao !!!