Archive for August, 2011

ITP Cafe [come see us @ maker faire]

Monday, August 29th, 2011

I am happy to be involved in the coordination of the ITP Cafe for the Maker Faire in NYC this September. At this year’s event we are planning to host a series of hands-on sessions and demos. Please spread the word. We hope that you, your family, and friends will join us for a weekend of fun and learning with technology.

We plan to cover a wide range of topics including basic programming with processing, intro to physical computing, making sounds with an arduino, building soft and organic circuits, diy portable air conditioner, making your own wind power generator, learning to hack the kinect, and basic screen printing.

The final session list is still in the works, as soon as it is completed I will share it here. To buy your tickets, just click on the banner below and you will be taken to the official maker faire NYC 2011 page.

Maker Faire 2011


HSB to RGB [arduino library]

Sunday, August 28th, 2011

The first version of the firmware that I created for Bright Words only supported changing the color of the lights by controlling the RGB values – red, green, and blue. From a coding perspective this is an easy approach since it is consistent with the physical set-up of the device (the red, green and blue lights are each controlled individually).

Unfortunately, this is not a very intuitive way to cycle through colors. The HSB color model (hue, saturation, and brightness) provides a much more natural approach.

Intuitive Control
By supporting direct control of the hue, users are able to cycle through all colors that are of the same saturation and brightness. Users can use the saturation setting to select the appropriate tint of a color. Tints are essentially mixtures of a color with white. The brightness setting enables users to select the appropriate shade of a color. Shades are mixtures of a color with black.

Higher saturation and brightness levels resolve to stronger colors. A color with no saturation will be achromatic, or in other words, it will have no color. Such a color will range between white, grey and black. A color with no brightness will always resolve to black.

The Code
After deciding to take this route I searched online to find existing code samples that I could use to guide my own work. I found a few examples that were written for the Arduino, though in the end I decided to create my own code from scratch so that it would be structured in my own way. I’ve formatted my code into a simple library that you can download from the github repository.

Here is a brief overview of how to use this simple library. It features two methods that do the exact same thing, they just take different input parameters. Both of them accept 4 different parameters: hue, saturation, and brightness values, and a pointer to an integer array that can hold at least 3 elements (the r, g, and b values).

The difference is that method HSBtoRGB accepts hue integer values ranging from 0 to 360, and saturation and brightness integer values ranging from 0 to 100. The method HSBtoRGBfloat accepts hue, saturation and brightness float values ranging from 0 to 1.

Resource Links


Learning C++ [understanding makefiles]

Monday, August 22nd, 2011

I only recently started working with C and C++, both developing my own projects (simple ones), and installing packages that require local builds. In this short time I have come across numerous makefile. Unfortunately, I had no clue what the hell is a makefile, that is until now.

