Meemoo web media wiring

Thinking about Meemoo 2.0

2020-10-17T00:00:00+00:00

Meemoo lives!

This is how I started my last post (2016). I’m happy that Meemoo continues to work whenever I spin it up with an idea.

(Saving to gist needs some help. Github probably turned off anonymous Gist creation, or changed that API. Other than that, I think that this project is stable enough to keep working. As long as I pay for the domain registration.)

Meemoo as a project and thesis always had these layers in mind:

A layer on top to build mini apps with UI, to encapsulate the dataflow flow view.
(Existing) data flow view.
A layer beneath, to see, fork, and/or edit the source code of any module.

I commissioned this illustration to show how these layers would unfold:

With this sequence of layers in the Meemoo ecosystem, I imagined guiding folks down the rabbit hole towards “learning to code.”

Somebody sees an eye-catching image or animation out on the internet somewhere.
They ask the author “what app did you use to make that?”
They get a link to the Meemoo app, and use it to make and share their own images. (Layer 1)
They might stop there, but they might notice the invitation to hack the app, and see the data flow behind the UI. (Layer 2)
Once they understand how hacking the app works, and see the library of available modules, they might want to hack a module or make their own with code. (Layer 3)

There was also supposed to be a community site for sharing and forking these mini apps. Why did Meemoo stall with just the dataflow layer? Probably some combination of starting a family, running out of grant funding, and getting a day job. Standing up an online community is a major obligation in terms of moderation. I felt like making a community without committing the resources to make it a safe and good learning environment would be worse than not making the community at all. Meemoo hasn’t gained traction or a life of its own, which I’ve decided to be OK with.

Also it reached a local maxima of being “fun enough,” which isn’t a bad thing.

Meemoo 2.0?

So what is there to do at this point? Will there be a Meemoo 2.0?

Meemoo is built on Backbone and jQuery/UI, which are fairly obsolete. On the other hand, they are simple, stable, and work.

A lot has changed in web development in the 9 years since my first commits. In the first version, the camera module was powered by Flash, because the web standards for accessing a device camera hadn’t shipped yet. As standards like this shipped to the web platform, I was able to remove code and complexity.

Meemoo’s “Hello World” app is a camera module that sends images to an image stack, that can compile an animated GIF.

Meemoo cam2gif

If Meemoo modules were packaged as Web Components, it would be possible to build this app with a few lines of code in any web page:

  <meemoo-cam id="cam" />
  <meemoo-animation id="animation" />
  <meemoo-link from="cam" out="image" to="animation" in="image" />

By taking the module code out of the dataflow environment, it might be possible to jump from interface to code more easily. The dataflow environment wouldn’t be needed to style or edit the app, but it could be loaded as a layer on top of (or under) the published app.

I’m not sure if Web Components are really the best abstraction for what I want to do here. There are at least 43 ways to build Web Components, that have tradoffs with authoring complexity and compatibility with other frameworks. This has caused some analysis paralysis on my part.

I’m also not sure if “reusing Meemoo components” should be my first design goal with future Meemoo work.

So what is the web missing?

Several of my web developer peers express fondness for Flash, as it existed around 2002. I credit the combination of vector editing, timeline animation, and scripting with my initial love for creative coding. Are there any environments that combine separate modalities like this now? What about other metaphors, like spreadsheets for tabular data editing and visualization?

I’ve been thinking about designing a “thicker” Meemoo module with a full-featured animation timeline. Maybe also a mini spreadsheet module.

But is dataflow the correct metaphor to be coordinating these modalities?

Could it be that the “correct” metaphor is just a webpage, with any framework, or none at all?

“Exposing ports”

Meemoo components announce their inports and outports: what type of data they expect as input, and output. This is something that most component systems lack, including React and standard Web Components.

This enables a few things:

UI for tweaking initial state of components
Wiring hints for compatible data

Do any other component systems expose “data types” like this? Is there room for some kind of standard around this?

HMU

