CADA Thesis - ProZeuxis

Final Visual Plan

2009-11-17T06:09:00.000-08:00

I did some tests with layering a set of visuals over a pre-recorded
performance from the PreViz final Mock-Up video. I played this
video mock up while triggering events for 4 different layered visuals.
The screen capture from this performance was than layered with
the existing performance footage and associated audio track.
While the screen capture is not that great, the concept seems to be
working out.

My plan for the final execution will including refining these visuals
a bit more before attempting to do this type of performance live
(but in a controlled setting). I will project the same type of performance
that is pictured here over top of these two performers. This will
become an element of the final ProZeuxis demonstration video.
The other elements will include footage of me operating the touch
surface, as well as the screen capture describing how to create the
performance composition using the system.

Mock up - Live Visual from Aaron Lieb on Vimeo.

Now Infused with Audio Interactivity

2009-11-03T05:01:00.000-08:00

Ok - there may look like there is mostly data related
changes going on here - but it is all for a good cause
toward what ProZeuxis always intended to be. That is,
a toolbox where the VJ can plug visual nodes together
in interesting ways with tools that feed these nodes with
input from the performance space (such as audio and
motion tracking). Until now - we did not have this
"pluggin/linking" capability, to make the visuals
performance driven in any capacity.

Guess what? - now we do. Lets just run down the major
development milestones achieved this week, and what
is and is not planned for the Nov 10 Demo:

Node-To-Node Linking (partially complete)
Last round - I implemented the menus and interactions
that allow linking between a midi controller and a
parameter node. This has been taken a step further,
as has always been the intent, to allow a user to link
one parameter node to another directly. This interaction
is working but there are some important points to note:

- Linking between nodes is only implemented for boolean
values at this current time - this was the proof of concept.
Number, point. color data still needs to be worked out

- The menu interaction to link one parameter to another
is done by dragging an icon from the PZNode menu
and dropping it on the icon of a compatible node

- Other ways to create a node-to-node link through the
param panel box and the ability to manage these links
using the [L] icon menu is still yet to be worked on,
and at this point, will not be included for Nov10, but
may still find its way into the final.

Metronome Data Node Created
- A Data providing node called "MetroGnome" was created
for the purpose of providing a Triggering type of boolean
data that can be linked to other nodes (such as enable/
disabling a node, triggering to create a fish, etc)

- The MetroGnome comes with 2 independently configurable
"Beat Instance" subnodes. Each one can have its own BPM
value set by a slider control.

- As a MetroGnome Beat ticks, an output value toggles back
and fourth. This is the boolean value that can be plugged into
visuals or other data nodes that would accept this type of
value.

- One beat's value can even be plugged into the second beat's
enable/disable switch for some interesting results. IE: Beat 1
is set at 220 bmp, and Beat 2 is set at 15 bpm. By plugging
Beat 2 into the enable switch of beat one - then plugging
Beat 1into the "create fish trigger", we quickly pop out a
burst of about 10 fish every 4 seconds.

- The creation of this node proved to be good testing and
preparation for another type of data providing node
such as an audio input.

Sonia Audio
For my first AUDIO related node, I utilized the LiveInput
capabilities of the library "Sonia" (Thus the node name).

- My first audio input node works a whole lot like the
MetroGnome node. It has the same basic structure
that includes an enable/disable switch, a slider value,
and an output trigger value. Except in Sonia, out slider
value controls a Volume Threshold that the live input
is listening for rather than setting a bpm.

- By creating a Sonia Audio node and setting a threshold
value for a LiveInput instance, a user can then Link the
Input Listener trigger to any boolean param node much
like we did with the MetroGnome beat.

- As a first test, I picked on the Create Fish Trigger once
again. Now a new fish is created by making sound into the
microphone. The sensitivity at which this will occur can be
controlled by the Volume Threshold slider. This all seemed
to work with much success (sorry this success happened
a lot later than would have been possible to document with
a demo video)

Nov 10 Demo
So now the fun part comes in. I beleive I have enough now
to put together a more robust type of demo. The only other
thing that I may try to add in terms of data interaction before
locking things down for Nov 10 will be the ability to pass other
values through node linking so I can output the Volume value
as a number as well as the Boolean from my new SoniaAudio
node.

