I am retiring my google code rep for openframeworks addons in favor of github. You can now find my addons at http://github.com/memo/msalibs . Actually I've taken a leaf out of Karsten Schmidt's book and registered http://msalibs.org too. For now it just forwards to the github rep, but maybe soon it will be it's own site. (Note you can download the entire thing as a single zip if you don't want to get your hands dirty with git - thank you github!).
There are some pretty big changes in all of these versions. Some of you might have seen that the Cinder guys ported MSAFluid to Cinder and they got a 100% speed boost! Well it's true, they've made some hardcore mods to the FluidSolver allowing it to run exactly 2x faster. Now I've ported it back to OF, so now we have the 100% speed boost in OF too. In fact carrying on their optimization concepts I managed to squeeze another 20% out of it, so now it's 120% faster! (And these mods also lend themselves to further SSE or GPU optimizations too).
To prevent this porting back and forth between Cinder and OF I created a system introducing an MSACore addon which simply maps some basic types and functions and forms a tiny bridge (with no or negligible overheads) between my addons and OF or Cinder (or potentially other C/C++ frameworks or hosts). MSACore is really tiny and not intended to allow full OF code to run in Cinder or vice versa, but just the bare essentials to get my classes which mainly do data processing (such as Physics, Fluids, Spline, Shape3D etc. - hopefully OpenCL soon) to run on both without modifying anything.
So now any improvement made to the addon by one community will benefit the other. Feeling the love :) ?
Some boring tech notes: Everything is now inside the MSA:: namespace instead of having an MSA prefix. I.e. MSA::FluidSolver instead of MSAFluidSolver. So just by adding using namespace MSA; at the top of your source file you can just use FluidSolver, Physics, Shape3D, Spline etc. without the MSA prefix (or just carry on using MSA:: if you want). I think it aids readability a lot while still preventing name clashes.
There are more changes in each addon so check the changelog in each for more info. e.g. MSA::Physics now has a MSA::Physics::World which is where you add your particles and springs (instead of directly to physics), and the MSA::Fluid has an improved API which is more consistent with itself. So backwards compatibility will be broken a bit, but a very quick search and replace should be able to fix it. Look at the examples.
P.S. this is the first version of this MSACore system (more like 0.001) so it may change or there may be issues. If you are nearing a deadline and using one of these addons, I'd suggest you make a backup of all of your source (including your copy of MSAxxxx addon) before updating!
ofxWebSimpleGuiToo is an amazingly useful new addon for openFrameworks from Marek Bereza. With one line of code it allows you to create a webserver from within your OF app and send your ofxSimpleGuiToo gui as an html/javascript page, allowing remote clients to control your OF app from a regular web browser. These can be another PC or Mac, or android device, iPod Touch, iPhone, iPad etc. you name it. No specific app is needed on the client, just a simple web browser. In the photo below you can see the OF app running on the laptop sending the gui structure to an iPad and an iPhone - both running safari, which in turn can control the OF app.
there is still more work to be done, especially any Javascript / JQuery gurus out there willing to improve the client end are encouraged to come on board and finish it off!
Earlier this year MSA VIsuals directed and produced the visuals for the west-end dance show BLAZE. Below is a short snipped of some of the visuals. You can see more information at www.msavisuals.com/blaze
A while ago I'd posted an example and source code for using Vertex Arrays, Vertex Buffer Objects and Point Sprites in openFrameworks. This was for openFrameworks 005 and needed some mods to the core and other hacks to get it to do what we needed. In the current version of openframeworks (006+) a lot of the required functionality has been moved to the core and so we don't need the extra classes MSAImage and MSATexture, or to hack the core. The updated example is attached and can be downloaded from below.
P.S. An example on particle system with OpenCL for even more performance (updating the particles on the GPU) can be found here.
I've recently needed to work with Midi Time Code (MTC) and could not find any code to parse the midi messages and construct an SMPTE timecode. Closest I got was finding this documentation (which is pretty good) on how the data is encoded in the bits of 8 bytes sent over 2 SMPTE frames, each byte sent at quarter frame intervals. From that I wrote the code below (I've only really tested the 25 fps). The code is from an openframeworks application but should work with any C/C++ code.
class ofxMidiEventArgs: public ofEventArgs{public:
int port;
int channel;
int status;
int byteOne;
int byteTwo;
double timestamp;
};
#define kMTCFrames 0#define kMTCSeconds 1#define kMTCMinutes 2#define kMTCHours 3// callback for when a midi message is receivedvoid newMidiMessage(ofxMidiEventArgs& eventArgs){if(eventArgs.status == 240){// if this is a MTC message...// these static variables could be globals, or class properties etc.staticint times[4] = {0, 0, 0, 0}; // this static buffer will hold our 4 time componens (frames, seconds, minutes, hours)staticchar *szType = ""; // SMPTE type as string (24fps, 25fps, 30fps drop-frame, 30fps)staticint numFrames = 100; // number of frames per second (start off with arbitrary high number until we receive it)int messageIndex = eventArgs.byteOne >> 4; // the high nibble: which quarter message is this (0...7).int value = eventArgs.byteOne & 0x0F; // the low nibble: valueint timeIndex = messageIndex>>1; // which time component (frames, seconds, minutes or hours) is thisbool bNewFrame = messageIndex % 4 == 0;
// the time encoded in the MTC is 1 frame behind by the time we have received a new frame, so adjust accordinglyif(bNewFrame){
times[kMTCFrames]++;
if(times[kMTCFrames] >= numFrames){
times[kMTCFrames] %= numFrames;
times[kMTCSeconds]++;
if(times[kMTCSeconds] >= 60){
times[kMTCSeconds] %= 60;
times[kMTCMinutes]++;
if(times[kMTCMinutes] >= 60){
times[kMTCMinutes] %= 60;
times[kMTCHours]++;
}}}printf("%i:%i:%i:%i | %s\n", times[3], times[2], times[1], times[0], szType);
}if(messageIndex % 2 == 0){// if this is lower nibble of time component
times[timeIndex] = value;
}else{// ... or higher nibble
times[timeIndex] |= value<<4;
}if(messageIndex == 7){
times[kMTCHours] &= 0x1F; // only use lower 5 bits for hours (higher bits indicate SMPTE type)int smpteType = value >> 1;
switch(smpteType){case0: numFrames = 24; szType = "24 fps"; break;
case1: numFrames = 25; szType = "25 fps"; break;
case2: numFrames = 30; szType = "30 fps (drop-frame)"; break;
case3: numFrames = 30; szType = "30 fps"; break;
default: numFrames = 100; szType = " **** unknown SMPTE type ****";
}}}}
For the Grammy awards 2010, musician & artist Imogen Heap wanted a dress that would display the tweets and photos coming from her fans in realtime, so she could take her fans with her onto the red carpet. Moritz Waldemeyer designed a flexible LED ribbon which she could wear, and I developed the controlling software, an iPod Touch application that she could carry in her bag that would collect all the tweets and photos from the net, and send the information to the custom LED ribbon.
I designed and programmed visuals (projections) for the OKGo performance and Fendi installation at Design Miami 2009. OKGo were playing modified Les Paul guitars mounted with laser beams in the headstock, designed by Fendi in collaboration with Moritz Waldemeyer. Using a PC equipped with a high-speed firewire camera, I developed custom software to track the laser beams and generate visuals around the spots they hit the wall. These visuals were also audio-reactive, responding to the live audio feed coming from the sounddesk.
More images & video coverage coming soon.
P.S. For additional laser tracking goodness, checkout the Graffiti Research Lab's Laser Tag.
Recently I've been playing a lot with OpenCL, the new API / framework designed to handle cross-platform parallel computing (i.e. a simple way of running code simultaneously on all cores of your CPU, GPU or other processors). Implementations have been cropping up this year in NVidia drivers or ATI drivers, but most famously it's included with Mac OSX 10.6 Snow Leopard.
To cut a long story short I've been working on a simple-to-use C++ wrapper for some of the most common functions, imaginatively called ofxOpenCL and here is a little demo of 1 million particles running at 100-200fps.
NOTE: The Vimeo compression destroys most of the particles, so I suggest downloading the quicktime directly from the vimeo page at http://www.vimeo.com/7332496
This is 1,000,000 particles being interacted on by mouse, updated on GPU (with springy behaviours ) via an OpenCL kernel, data written straight to a VBO and rendered - without ever coming back to host (i.e. main memory + cpu etc.)
Frame-rate is around 100-200fps running on a macbook pro with GF 9600GT. That's 100-200fps on a laptop! (albeit a pretty decent one), but I'm dying to try this on a GF 285 GTX - which has 7.5x the number of cores, 2.5x the fillrate and 3.5x the memory bandwidth - for only £250!!
There are many posts out there on the internet discussing the pros and cons of running an update loop on iPhone (or on desktop for that matter) via an NSTimer vs NSThread, and many suggest they can squeeze an extra 3-5fps out of using an NSThread. So after this discussion on the openFrameworks forum, and with help from Robert Carlsen, I added this feature as an option to ofxiPhone. By default the update loop is still triggered from an NSTimer for backwards compatibility (and safety), but if in your testApp::setup() you call iPhoneEnableLoopInThread(), then the loop will be initialized to run in a separate NSThread and throttled by mach_absolute_time(). It is very much in its infancy (uploading to SVN as I type) but seems to do the job (obviously you'll need to write threadsafe code if you use it).
Originally created to forward UDP TUIO (OSC) messages straight to TCP to be read from within Flash.
This application forwards all incoming UDP messages straight to TCP without touching the data, just a straight forward.(Since version 0.2.1 there is the option to prefix the size of the packet before sending the data to comply with OSC / TCP specifications). This enables applications that don't support UDP (e.g. Flash) to receive the data. Since OSC / TUIO are generally sent via UDP, this enables Flash to recieve those messages in their raw binary form.
Inspired by Roxlu's brilliant openFrameworks wizard for code::blocks I thought I'd have a go at creating similar XCode templates - turned out it's super easy and you can download them below (templates for both desktop applications and iphone applications). Instructions are included in the zip but I'm attaching it below too.
Note: the iPhone template is for the latest version of ofxiPhone from the svn because there are additional files in the current version. (Thanks to everybody for pointing this out).
MSA Remote is a remote control application for iPhone & iPod Touch that sends OSC messages over the wifi network. This allows you to control any OSC supporting applications such as Max/MSP/Jitter, PureData, Reaktor, VDMX, vvvv, Resolume, Quartz Composer etc. as well as any custom applications such as interactive installations, audio/visual performances, multitouch capable surfaces etc.
By mapping the OSC to midi on desktop (e.g. using OSCulator) allows further control of any application which supports midi such as Ableton Live, Cubase, Logic Pro, 3DSMax etc. In addition, developers can easily integrate OSC into their applications knowing it can be controlled remotely.
The application can be distributed to visitors, guests, members of the public etc. to interact with an installation or performance, or used by dedicated performers.
- Multitouch information sent using standard TUIO protocol for instant integration with existing TUIO clients
- Accelerometer data for each axis (x, y, z) is sent
- 64 faders (8 pages of 8 faders)
- 64 triggers (8 pages of 8 triggers)
- 108 key (9 octaves) VELOCITY SENSITIVE polyphonic keyboard. Yes, the harder you hit the keys, the greater the velocity.
- Settings are automatically saved and restored
- Multitouch area orientation can be set as desired
- All information on protocols are documented in the app
Controlling VDMX & Ableton Live simultaneously
In this video, OSCulator is routing the OSC (& TUIO) messages coming from MSA Remote to midi and forwarding to Ableton Live (for audio) and VDMX (for visuals) simultaneously. Nothing is done in post, the same signal is controlling both audio and video. Video demonstrates faders, triggers, and velocity sensitive keys - yes velocity sensitive. The harder you hit the keys, the louder the sound (or whatever you want to map it to).
Controlling Java/processing.org fluid simulation with TUIO
Source code for the processing.org sketch can be found here:
Controlling custom multitouch paint application with TUIO
Graffiti Wall is a product that Tangible Interaction had already developed a while ago and have been using commercially. It was built on TUIO from the beginning, so when I passed on a copy of MSA Remote (via ad-hoc), they were able to immediately integrate it with their app without any modifications.
Camille Troillard, the mastermind behind OSCulator was kind enough to add some features (and sample patches) to his app to make handling the data coming from MSA Remote and converting to midi as seamless as possible.
The /msaremote/fader protocol is recognized and faders are automatically setup to forward to midiCC with same number as the slider.
The /msaremote/trigger protocol is recognized and triggers are automatically setup to forward to midi notes with constant velocity.
The /msaremote/bank protocol is recognized and triggers are automatically setup to forward to midi notes with constant velocity.
In the Osculator/Sample Patches/iPhone folder there are two sample patches which map incoming msaremote keyboard OSC messages to midi notes with velocity. The basic patch maps each key to the relevant midi note, while the advanced patch has the keys setup so you can assign each key to a different event.
Max/MSP
Blair Neal aka vimeo.com/laserpilot has created a Max MSP template (for Max5) to handle the OSC Messages coming from MSA Remote. Cheers Blair!
This is a set of C++ classes for solving and displaying real-time fluid dynamics simulations based on Navier-Stokes equations and Jos Stam's paper on Real-Time Fluid Dynamics for Games. The solver class has no dependencies on openFrameworks and can be used in any C++ project. The drawer class extends ofBaseDraws and contains an ofTexture for seamless integration with openFrameworks drawing routines. Also included in the addon is a ofxMSAParticleUpdater class which allows the fluid solver to be easily plugged into ofxMSAPhysics as a force field.
This is a tutorial in getting a very simple openFrameworks application running on iPhone with basic graphics, multitouch and accelerometer support (and one might say a simple particle system too!).
10 Balls are moving around on screen and bouncing off the edges.
You can touch the screen with multiple fingers and drag the balls around (multitouch support)
You can tilt the iphone and the balls fall in that direction (accelerometer support).
...and all of this without touching a line of Objective C. It is actually one of the samples included in the ofxiPhone download - iPhone Touch+Accel Example. You can find it in the examples folder of the download, so if you load and run that project you can see the finished result. The code below is straight from that sample, warts and all :P
Note: Everytime I mention iPhone, I am in fact referring to iPhone & iPod Touch running OS 2+.
Update 29/03/2009
Just posted a simple example application source code and walk-through which can be found here.
Update 27/03/2009
openFrameworks 006 is now officially released! You can download a fat package for your system from www.openframeworks.cc, mac/linux/windows and now iPhone. I do recommend you keep an eye on the ofxiPhone SVN for updates and fixes.
What is this and what does it do?
ofxiPhone (along with ofxMultitouch & ofxAccelerometer) are addons for openFrameworks 006+ that allow you to develop for iPhone in plain old C/C++ just as you would on a normal desktop (mac, linux, windows). This means using the normal testApp.h, testApp.cpp, main.cpp; setup(), update(), draw(), mousePressed(), ofImage, ofTexture etc. and any other C++ classes you may have created. It also means that you can reuse your exact same code running on your desktop (mac osx, windows, linux) unchanged on the iPhone by just copying across your testApp.h, testApp.cpp, main.cpp and other source or resource files you may be using.
ofxMSAPhysics is a C++ 3D particle/constraint based physics library for openFrameworks. It uses a very similar api to the traer.physics library for processing to make getting into it as easy as possible.
Version 2.0a is now available for testing.
Main features include
particles
springs
attractions (+ve or -ve)
collision
replay saving and load from disk (temporarily disabled in current alpha release)
custom particles (extend ofxMSAParticle and add to the system)
custom constraints (extend ofxMSAConstraint and add to the system)
custom force fields (extend ofxMSAParticleUpdater and add to the system)
custom drawing (extend ofxMSAParticleDrawer and add to the system)
An interactive, generative, audio-reactive visualization app for the iPhone and iPod Touch (what a mouthful!) (This is the continuation of what I originally called "The Meshulator").
Use your fingers to create and interact with abstract geometry in 2D or 3D. Very simple to use, just slide your fingers over the screen and try different gestures. Tilt the device to look at the shape from different angles. Options for two different kinds of audio-reactive behaviour (microphone input - iPhone only): deforming based on audio, or completely generative driven by audio. If you feel adventurous, you can play with plenty of customizable parameters to adjust coloring, physics, shape etc. Or if that feels too intimidating just click 'randomize' to make the settings random and experiment.
It was written with a custom version of openFrameworks (pre-006) and an early version of the ofxiPhone addon. Information on openFrameworks and ofxiPhone at memo.tv/ofxiphone.
148apps.com - 4/5 stars."You will find yourself showing people this application …and then, not getting your iPhone back because they want to keep painting."
geek.com - "I like the fact that the app is not just a port of the website, but includes enhancements which take advantage of the features of the iPhone."
iphonefreakz.com - "...the most jollificating paint app for iPhone and iPod Touch. It’s like getting a Jackson Pollock soul inside you...Definitely worth having it on your phone for. Well worth $0.99"
iPhone adaptation of Miltos Manetas' website jacksonpollock.org (original flash developed by Stamen Design). Save your pictures and send them to jackson@jacksonpollock.org, the best Pollocks will be published in an upcoming book.
The video below shows the basic features of v1.0. In the current version (v1.1) ability to choose your own colors has been added to allow the creation of more controlled paintings like those seen in the images below.
Version 1.1 is now in the appStore. New version brings serious optimizations thus max amount of dust is now tripled.
This is a port of my original gold dust app (vimeo.com/2281077) to iPhone. Of course it doesn't translate exactly but this is my first attempt to capture the essence of the original demo. Unfortunately I don't think this video manages to capture the behavior of the glittery gold dust either, but it's free so you can try it for yourself :P.
It was written with a custom version of openFrameworks (pre-006) and an early version of the ofxiPhone addon. Information on openFrameworks and ofxiPhone at memo.tv/ofxiphone.
"Reincarnation" is an off-shoot from a visual performance for the Rambert Dance Company's "Iatrogenesis" at the Queen Elizabeth Hall, South Bank, London UK - visuals for the latter directed by my good friends at flat-e.
The project began when I started working with footage of the Rambert dancers. Inspired by the footage, I wrote custom software to track the motion and generate the visuals you see in the video below... and "Reincarnation" was born.
For the Rambert's "Iatrogenesis" piece, I created similar visuals, abstract visual layers containing subtle hints of human forms and motion, which would tie in with the movement of the dancers on stage. These were used by flat-e and composited with various other layers and projected on a see-through gauze in front of the stage.
The video (and music) you see below is not representative of the visuals (and music) of the Rambert's and flat-e's "Iatrogenesis". This is just a standalone piece born from working with the Rambert choreography.
When the clip starts, you probably won't recognize a human shape at first, but your eyes and mind will be searching, seeking mental connections between abstract shapes and recognizable patterns, like looking for shapes in clouds. You'll be questioning what you see, is that it? is it sitting? is it crouching? is it kneeling? Then all of a sudden, it'll be crystal clear. Then you'll try and keep it in focus, following it as it moves around, tracking each limb, using the motion to construct an image of the parts you can't see. It'll fade in and out of clarity. At times you'll be clinging onto just the tip of it's hand swinging round, trying to identify any other recognizable parts. You might see another arm or leg and grab onto it, fighting not to lose it. Then it'll be crystal clear again, and then all of a sudden vanish, literally in a puff of smoke, and your eyes will start searching again.
Over the years OpenGL has developed lots of different ways of sending vertex data to the graphics card: Immediate mode (glBegin / glVertex / glEnd etc.), Display Lists, Vertex Arrays, Vertex Buffer Objects etc. The first of these (Immediate Mode) is quite inefficient, so it's been dropped in OpenGL ES and depreciated in OpenGL 3.0. Instead we are to use Vertex Arrays or VBO's (Vertex Buffer Objects). They are way more efficient, but generally not as straightforward to setup and use.
For this reason I wrote a C++ class that wraps up the functionality of Vertex Arrays (and soon VBO's) in an immediate mode style syntax. I.e. you can carry on calling glBegin / glNormal / setColor / glTexCoord / glVertex / glEnd etc. but instead of sending the data on every function call, it just caches them all in client-side arrays, and sends it all in one go when you call glEnd(). Later you can call draw() to redraw the information you've put in. Thus improving performance on desktop systems, and allowing immediate mode style syntax on embedded systems such as the iPhone. (The previous post about the Meshulator uses this class).