After several years on the backburner, I’d like to find Meemoo’s next step. Got ideas? 👉 Talk in issue #145

The Learning Center school Maker Faire

2016-03-10T00:00:00+00:00

Meemoo lives!

We were invited to set up a stop-motion animation station at the local school’s Maker Faire. A lot of people came to try their hand at making stop-motion loops. A few people had done stop-motion before, so I was able to pitch the hackability aspect to them. I think that the Maker Faire surroundings helped people understand the benefit of being able to hack creative apps.

One young person asked how to wire in sound effects… that’s a module that needs to be made!

</source> </source>

Update

Imgur

I jumped back into Meemoo a bit to change how images are stored to the web. Imgur has a funny GIFV format that’s actually a looping mp4/webm video. (If you see a .gifv link you can change it to .mp4 or .webm.) This is nice for longer animations with big filesizes. Meemoo still has to save and upload the animation as GIF, so the process is lossy, but still an improvement.

You can see the looping video made by Imgur in the last loop above.

HTTPS everywhere

Chrome started blocking getUserMedia (webcam) access on non-https web apps. Meemoo will now redirect you from http: to https: so you should not run into that issue.

Turtle power to the people

2015-01-14T00:00:00+00:00

The Grid meet up

After working for about three years with Forrest we finally meet him on a meet up of The Grid team.

During the first days we were preparing a workshop for MozFest’s #ArtOfWeb track. The idea was to present a quick introduction to Flowhub/NoFlo and how to use it to draw with Mirobot. Then we would let people create their own drawings.

We created a NoFlo component to talk with Mirobot:

Having the robot represented as a component made it easier to even explain to people how it was drawing: “the SendCommand component waits for commands — like go forward or turn left — so when it receives a new command, it sends it to the robot. When the robot finishes drawing, it signalizes banging the completed port, so we are good for the next command”.

For the workshop Gabi created a NoFlo graph that draws contours of a given image:

Given an image as input (the heart), the graph extracts its edges and chooses random points from it. If we give those points to Mirobot draw randomly, it will end up with a random path that wouldn’t remember the original shape of a heart. We have to order the points in a way the robot will travel along the shortest path. We have a Travelling Salesman Person solver that finds the shortest path. After converting cartesian coordinates to polar ones — because Mirobot just understands translations and rotations, remember? forward X and turn left/right Y — we send the commands to Mirobot and using noflo-canvas we draw a preview. Here’s the result:

The other graph collects points someone draw on a canvas and after sending that, Mirobot draws them on paper:

The meetup with The Grid was incredible. We met Forrest, Jon Nordby and Henri Bergius. Lionel Landwerlin joined us some days later. Those guys never stopped coding and inspiring us.

More robots on the way

While preparing the workshop we built a hack to Mirobot, making it possible to draw on walls. That’s a work-in-progress and we are planning to keep improving and documenting the process.

MozFest’s ArtOfWeb

MozFest was fantastic. We met Kat, Eric, Paula, Michelle, Allison, Ginger, Ricardo and all the other incredible “art phreaks” of the #ArtOfWeb track. Ben Pirt, the Mirobot’s creator, joined us in the art gallery and brought us his bots and kindness.

ArtOfWeb was a refuge during the chaotic creative tornado of MozFest. A place to chat, create and relax listening to good music and enjoying art installations.

Yay, #Mozfest: The #ARTOFWEB Gallery is packed w/ folks teaching + making open art together. Join now on Floor 2! pic.twitter.com/bx4GMKXNUV
— Kat Braybrooke (@codekat) 25 October 2014

Our session did its job. We had people curious about the drawing robot, nice discussions about procedural vs flow-based programming and really nice collaborative drawings.

Henri recorded the following time-lapse video. A really nice way to capture this kind of session.

The festival ended up with a demo party where the most revealing feeling of collaboration and aesthetics experimentation took its place. Surrounded by curtains, music and projections, people and robots joined again to draw together.