- Other than this change, I will work on one or two new visuals
to add to the set that will best exploit this new capability.
I was looking at a Grid type visual that looks like flashing LED's.
The Grid could change in composition by being linked into the
audio detection node.

- With this new capability and visuals, I will take the system into
a longer space (such as a garage) and captured footage of a
filmed demostration "in the round" so to speak. I will have a
friend asssist me with the filming and executing of this new
demo.

Until then ~AAron

PhotoJournal - Construkction de Tableau

2009-10-26T22:08:00.000-07:00

Lately, the project development has been done with the prototype
table powered Off and this ReacTivision simulator software
turned on. Below:

Essentially this has sped the development work up a good deal, but
has left the Physical status of my prototype a bit lacking. For the
final presentation, I would like to have a much better table in place.
Ideally, it would both look good and function well. So this weekend,
I set to work on remedying the table situation with the help of my
friend. The following photos chronicle the birth of the ProZeuxis
Workstation 1.0.1.

1. Began with a basic frame to house the illuminated plexi touch surface (surface not pictured)

2. Improved mounting bracket for softbox/camera to tripod

3. Surface enclosure closes tightly with cabinet hardware

4. Solution for surface front legs

5. Pre Camera mounting hardware

6. General layout coming together

7. Camera mount (screws into tripod mount through a hole in the softbox covering

8. Mount slides into place

9. Working out first round of design bugs

10. Calibrating camera for ReacTivision / ProZeuxis "road test"

11. Good with tests and some alterations - hanging up for a paint job

The new prototype table that has come out of this week's effort
should suit me well for the preparing and gathering of system
demonstration footage for the final. The previous table would just
not have done the work behind this project any justice. It was
only a matter of time before these measures were taken before I
could pursue serious demonstrations of ProZeuxis in any venue other
than my home.

Prozeuxis Instructional - Midterm 10/20

2009-10-20T06:43:00.000-07:00

For the midterm - I have created an instructional type video
for the ProZeuxis system. The video, unfortunately, rendered
at a file size slightly higher than I could post to the web - so
it will not be available here until I have time to save it out
in parts or at a different compression.

The video introduces the ProZeuxis workspace and steps
a user through configuring two visual nodes. Along the way,
various concepts that may not be self explanatory are
covered in detail. A narrator explains:

- Parameter Grid, Node Configuration Menu, Midi Input
- The design of the selected PZ Node menu
- Moving, Closing, and Opening a Parameter Box
- How to use "Quick Keys"
- Linking a parameter to a midi controller
- Linking multiple parameters to the same controller
- Overwriting a midi controller link

This set of explanations will be expanded upon for the final
defence to include interactions that are not yet implemented.
This will include:

- The remaining two menu buttons [L]ink [R]andom

Link Button:
- The Link Icon button will control whether or not
a Midi input link is Enabled, Disabled, or Not Set
- This button will be colored Green, Red, or Gray to
represent these 3 options
- Pressing the button will toggle between Enabled
and Disabled

Random Button:
- The random button will open a small menu to allow
a user to configure a parameter for random input
- The menu will include a Min/Max selection area for
that type of parameter input
- A Slider for controlling the Frequency that a Random
selection should be changed, (Once, every 2000 ms, ect)
- Also a linkable trigger input that would allow changing
the random value to occur from some stimulus by the
user or some other node parameter (such as linking it
to a key press - or to a audio beat)

Node-To-Node Linking:
- Dragging and dropping a connection between two nodes
of compatible parameters.
- This will allow for interesting interactions within a composition
of visual and other tool nodes

Z-Order Menu (possibly)
- The Node Configuration menu will eventually double as a
Z-Order menu
- This menu would allow a user to change the order in which
visuals are drawn (A Layer Manager of sorts)

Other Convenience Buttons
- While testing the system, many situations come up where
it seems like a function or helper button may be needed.
- For example, a button that closes all open parameter boxes
- A button that will disable all parameter boxes without closing
them - allowing you to freely configure a new node on top
of this surface without "disturbing" open touch panels.
- A pallet for loading saved colors, values, etc
(this may be within a node - but some interface of the core
system would need to be written to allow this to work)

(video now attached 10/21/09)

ProZeuxis Walkthrough from Aaron Lieb on Vimeo.

Developments 10/07

2009-10-07T09:51:00.000-07:00

I apologize for a somewhat limited amount of sync between
the two layers of this demo - some parts synched right - others
did not, but the general premise is there.

This demonstrates two newer capabilities of the system.
One being the management of parameter panels on the
user interface. A use can now close a param panel both through
touching the Orbital Node menu or on the param panel top
left hand icon. Touching and holding the icon also allows them
to dynamically link the opening and closing of the parameter to
a midi keyboard key. A key can be linked to any number of panels.
Unlinking of panels is not currently worked out - does not mean it
cannot be done. This is a low priority feature for the deliverables
of the final defense.

Next is the capability to layer, enable/disable, and effect two
different Visual Plugin Nodes simultaneously. I show a flowing
particle wave visual layered with the Phishstyxx visual.
One of the next capabilities will be to link the source of these
visual params to one another. This way two different visuals
could have some parameter that is shared in a way which
will aid in creating visuals that are synched with one another.

ProZeuxis Developments 10/07 from Aaron Lieb on Vimeo.

Phishtyxx Tests

2009-09-29T05:15:00.000-07:00

This week - the project has some new developments
in two different areas. The first is in the interactions between
the touch screen interface and a visual that is being manipulated.
In this example I show four different touch controls working in
tandem to control a simplistic Fly Swarm visual plug-in. The
graphics in this case are very simplistic - the more important
aspect of this test is the interaction that is accomplished.
The four elements that make this work are:

Enable Toggle:
- used to completely enable/disable the visual

New Fly Trigger:
- used to create a new fly with the current slider settings

Size Slider:
- used to specify a ceiling for the fly size

Color Picker:
- used to specify the fly's body color

Each of these controls can be used simultaneously / independently
from one another.

I am pleased with these results - but the interaction needs to be,
linked to a visual with more sophistication.

The second portion of the video looks at an investigation that I
have done to modify an existing generative fish visual written
in the same technology as my project: koi fish pond
This processing "sketch" example seemed to fit my needs well.
With some modification - I can use this example and apply it
to my interactive visual plug-in - just like the fly example.
Before beginning this process, I began experimenting with
changing the graphics of the fish. For my visual - I prefer
fish swimming side to side, as opposed to a top-down view.
I create a series of new fish "skins" using open source
images of fish from a textbook. This seemed to work nicely.

Second - I took this a little further and separated a layer
to allow the fins, lips, spots, etc of the fish to be tinted a
separate color from the main body of the fish. Now in the
sketch I adapted the way the fish are painted by including
a desaturated layer for the body and the fins layer. I select
two random colors for each fish which is applied as a tint to
the desaturated layers, and painted body first, fins layer second.

You get some funky color combos with a complete rgb random,
but in the plug-in application of this visual, the user will be able
to select more fine tuned color ranges for these elements using
a few color picker touch controls on the surface.

Next steps, of course, are to do this integration work, and also
add constraints on some other parameters of the visual - such
as a central point for the fish to swim around, the ability to
select a background image or another generative element, etc.

Blog 09 - Phishtyxx from Aaron Lieb on Vimeo.

Lighting and Touch area Updates

2009-09-15T06:35:00.000-07:00

Not too much new in terms of highly visible updates from
last week's images and software screen capture (below):

Blog 7 Post Summer from Aaron Lieb on Vimeo.

Important things pictured in this clip are:

- Hardware -

The lighting solution for the surface, as I mentioned, is
a two-fold approach using the IR Led strip from 3m.
The first strip of LEDs spans two sides of the plexiglass
surface for direct illumination. This helps the camera
see very clear blobs for finger touching of the surface
as direct contact from anything rubbery (like a finger)
will break the IR beam.

The second piece is the softbox illuminator for the
ReacTivision tokens/fidicuals. This was better achieve
with IR light as opposed to visible light as well.
One major change included properly mounting the
IR Lighting rig to the inside of the Softbox, and making
the power cable for this component detachable by including
a plug between it and the side LED strips.

- Software -

Still working out the ability to select Parameter nodes
of a visual using a touch selection that will in turn populate
a Touch Grid area with the appropriate touch control for
that type of parameter. I have successfully worked out touch
controls for a Single Value Slider, which can be reused as a
subcomponent of things like ColorPicker, Sound EQ sliders,
and other Value Sliders. This is a pretty basic component that
has come along in terms of functionality since last week.

Of course as soon as I finished creating this piece last night
some other unknown issue surfaced that will need to be worked
out before I can proceed. However, at this point I believe I am
closer than ever to connecting the dots between the touchable
menu components and controlling some sort of example visual
running in a separate window. Even if I just get the ColorPicker
and a basic value slider working from the touch menu I will
be able to achieve some interaction between these things for
next week.

The next steps following this include linking the interaction of
each parameter, not just to it's own native touch area, but also
node-to-node and/or linked to a midi control. A lot of the menu and
data model leg work to make these interactions were taken in to
consideration all along the way - it will just be a matter of populating
the components with the know-how to achieve these interactions.

Long Gaps and Brievity on the State of Things

2009-07-09T21:28:00.000-07:00

I am aware it has been quite some time since updates - I assure you,
work is being done on this project. Work on the blog - is another story.
Hopefully this brief evolution of screen caps of the functioning UI speaks
for itself:

Final Docs

2009-05-04T17:36:00.001-07:00

Final Review Final Review spiral0ut83

Publish at Scribd or explore others:

5.4_FinalReviewEvaluationSheets 5.4_FinalReviewEvaluationSheets spiral0ut83

Publish at Scribd or explore others:

Drafting

2009-04-09T05:54:00.000-07:00

Most of the weeks efforts went into completing this draft.
It did not turn out to be as long as I expected, but hopefully I
was able to say all that I needed to say without going on longer
technical tangents that may have bored everybody completely
to tears. I have also semi-moved into the space in my new home,
where it seems like it will be a better environment to experiment
with this project - so I was able to get that all set up as well.
ProZeuxisPaper_04_09_09 ProZeuxisPaper_04_09_09 spiral0ut83

Publish at Scribd or explore others:

Taskmaster

2009-04-02T15:41:00.000-07:00

     Alright - it's been a little while since the last post, but that doesn't mean
the ball isn't still rolling. Well, it's rolling alright. Let's just try to keep
it from rolling over me.
     This task list / gantt chart, as well as the Research paper, are of coures
ongoing drafts. It seems as if I will actually be able to articulate a much
better task list iteratively along with writing the paper. Some topics that
I start to touch on began to take the tone of tasks that may not have been
accounted for - even in the first few paragraphs. I imagine that I will need
to periodically update all of these documents as the content in one informs
the other.
     What we have here is a decent generalization about how I will go about
completing my research work and the eventual system to back it up.
I still need to formulate these items into the Task description where I lay
out in a brief summary, my planned methodology. This should be pretty
straight forward to work on next - now that I have time to let what I have
put in this first task list a little time to simmer.

Task List
Task List Task List spiral0ut83

Publish at Scribd or explore others: job list

Gantt Chart
gantChart gantChart spiral0ut83

Publish at Scribd or explore others:

Research Paper Draft
researchPaperDraft_04_02_09 researchPaperDraft_04_02_09 spiral0ut83

Publish at Scribd or explore others:

VMenu Look

2009-03-12T06:14:00.001-07:00

These are randomly generated examples of approx
how these menus might look. Eventually - when each
node and subnode is linked to some input or output
parameters, the compatible parameters will attract to
one another based on relative proximity of their respective
tracking markers. This will make it easy to find matches
for linking things without manually drilling down through
menus. This demo is not an example of this "attraction"
just an update on the nascent developments of this ui
concept.

VMenu Look from Aaron Lieb on Vimeo.

Research Paper (WIP 1)

2009-03-02T21:00:00.000-08:00

Maybe a little premature - have a lot of quotable / paraphrasable
goodness going on. It is the basic outline with these refernced items
that support what I may want to pontificate upon / argue included
as place holders. This is how I have written all papers. Good to organize
reference material and align it to your own thinking. My arguments may
need a little sharpening - seems like my thoughts "dullen" upon atmospheric
impact from brain nebulae - to thought meteorite - to research paper crater.

Sounded better in my head / what am I trying to say? / Is it 3 am already? /
Why didn't I think of that / What is eating away at my skin? / What am I
promising I will be able to code / Yes of course it's resizable / In a day?
who knows? Rome wasn't resized in a day / Oh wait, this is my school blog,
not my work blog / wait I don't blog at work / why so many slashes / slash /
another slash / Should I include this in my journal / the power of editorial /
sleep /
prozeuxisResearchPaper2

Publish at Scribd or explore others:

Style Book Video

2009-03-02T18:54:00.000-08:00

This is the video version of the previous post (I hope this is obvious).
These are examples of work that I wish to draw from in my execution of
the ProZeuxis system.
I have chosen to password protect this one due to the fact that it contains
clips of other peoples work. This is an attempt to avoid angry terms of service
violations. Again, a disclaimer, anyone's work will be removed upon request.
Ok - to view the video, the password is "stylebook".

ProZeuxis Style Book from Aaron Lieb on Vimeo.

Style Book

2009-02-28T11:42:00.001-08:00

I'm not looking to reinvent the wheel here. There is obviously a lot
of cross over work in this topic - hopefully what I am planning on
doing will contribute something new. So many interesting projects
and quick sketches by individuals, it is hard to narrow it down.
Every time I would look, there seemed to be something new,
but I had to draw the line somewhere. This is a final compiled "book"
of styles that I wish to draw from for ProZeuxis:

Style Book

Publish at Scribd or explore others:

Yet Another Development Doc (Use Case / Script)

2009-02-27T20:11:00.000-08:00

I have combined multiple needs into one document. This is my answer to
a Script as a software Use-Case. Actual use case documents are actually
even more tedious than this to write properly. There is this notion of
"Pre" and "Post" conditions for each use case. This means, in order to
properly describe a series of interactions, a lot of time is wasted describing
what the laster interaction was, and what the next one will be. By placing
everything in a logical order of how a user might configure a composition
using the system, I think I have accomplished this in a little bit less technical
fashion. If you do not feel that this is the case - comments are welcomed.

PaperProtoTypeScript(Formal Final)

Publish at Scribd or explore others:

Mock System Setup

2009-02-25T06:14:00.000-08:00

More of the same from the last blog software - wise, but
now set up comparably to how the actual system console
might look. "Hardware working in cohesion" - That's
a first. Almost ran into a cable length issue to have the projector,
camera and midi keyboard hooked up to the same laptop.
Luckily, everything ended up being sufficiently long enough to reach.

Mock ProZeuxis System Setup from Aaron Lieb on Vimeo.

MIDI menu - VMenu beginnings

2009-02-24T21:18:00.001-08:00

Ok, so enough documentation and writing papers for a two day span here
(well minimally). I had some ideas about the implementing the menu
system linked to the reacTivison tracking markers. I had to start fleshing this
out just to get a nice reality check on the actual coding of this things.
This shows an update to that (I know I say it's the update for the 23rd -
but the title says the 24th - actually midnight passed between filming and
editing the video - so that is that)

02-23-09 - (Yes - that was yesterday) from Aaron Lieb on Vimeo.

Paper Prototype (revised further)

2009-02-22T16:23:00.000-08:00

Another revision. I have ditched the paper cards (except the
title card) for more fluid overlaid captions. Hopefully the timing
is suitable for most viewers to get the important points. I have
been looking at it too much as it was worked on to be a good judge
of this (as I already know what all the captions and steps are ahead
of time). I think I will let it sit for a few days, get some feedback,
and then do any more revisions as needed. For now, I need to focus
on the research and cobbling together a screen capture video of
reference works that have inspired this one.

Paper Prototype (revised (again)) from Aaron Lieb on Vimeo.

Sequence Diagram

2009-02-20T21:29:00.000-08:00

     Sequence Diagrams are typically used in software engineering
to visualize a work flow of the steps that take place when one
or multiple types of users interact with the system. Well, that
is just what we have here. I outlined a general interaction between
a VJ and Performer user and the system.
     It was not too many years ago that I failed a software engineering
test horribly by drawing the wrong type of diagram altogether as
my response to an open ended (dreaded blue book) question.
Apparently, it was not worth "partial credit". (unless 0% is counted
as a part)
      Anyway, I guess I was not completely soured to their usefulness
for this stage in designing a software. This is a necessary step in
in defining the classes for my UML Class diagram. I picture here a
broad view of the larger Manager and Controller classes that will house
instances of the various types of nodes. I did not want to have this diagram
looking at the finer granularity of the Manager classes sending updates
and configuring individual instances of AudioNodes, TrackingNodes, etc.
This would have made the diagram even more exeedingly difficult to
understand. This way of understanding the system as a set of Input
Conroller and Node Manager Classes that talk to one another is a
bit more straightforward. The place to model the nitty gritty aspects
of the system down to specific parameters and data types would be
the Class Diagram (to be created soon).

Sequence Diagram

Publish at Scribd or explore others: uml diagram

Paper Prototype (Part 1Revised)

2009-02-19T05:54:00.000-08:00

This is a more completed Paper Prototype example.
It goes through the steps you would need to set up the
system to begin using it. The use-case does not by any means
explore every feature described in the Feature Document. This
would probably take 15 to 30 minutes worth of Stop motion video
(like this one) to properly explain each possible usage.
It does, however, visualize the steps for using a combination
of high priority capabilities of the system. This, in a sense,
demonstrates a more realistic picture of what may be accomplished
within the scope of this thesis project. IE. I may not be able to
implement every feature described in the Feature Document, but
I should aim to, at least, complete what is shown in this Paper
Prototype demo completed in some working sense.

[----------------------------------------------------------]
[ ----- Removed from web to reclaim space------ ]
[ -------- Please see the latest version ------------ ]
[----------------------------------------------------------]

Paper Prototype (Part 1 Draft)

2009-02-18T06:55:00.000-08:00

The first section of the Paper Prototype has been posted (with some mistakes).
This needs to be refined and have the rest of it completed.

If nothing else, at least the general idea is coming together.

[----------------------------------------------------------]
[ ----- Removed from web to reclaim space------ ]
[ -------- Please see the latest version ------------ ]
[----------------------------------------------------------]

PaperPrototype (hardware)

2009-02-15T22:27:00.000-08:00

The Hardware portion of the Paper Prototype is complete
(for the most part - missing the MIDI Keyboard yet). Next
I will need to make the sample visuals to clip into the
3 Ring binder "stage" area. Also, I will need to create poster
board cut outs of how the user interface will look. This
step should be pretty straight forward as I can follow the
diagrams that I created for the feature document.
I will then be able to film a stop motion of interacting
with the system. I can cut back and forth between the
reacTable interface, how this is being changed, and then
show how the stage visual has changed. I will have all of the
visuals in the correct order in the binder to follow along
with the interface usages that I am demonstrating.
A visual script of this whole process will have to come
as a natural result of creating the Paper Prototype video.
I can create the video simply based on loose notes, but the
more official script can be finalized as I complete the final
demo video.
PaperPrototype(hardware)

Publish at Scribd or explore others: Academic Work online software

Feature Description (Revised)

2009-02-15T08:43:00.000-08:00

Ok, I have a complete and revised version of the feature doc up as promise.
To do a "story board" equivalent for this type of project, I think it would be
best to create a Paper Prototype (here is an example of what that looks like).
Basically, I will create the physical and user interface components of the
system out of foam core, poster board, etc drawn on with colored pencil.
I will also haveprint outs of what some of the visuals might look like to
represent the final projection. I can then write a script to follow to show a
use-case of a user interacting with the proposed system. While I act this out,
I can also take still pictures to later assemble it into a stop motion
demonstration. This is the plan (that and write the research paper).

1.3 Feature Revised)