Here is one line description I came across earlier today: “Makefiles are special format files that together with the make utility will help you to automagically build and manage your projects.” [from http://mrbook.org/tutorials/make/]

Make files were created to facilitate the tedious process of building projects that are comprised of multiple files. They help ensure that each file is compiled with the appropriate settings, and that files are compiled and linked in the proper order. This is specially useful, since most projects need to be compiled hundreds of times during the development process.

Makefile Structures
The main section of make files is comprised of a list of targets elements. Each one of these target elements is associated to dependencies, and commands that should be run when those dependencies are met. These files also hold information such as variables that can be used to capture compile options or to streamline the system commands and dependency descriptions.

Here is an example of the syntax for each target element pairing:

target label: dependencies
[tab] system command

The way to read these target element pairings is as follows:

The target label is just an identifier that functions similar to a variable name. It is good practice to make the target label consistent with the name of the file that is generated by the command associated to a target element.

For example if the system command for a target element generates a file called compiled_file.o, then a good target label would be compiled_file.o. It is not always possible to follow this guidance because sometimes you may have commands that generate multiple files, or none at all.

The dependencies feature one or more target elements that need to be ready before the command associated to the current target element is run. Sometimes variables are used to identify groups of dependencies. There are also instance where a target element has no dependencies at all.

The commands are standard unix/linux system commands that can be used in a terminal/console to compile or link files – they specify a compiler followed by compile options such as flags, input and output file information.

Sometimes a target element has no associated commands. Why is this so? This strategy is often used to confirm that multiple different targets elements have been compiled before a makefile ends.

Here is a brief overview of how to use variables in a make file. There are three important things to keep in mind. First off, all variables need to be defined at the top of a make file before the target element pairings. Here is an example of a variable declaration:

variable=gcc

Secondly, there is no variable typing since all variables hold text information. Lastly, you need to use a the following syntax to when using a variable (but not when declaring it):

$(variable)

Here is an example of what the contents of a makefile may look like. This is a pretty simple makefile that does not make use of any of the more advanced features of a makefile (considering the focus of this tutorial has been on providing you and me with a basic understanding of how makefiles work). This example was taken almost verbatim from http://mrbook.org/tutorials/make/.

compiler=g++

all: hello

hello: main.o factorial.o hello.o
	$(compiler) main.o factorial.o hello.o -o hello

main.o: main.cpp
	$(compiler) -c main.cpp

factorial.o: factorial.cpp
	$(compiler) -c factorial.cpp

hello.o: hello.cpp
	$(compiler) -c hello.cpp

clean:
	rm -rf *o hello

You can download a pdf version of this tutorial (if you can call it that) here.


Bright Words [multi-colored strobe light]

Wednesday, August 17th, 2011

It all started with an 80s themed party. We wanted to go all out, music, costumes, drinks, and decoration. We were talking about lighting when the movie cocktails came up in conversation. I happen to have a bunch of rgb leds lying around looking for something to do. So I decided to create a multi-colored neon-styled strobe light, called bright words.

Here is a video that showcases the current prototype. This is a work in progress, as I have plans to play around with connecting this device wirelessly to a computer or mobile device via bluetooth or wifi.

Bright Words [multicolored strobe light] from Julio Terra on Vimeo.

This is a DIY project that can be recreated using a laser cutter, some microcontrollers, electronic components, and circuits. This project is a bit complex than my other DIY projects, so I will need to create a separate material lists with instructions. Production files for the box will be available in Adobe Illustrator and svg formats. Schematics will be provided for the circuits, along with a list of materials. I will post a link here when the project is uploaded to thingiverse.


Learning Objective-C [concept: dynamic language]

Wednesday, August 17th, 2011

I have recently started a personal curriculum to learn how to code in Objective-C. At this point I have barely begun to scratch the surface. This is my first of set of notes, which focus on the structure of Objective-C from a purely conceptual standpoint. I hope this material can also be helpful to others, and let me know if you have anything to add. You can download a pdf copy of these notes here.

These notes will probably only make sense to you if you have some knowledge of object-oriented programming. My source material to date has been limited to a few sections of the documentation from the Apple Developer Website, and an excellent 4-hour kitchen table session by Nolen & Pitaru.

Why is Objective-C a Dynamic Language
Objective-C is a truly dynamic object oriented programming language. It was designed to make to shift as much of the decision making as possible to runtime, from compile time and link time. This is in contrast to most other languages, both procedural and object-oriented ones, which mandate that variable typing and relationships be defined in the source code at compile time.

Dynamic languages are ideal for systems where components are loosely coupled, such as in user interface design and development. They allow applications to be structured like networks of objects that are able to work together to respond to external events. The objects act as “agents” that work in a coordinated fashion to carry out the program’s intent. Each object has a particular role to play, and within that role it can act fairly independently of the other parts of the program.

Ok, up until this point it sounds pretty much like standard object-oriented programming mumbo jumbo. This is where it starts to get interesting. In Objective-C, the messaging architecture separates the message (the requested behavior) from the receiver (the owner of a method that can respond to the request). The messaging metaphor is used to capture the idea that behaviors (or methods, in old school oop parlance) can be abstracted away from their particular implementations (or classes).

Ultimately this means that at compile-time objects only need to know the abstract behaviors, or actions, they can request from other objects. The concrete behaviors that is actually requested is only determined at run-time, when the recipient of the message is identified.

Let’s dig a little deeper into the three specific types of dynamism provided by Objective-C, and the new possibilities they create. Here is a short list followed by brief descriptions along with short overviews of the possibilities create by each one.

  1. Dynamic typing: identifying the class of an object at runtime
  2. Dynamic binding: determining what method to invoke at runtime
  3. Dynamic loading, adding new components to a program at runtime

i. Dynamic Typing
Dynamic Typing permits the type of an object be determined at runtime rather than forcing it to be defined statically in your code. This creates the following possibilities:

  • An object can be passed via a message without defining what kind of object it is at compile-time. The type of object being passed is only determined during runtime.
  • An object that is receiving, and responding to, a message can also be left undefined until runtime. Therefore, the action will be taken is only determined at run-time when the receiving object is identified.

ii. Dynamic Binding
Dynamic Binding enables the program to determine which method to invoke at runtime. Dynamic typing and dynamic binding are closely related. They work together to open up the following possibilities:

  • Message can have very different results depending on the class of the receiver, which is determined when the program is running based on runtime factors.
  • Messages can be sent to objects that were not invented when your code was originally written. New classes just need to agree on the messages to enable communications from your code.

Dynamic binding available in Objective-C differs from late binding, which is a more limited type of dynamic binding supported by many object oriented languages such as C++ and Java. Late binding enables an object to be typed using a generic, or high-level, type. At run-time the actual objects handled by the application are sub-types that inherits from the generic type defined in the source code. As you will note, this type of binding still requires that a specific type be identified at compile-time.

iii. Dynamic Loading
Dynamic Loading allows different parts of an executable program to be separated into their own files. The program is then launched in bits and pieces, new parts are dynamically loaded and linked as they’re needed. Dynamic loading raises several interesting possibilities:

  • It enables software to be developed in a more modular fashion. An entire program does not have to be developed at once; it can be delivered and updated one part at a time.
  • Programs can run more efficiently by enabling users to load just the tools that they need, enabling users to grouping of tools under a single interface, and enabling them to select between, and load, different tools to do the same job.
  • It makes your application more extensible, making it easier to add to and customize your creation. All your program needs to do is provide a framework that others can fill in, and, at runtime, find the pieces that they’ve implemented and load them dynamically.

Firestand [diy laptop stand]

Sunday, August 7th, 2011

Space is a luxury in my small apartment, and even more so on my overcrowded work table. I created Firestand to hold my 13” MacBook Pro on top of my M-Audio FireWire 610 audio interface. It has helped me reclaim over 67 square inches of space on my desk (and, yes this is an accurate calculation of my space savings).

I decided not to purchase a laptop stand because the ones that I like are either too expensive, or their design does not accomodate my audio interface underneath the laptop. I also happen to have 12″ x 24″ piece of plexi lying around my apartment.

This is a DIY project that can be recreated using a laser cutter. All you need is a 12” x 24” piece of plexi (1/4“ thick), acrylic cement, and a few hours of spare time. Production files are available in illustrator, svg, and dwg formats. Here is a link to the files and instructions on thingiverse.

Here is a slide show with some photos of my first prototype (which will probably be my only one).


AMUP air [controlling traktor duo]

Saturday, August 6th, 2011

AMUP [Traktor Duo Test] from Julio Terra on Vimeo.

I recently switched gears on my AMUP project so that I could focus on getting the controller to work with Traktor Duo. The video above is the culmination of my work from the past two weeks. I am happy to report that I have been able to get these two to play together very nicely.

Most of my time has been focused on testing different control layouts so that I could determine what functionality was most important, and how best to group the various controls. For the most part, I found Traktor’s mapping functionality to be pretty good – it ultimately let me do almost everything I wanted to. The issue is that the interface that you need to use to create the mappings is rather cumbersome.

To help you understand how AMUP actually works, here is a description of the mapping of Traktor functionality to AMUP switches, buttons and knobs.


AMUP [generic midi map]

Saturday, August 6th, 2011

Over the last couple of weeks, while I worked to get AMUP air working with Traktor Duo, I decided to create a generic midi map for AMUP that I could use with Traktor, Ableton and any other midi-controlled application.

The controls from the console send midi messages on channel 16, while the button and air panels send messages on channels 0 and 1. The led buttons have 5 different states – they are off when in state 0, and they have a different color for each of the other states.

Here is a chart with a detailed overview of the midi mapping for all AMUP air switches and sensors.


Catsurf [laser cut cat scratching pad]

Saturday, August 6th, 2011

Cats love to surf, at least in my dreams. In real life, I know they actually love to scratch. With waves made of cardboard they do can do both. The inspiration for this project is Sasha, a slinky little oriental short hair. She was my first cat, and she was as playful as they come. Unfortunately, Sasha recently passed away but her inspiration lives on.

Earlier today I cut the pieces for the first catsurf prototype using the laser cutter at SSX. The cut did not turn out as clean as I hoped, in large part because I didn’t have time to do a second run (which I will plan for on the next round). Here is a slide show of the unassembled cardboard layers (you’ll see that we had a few visitors at the shoot).

This is a DIY project that can be recreated using a laser cutter and some glue. All you need is five 12” x 24” pieces of cardboard, a 12” x 12” piece of collored plexi, some screws, glue, and a few hours of spare time. Production files and instructions will be made available soon on thingiverse.com (I’ll add a link to the post here).

Specifications
dimensions: W 10”, L 11.5“, H 2.4”
prototype version: 1.0
created on: August 3rd, 2011