We hope the next workshops are like this last experience and we’ll try to make it happen more in the future. As well pointed by Kat, “let’s (re)make networked art”.

We really want to thank and give a huge hug on all people we met. To our dear colleagues of The Grid, that made it possible to happen, thank you for all. To Mozilla, thank you to bring this amazing people together for a better Web of openness and opportunity.

Looking forward to keep phreaking art and meet you all again this year!

Photos by Kat Braybrooke, Mozilla in Europe and Vilson Vieira.

First steps for noflo-webaudio

2014-08-05T00:00:00+00:00

Before any word, let’s make some noise. You can play yourself with this demo clicking here.

This simple demo was presented by Forrest in his last Assembly talk. It illustrates how we are combining audio and visuals in NoFlo.

It uses noflo-webaudio, our wrapper library to the Web Audio API. Web Audio API defines a “signal-flow graph” where audio sources connect to processors and can be manipulated on a sample-accurate base. How to map such “signal-flow graph” to NoFlo? Having worked with noflo-canvas we wanted to explore if the same design and semantics used on it could work with Web Audio.

In noflo-canvas, each component generates lispy commands that are lazy-evaluated in a complex component (Draw). We are doing the same for noflo-webaudio. In this way, we have some components like Oscillator and Gain that sends lispy commands like the following:

{"type": "gain", 
 "input": [{"type": "oscillator", "frequency": 440.0},
           {"type": "oscillator", "frequency": 660.0}]
 0.8}

which, again, maps to a lispy representation like

(gain ((oscillator 440)
       (oscillator 660))
      0.8)

Each time a component input (like Oscillator’s frequency) changes, it sends an updated command as its output. The Play component gets all those commands and takes care of how to plug them together and update the parameters when needed.

The major difference is that noflo-canvas follows a “redraw the entire canvas everytime” paradigm while noflo-webaudio can’t reconnect all the audio nodes everytime: most of the time the audio graph doesn’t change, just the parameters. So Play should be smart enough to walk through the received commands and decide which should be reconnected (like Oscillators and AudioFile) and which should have just its parameter updated.

The JSON representation of such signal-flow graphs remembers a declarative paradigm. We are exploring a Web Audio library called Flocking which makes possible to define signal-flow graphs in a declarative way that maps directly in the way we are dealing with noflo-canvas and noflo-webaudio for now. So we should have a usable noflo-flocking soon.

We already have support for Web Audio API in Android and iOS devices so we can expect mobile music instruments in NoFlo in the near future!

We started the noflo-three components library to Three.js during this time too. We hope the same design we used for noflo-webaudio can be applied to a scene graph like that used in Three.js. We are also making some nice generative stuff with noflo-canvas that we will love to share soon.

noflo-geometry

2014-07-14T00:00:00+00:00

Now that we have a working noflo-canvas it is time to try more complex shapes. Voronoi Diagram and Delaunay Triangulation are canonical algorithms from Computational Geometry and were made classic for generative art or creative coding. These algorithms are useful to create textures or meshes. In general, you can give them a set of points and Voronoi will create cells around your points. Delaunay will draw triangles for each possible triple of points, with non-crossing edges. This figure presents both Voronoi Diagram (in pink) and Delaunay Triangulation (in blue) for some random points (in yellow):

Other examples follow:

To better understand the Delaunay Triangulation, let’s see an example. The following figure shows a triangulation for a set of points. Note the circumcircles around each possible triangle:

There’s no points inside of any of the circumcircles: the points are located right in circumcircles’ edges. You can try to find other triangles which points are not inside circumcircles, but you won’t. Let me give you an example of a wrong triangle:

As you can see, the red points are inside the circumcircle of our green triangle, so it’s not a valid triangle. That’s what Delaunay Triangulation is about: for a given set of points, it finds all the triangles which points are not inside a circumcircle (formed by the triangles).