Publish at Scribd or explore others: 2008 history

Feature Description ( Draught Version )

2009-02-12T07:04:00.000-08:00

This document started out with the simple concept of outlining the
core features that I would like to include in the system. This began to
take on a life of its own and become almost a type of pre-research
paper type of paper. I ended up needing to read up on each individual
feature quite a good deal before I could acurately describe how each
would work in reality (without making false promises). It's actually not
complete at the time of this writing (will update the iPaper when it is).
I still need to investigate one more topic, and then it will be finished.
Figured it was worth posting in this draft version for the time being.

1.3 Feature Description (semi completed)

Publish at Scribd or explore others: Business culture features

Gathering Sources, Pathogens, and Other useful tidbits

2009-02-10T21:27:00.001-08:00

(I could actually do without the Pathogens part)
Yes - at the time of this writing I am feeling a collection of pathogens
attacking my body. The common cold - nature's original MalWare.

It is about time to start posting useful docs about this ProZeuxis project
I have been so diligently researching. As you know - the general premise
is to use a reacTable interface as a platform to build a VJ software. Very fun
stuff - but a very broad area of research. I have been following trends pertaining
to concert visualization and interactive multimedia exhibits.

A lot of times ...
they are quite intriguing, but at the same time, not very flexible or reusable
for any other application. (Other than - oh, this is my interactive piece -
it does this and that with a camera, microphone, and projectors, etc. It'll
be here in this public space/museum/class room/etc for several days before
it gets packed up and never seen or heard from again). This, to me, is a
serious problem. People are coming up with some cool stuff, but it's not
portable enough... or something (ok lets just mitigate this long rant before
it gets out of control).