And what about Voronoi Diagram? There’s many ways to understand what Voronoi algorithm is about, but there’s an easy way now that we know Delaunay Triangulation. Voronoi is dual (or related) to Delaunay. If we connect the center points of all the triangle circumcircles obtained by the Delaunay Triangulation, we have the Voronoi Diagram!

The noflo-geometry implements both Voronoi and Delaunay algorithms. Being NoFlo a general purpose flow-based environment, it is a common approach to search for JS libraries which implements what you want and encapsulate them as a bunch of components. For noflo-geometry we used libraries by @ironwallaby and @gorhill, and thanks to NoFlo now you can use both as components with a common interface, at the same environment:

Here are some examples of tessellations generated by the Voronoi and Delaunay component:

Next steps

Forrest was invited to the super cool Assembly demo party (!!!) so we are planning to work on components for threejs, Web Audio API and timeline to create a demo! Fun times coming, please keep following!

An introduction to noflo-canvas

2014-06-16T00:00:00+00:00

During the last weeks we were working on noflo-canvas and experimenting with it. Here I describe some of those developments and how we ended with the current noflo-canvas design.

Arrays and grids

Following Forrest’s suggestions we have designed noflo-canvas inspired by Grasshopper, an algorithmic modeling tool for Rhino. In Grasshopper you can create an unique point or an array of points using the same component. In noflo-canvas, you have components like MakePoint which receives an unique pair of (x,y) coordinates or an array of them.

When given an array of x and y coordinates, MakePoint makes one point for each pair of x and y. It is like Spreads from VVVV.

Another possibility is to create one point for each possible combination of x and y. MakeGrid does that and resembles the cross product between two vectors (also resembles Cross from VVVV). This example makes it easy to understand:

Such patterns are powerful to algorithmic design because we can create complex shapes using few components. Imagine how many MakePoints are necessary to reproduce the same of just one MakeGrid.

Lazy evaluation

Another interesting detail in noflo-canvas design is how drawing commands are evaluated. Draw is the main component in noflo-canvas and all the magic happens inside it. Take the following program as an example:

Draw receives these commands:

    [{"type": "fill", "items":
         {"type": "circle", "center":
             {"type": "point", "x": 100, "y": 100}, 
             "radius": 100},
         "fillstyle":"#00ff00"}] 

If we remove JSON stuff we get this Lispy representation:

    (fill (circle (point 100 100)
                  100)
          "#00ff00")

Lisp was a great inspiration not only for how we represent commands but on how we evaluate them. Draw parses received commands and applies the respective Canvas 2d method on its arguments.

The entire process resembles a lazy evaluator: each component just has to generate a specific instruction like {"type": "point", "x": 100, "y": 100} and send it to the target component. It repeats until those commands are finally received by Draw that evalutes them.

Connection ordering is important in those situations because we want commands evaluated in specific order: “I want to clean the canvas first, then draw a circle, then …”. NoFlo supports connection ordering which makes this design possible.

This lazy evaluation pattern is becoming useful in FBP, specially when you have to deal with an independent dataflow like the ones of Canvas 2d or Web Audio.

Running on backend

Thanks to node-canvas, it is also possible to use noflo-canvas on NoFlo programs running on Node.js. Flowhub has helpful documentation about how to connect Flowhub on your Node.js runtime.

Node-canvas uses Cairo as its graphics toolkit and we are using it to generate images with high dimensions on backend. Ready-to-use images like that are useful for caching. We are currently reporting experiments of this use of noflo-canvas in this issue.

Auto layout

2014-05-22T00:00:00+00:00

One issue around Flow Based Programming is the amount of time we spend dragging-and-dropping boxes to get the most proper layout.

On a text-based programming language we have at least the left-right and top-down directions to follow. However, in a 2D FBP canvas those nodes can be anywhere and the graph can become really messy.

A proper layout is crucial to make a graph easy to read to both its creator and anyone else (the graph is the documentation).

So we want easy to read graph layouts but we don’t want to do it by hand. Auto layout to the rescue!

Last months we were researching auto layout algorithms on The Grid. There are plenty of techniques and features we can expect from those algorithms and implementations. At the same time, in FBP environments like Flowhub / Meemoo we have many constraints to consider: port ordering, components as groups or subgraphs, input and output “nodes” and so on.

We ended up using a layer-based hierarchical algorithm called KLay Layered which is originally written in Java. It is part of the KIELER Project from Kiel University.

In collaboration with the amazing KIELER / KLay team we developed KLayJS, a JavaScript interface to KLay using GWT’s JSNI. Now we can run the original layout algorithm inside a Web Worker and get rid of all the GWT crazyness. There is already a Bower component to this interface, so you can use that on your own graphs.

The auto layout feature provided by KlayJS is currently available on Flowhub: it’s the magic wand you can wave anytime you want to organize your graph.

While using auto layout we are identifying two scenarios where it is becoming really useful:

When creating a graph from scratch you don’t have to think where is the best place to drop your components. Keep focus on problem solving and just call auto layout everytime you need to align and organize the components;
Auto layout works better when you have grouped components. So it motivates you to keep grouping components together, making it easy to read and document.

Auto layout is not perfect, many times edges crosses and nodes are not well arranged, but it is a handy tool on FBP environments like Flowhub / Meemoo and we want to keep improving it.

Google Summer of Code 2014

2014-05-06T00:00:00+00:00

Thanks to Mozilla I have a project accepted to Google Summer of Code! I am so excited and grateful to Mozilla, Forrest and the NoFlo/Flowhub team! This is my second time in the program: back in 2012 I was mentored by Forrest to work on Meemoo. This year I will be working under Forrest mentoring again, hacking on both Meemoo and NoFlo/Flowhub.

NoFlo is an open source JavaScript implementation of Flow-Based Programming that you can plug in many runtimes like Web browsers, Node.js, GNOME and even Arduino and other microcontrollers. NoFlo empowers Flowhub, a visual programming environment that makes possible to code without real code: like Meemoo, you can code just dragging-and-dropping boxes and plugging them together with wires.

The GSoC project idea is to implement main existing Meemoo modules as NoFlo components and subgraphs. Meemoo is strong in 2d drawing and animation so we will be creating NoFlo components and subgraphs to canvas 2d rendering. The main repository to follow for updates now is noflo-canvas and we wish to give some love to other component libraries like noflo-tween, noflo-webaudio and an upcoming noflo-three.

You can already give noflo-canvas a try running this example on Flowhub.

We hope to get many of the existing Meemoo apps ported to NoFlo near the end of this summer and to create brand new ones. We also like to investigate ways to get Meemoo closer to WebMaker tools: maybe we could use MakeAPI to publish on Mozilla WebMaker Gallery.

This blog will receive weekly updates about what we are working on, so please keep following us!

FBP and NoFlo - another hacker's perspective

2013-08-24T00:00:00+00:00

Meemoo has joined forces with another open-source JavaScript dataflow project called NoFlo. We launched an ambitious Kickstarter campaign which has gotten a lot of positive reaction and is closing in on the goal. Of course, as with any idea around coding, the trolls also come out.

Looking at the FastCo comments and the Hacker News thread, it seems like all critique is focused on the choice of one word in the introduction. Can we move beyond that and talk about actual ideas?

I have used Quartz Composer and Pure Data, but most of my coding was in Flash and JS. Then I started Meemoo to bridge those paradigms and experiment with hackable media. Now I’m working on NoFlo to bring the concept closer to JS for more general programming. I’m looking forward to building Meemoo components with NoFlo, making my code even more encapsulated and reusable.

My biggest issue with QC and PD is that I often wanted to dive into a component and change something. In QC this meant finding the source (if open) and figuring out Objective-C, XCode, compiling… too much friction. We are putting a lot of design into making a useful tool for coders. We’ll be able to edit a component’s JS or make a new component in-place, in a live graph, without changing windows and taking us out of our own coding flow.