Ok, so with this project - I hope to focus on those common hardware
components, cameras, mics, projectors, and their common setup for
interaction, and apply that to the arena of live performance. Concerts,
Dance, Slam Poetry, Group Throat Singing - you name it, it's on a stage -
I want to help enhance it.

To do that, I want to borrow some of these ideas from
previous interactive installations and focus their capabilities
more on "The Main Event" so to speak. In alot of cases, you
have a peice that might have some really powerful implications,
but the prototype showing it off was built in such a way that
its core function ends up being for passers-by of the exhibit
to stand there and just goof off with it for a few minutes - then
move on. Where is the captivation in that? I know it's getting to
be an exceedingly ocd world, but there is still something to be
said about sitting down, shutting up a bit, and sharing as a group
some unique experience.

To illustrate what I mean, take the ending of the Wizard of Oz.
Dorothy, the Tin Man, and Lion go through this whole Kafkaesque
ordeal to get into the Emerald City (E-Town). They finally get in,
and there's the whole big deal with this Wizard and his spooky
hallway leading to his chamber. Now what if they walked in, and
rather than scaring the BaJeezes out of these guys (and every 5 year
old who watched the movie) with his magical Wizard device, he had
them come right over behind the curtain and say, "hey . you guys,
I got this cool wizard device. you want to goof around with it for a
few minutes before I send Dorothy out of this tornado induced coma".
No, no no .... and no. What would the point of spending all of that
time becoming a Wizard and designing the cool device be if that's
all he was going to do with it? He needed to captivate his audience
by leaving that air of mystery, suspense, and theatrical Illusionism
before ultimately revealing the man behind the curtain.
(I hope this made some kind of a logical point - I really do) -
but I digress.

Well - as promised - I will post the completed docs that are in
somewhat of a finalized state.
Enjoy - Happy V-Day - keep it clean.

Thesis Diagram

Publish at Scribd or explore others:

Thesis Revised

Publish at Scribd or explore others:

Happy New Year - New Developments

2009-01-04T21:46:00.001-08:00

ProZeuxis Video Blog 01-04-09 from Aaron Lieb on Vimeo.

I have a pretty good plan on what I will work on within the
next weeks leading up to the start of the semester. I was
probably going to setup the next logical step of allowing the user
to configure a node to be in a specific layer order in the
composite, as well as assign it to a "midi control group".
Once all of the configuration stuff is hammered out, I feel it
will be about time to worry about separating the graphics that will
be seen solely on the ReacTable surface, and those of the projected
composite. As of now, these two are one in the same.

12-22-08 Post (1..*)

2008-12-22T07:20:00.000-08:00

ProZeuxis Video Blog 12-22-08 from Aaron Lieb on Vimeo.

ProZeuxis is the preliminary name for this programming project.
Taken from the Greek myth of Zeuxis and Parrhasius, and a play on
words for Projections.