So FBP hasn’t been suppressed, and is currently only used in niche industries. The truth is that it hasn’t been tried for general purpose JS, which spans server, interactive UI, canvas, WebGL, Web Audio, and all future niches that JS finds. We’re inviting our early community to help us design the patterns that make sense in those contexts. The beauty of the JS ecosystem is that it will be seamless to connect them.

So FBP isn’t a silver bullet that will make everybody magically understand code. But when I discovered Quartz Composer, my concept of what is possible with code was greatly expanded. My hope is that Meemoo and NoFlo will have that effect on future media hackers.

Open(Art) update

2013-07-07T00:00:00+00:00

Updates

I’m updating meemooapp.tumblr.com more regularly than this blog. You can also see what Matthias, our Summer of Code contributor is up to.

Events

I’m excited to be taking part of three events at Eyebeam NYC in the coming weeks:

July 12th - Open(Art) group exhibition opening. The exhibit will be up until August 10th.

July 13th - Educator media hacking workshop. We’ll be talking about potential ways to use hackable web apps in education.

July 15-19th - Animation workshop for teenagers. In this week-long workshop we’ll experiment with different kinds of animation with the goal of telling a larger story with small GIF animations.

Framework

I have been making some big changes in Meemoo, including one issue that has been open almost since the start of the project: nesting graphs inside other graphs. This is called a “macro” or “subgraph” in other environments, and is key to making big graphs more manageable. Here is a two-minute demo video, and you can try it out on the beta staging site.

->
see you in nyc!
(made with this app) <-

Why web?

2013-04-20T00:00:00+00:00

At the Open(Art) presentations on March 4th one of the Eyebeam fellows asked why I’m making Meemoo for the web, when we can already do the same things in Photoshop or other apps. I’m not sure how well I answered, but there a few answers that I’d like to put in words.

Everest / Demoscene

The easiest answer is “because it’s there.”

I had used data flow environments (Pure Data and Quartz Composer) for some projects. I wanted to combine the modularity, speed, and live feedback workflow that these environments offer with the rapidly expanding capabilities of the browser. Programming in data flow environments feels different than text-based coding. I would wager that they use different parts of the brain. Building this system has allowed me to dive deeper my own programming practice with both paradigms.

Access / media hacking in lockdown

Not everybody has Photoshop. Standards-based web browsers are everywhere.

Not everybody has access to systems where it is possible to install a coding environment. You can use, build, share, and hack Meemoo apps just by visting a url. This is a huge reduction in friction compared to installing a programming envirnonment or app.

Making web-based programming environments does a nice end-run around limitations that iOS places on native apps, that they can’t download and execute scripts. Mobile Safari can do that though; it would be suicide to lock Mobile Safari down to only running scripts from certain sites.

Design for Hackability

Photoshop is designed to emulate the physical tools of photo and graphic manipulation. This design made sense for the first users, who were coming from the darkroom and physical cut-and-paste design.

But web media is much more than static images. To design a creative platform for interactive media and web art, it is fruitful to explore different approaches.

Modular code design

It takes a lot of boilerplate code to do basic things in creative coding projects, like getting an image from a webcam. By making a “cam” module I can easily plug it in anywhere in my projects that takes an image. Every module that I add to the system can be combined with the existing modules, opening exponentially increasing potential for exploration… and we’re back to Everest.

Live edit JavaScript turtle graphics to SVG

2013-02-11T00:00:00+00:00

JavaScript + <canvas>

I recently taught Software Studies for Designers at Media Lab Helsinki. It was a good place to experiment with a group of beginner coders. We didn’t use Meemoo other than to demo what is possible with HTML. It was good for me to step away from the Meemoo code base for a few days and get back to coding from a blank slate.

We started with Khan Academy’s live editor, which has some nice features for experimenting with code. Khan Academy uses Processing.js. Processing was great when it was hard to draw on the screen, but now with the HTML <canvas> it isn’t so hard. Most 2D drawing commands are quite similar, and there are some things, like working with color, that are easier to code directly.

Here are some JavaScript examples that will get you started drawing on the canvas as easily as with Processing. This is not a library: just use the parts you need!

JavaScript turtle graphics → SVG

One of the things that I experimented with is making LOGO-like vector turtle graphics. Why? I wanted to do some algorithmic experiments with the laser cutter in Aalto’s FabLab, and turtle graphics directly translates to the motion of the laser.

LOGO was the first programming language designed for kids. For drawing on screen, it is a little irrelevant, as canvas’ strokeRect(x, y, w, h) is easier than FORWARD 100 RIGHT 90 FORWARD 100 RIGHT 90 FORWARD 100 RIGHT 90 FORWARD 100. But I think that these turtle graphics commands still have a place when they correspond to the real-world motion of a physical drawing robot (or laser cutter, CNC, 3D printer head, etc.).

At first I was doing the save-file/change-window/refresh-browser dance for every change, but tools like Khan’s editor and Mozilla Thimble have given me the expectation that my creative coding should have immediate feedback. So I set out to make my own editor.

Shoutout to Martin Schneider for the code contributions.

It was really exciting to see the laser follow the my coded paths with speed and precision, making my algorithm into a physical thing.

The editor has a few features that I think are nice:

Uses JavaScript, the most ubiquitous language, and outputs web-standard SVG.
Uses Ace, which checks the code with jsHint before attempting to evaluate it.
Uses a worker to evaluate the script, so while(true){} makes the worker hang, not the page. This method is inspired by John Resig’s talk about Khan’ editor.
Compresses and saves code for sharing in the URL hash, no server or API needed. I first saw this method in Mr.doob’s html editor.
Embeds the code and a link to the editor in a  in the exported SVG.

It is pretty easy to piece together coding toys and tools like this, focused on a certain task. From here I’m going to figure out how to do live coding like this directly in Meemoo.

Next Steps

2012-12-04T00:00:00+00:00

In addition to the new modules for MozFest, I have been working on a rewrite of Meemoo’s graphing interface.

Dataflow

Dataflow is a total rewrite of Meemoo’s graph editing interface. I started this project from scratch in order to have a clean start, implementing all that I have learned in the past year. Some of the goals of this rewrite:

Better separation of data models and views. Currently, there is a lot of spaghetti code that ties models and views. Now views just listen to change: events in the models. Currently, canvases are attached to views. In the new version they will be attached to the model, so that different views can show smaller and/or lower-fps preview versions of the full canvas.
This will help make it possible to design and define “app views” for Meemoo graphs. The illustration of a box with UI elements on the lid that can be unscrewed to see the “routing view” below is how Meemoo apps will work. You can use the app as it is designed, but if you want to see/hack how it works you can always unscrew the box, hack, and save your changes.
Submodules will be a way to encapsulate a graph into a module. You’ll be able to define a graph’s inputs and outputs and then load that graph as a module into any other graph. The concept is a bit complicated to explain in words, but it will result in less visual confusion in complicated graphs.
Plugins encapsulate functionality, making it easier to manage the code.
Dataflow is available for other projects to use as well, since it is totally separated from Meemoo’s code. The next version of Meemoo will extend Dataflow’s design and module library.

Hub

I have been working with the limitation of keeping Meemoo 100% client-side. In the next months I will be testing an early version of a “Meemoo Hub” (name to be decided) with features for sharing and remixing apps, modules, and images.

Mozfest 2012

2012-12-03T00:00:00+00:00

My work on web media wiring has come a long way in the past year. Most of my module development effort has been focused on 2D canvas animation and effects. Each module that I create can be recombined with the older ones, expanding Meemoo’s potential exponentially.

Module development

HTML5 video player (meemoo:video/player). Because of security restrictions, if the video is coming from another domain you can’t manipulate the image data (unless the server is CORS-enabled, which is rare). The workaround is to download the video to the local machine, and then select the file in the module.

Tile (meemoo:image/tile) tiles an image, with options for x/y mirroring for seamless kaleidoscope-like images.

firefox flicks video → tile

Grid (meemoo:image/grid) puts each frame of video into a grid, which animates once the grid is full. This module comes from earlier experiments in Flash that were inspired by Run Lola Run Lola Run Lola Run Lola Run.

Particles (meemoo:image/particles) is the most complicated module so far. You can input an image or animation that will become a particle system, for effects like swarms, branches, smoke, and fire.

Trails (meemoo:image/trails) draws to its canvas without clearing, leaving the trails of moving objects. Initially I forgot to clear the canvas when coding Particles, and got some nice effects. At first I thought about adding a “leave trails” option to Particles, but realized that this effect could be useful in combination with other modules. It is nice to be able to make a code idea into a module for instant reuse.

particles → trails → tile

Animation (meemoo:variable/animation) is a new kind of module that I’m experimenting with. It behaves like an array of canvases, and can be sent to the particles module. I will make it possible to save/load animations as a flat spritesheet image.

Chroma/Luma Key (meemoo:image/chromakey, meemoo:image/lumakey) is useful for making transparent backgrounds for animations. These modules are slower than the others, because they go through each pixel. They have potential to be faster with WebGL (Seriously.js), but I wanted to get it working in the 2D canvas context first.

papercraft → lumakey → animation → particles

Mozfest party, Meemoo as vj.js

I used all of these modules to wire together three hours of live visuals and animation at MozFest’s party at the London Film Museum. The music was live-coded by Slub. Getting this gig was a big motivator for working on and refining these modules.

It was great to be able to play with and wire together many different techniques that I have been experimenting with through the years: stop-motion animation, kaleidoscopes, video feedback loops, slit-scan, particle systems, and all the combinations between, and to do so as performance.

cam → feedback loop (more photos)

Before the gig I imagined that I was the only VJ in London going from shop to shop searching for a glue stick. I was also probably the only VJ that was choosing to work within the limitations of JavaScript and HTML5.

The nice thing about Meemoo is that its capabilities can expand with the browser’s capabilities, which have exploded in the time since I started the project. I hope to attract more HTML5 and creative coding brains to the project, since there is much more potential than this one developer can explore.

MakeyMakey + Meemoo

My animation workshop was next to MIT Media Lab’s Scratch and MakeyMakey workshops. I was inspired to unpack my MakeyMakey and made a simple camera trigger switch with a piece of cardboard and two pennies. This made it easier to add images to the animation, since we didn’t have to go back to the laptop.

I talked and hacked for a while with Eric Rosenbaum, one of MakeyMakey’s designers. Our projects have similar goals: to encourage hacking and experimentation with zero installing and configuration. The projects compliment each other well, making it very simple to add physical inputs to Meemoo apps.

I put together this clogging/tap dance visualizer in one hour with MakeyMakey + Meemoo. The shoes have foil on the heels and toes, and the foil on the mat is connected to the ground. Each of the four switches triggers a different particle system, and it looks like fireworks when I dance. It would be fun to connect these triggers to different sounds as well… I guess I need to get to work on audio modules!

My MozFest 2012 conclusion in 140 characters

I got so much inspiration and encouragement this weekend, and hope that I redistributed some % of that back out. #mozfest was serious fun.

Particle experiments

Experiments with circle → particles → trails, changing color, size, and particle system variables.

MozFest tiny film festival :-)

2012-11-10T00:00:00+00:00

Just had our mozfest animation workshop, here is what we made!

Tiger catches bee. @kittycatalayna

bees are buzzing @tangerinebee1

Stickman Flips! By @kittycatalayna

The magical tongue @kingfred111

kitten-catches-mouse by alayna @kittycatalayna

happy birthday firefox! @ioana_cis

rollin eyes @legocoder

sam’s awesome barrel roll

Smile!!!

prancey pony @ncasenmare

papercraft #firefox loves the world @forresto