What I did not realize, at first, is that fmin_slsqp requires a different type of objective function than leastsq.   leastsq requires you to write a function that returns a vector of residuals, and leastsq automatically squares and sums the residuals.  fmin_slsqp is actually more flexible, in that it can use any objective function that returns a single scalar value.  To implement least-squares curve fitting, your objective function will need to find the residual at each data point, square the values, and sum them up.  Hopefully this tip will save you some time.

Check out the scipy optimization tutorial for more examples.  Here is the original paper by Dieter Kraft which introduces the algorithm used by fmin_slsqp.

The main difference between the two models, the 24/48 and 48/96, is the number of hardware faders.  The software capabilities are identical.   The price of the console depends on how many channels of conventional dimming are “unlocked.”  You can choose from 125, 250, or 512 conventional channels.  All models support 1024 channels of moving-light control.  The two hardware DMX ports each support 512 channels, but two additional universes can be accessed via Ethernet (I’m not sure of the details on how this works).  The console seems to support all the basic and advanced cue and effect functions that you’d expect: multiple cue lists, flexible cue timing options, macros, subroutines, and effects.  I can’t really comment further about that, since I would need to spend a lot of time with the console to accurately gauge its reliability and ease of use.  Moving lights are also supported, with fixture profiles for easy patching and a trackball for focusing.  Once again, it looks promising, but the only way to really evaluate these features is to try to use them and see how intuitive the process is.  Download the offline editing software and try it for yourself.

A more sophisticated console called the Rendition Pro is expected to be available in the second quarter of 2010.  The Pro is aimed at more experienced users, and appears to compete with the ETC Eos and Ion.  It will run the same software as the Rendition, so many of the features that are expected to be added to the Rendition are actually being developed for the Pro.  The layout is similar to the Rendition, with playback masters on the left side, traditional cue playback controls in the lower center, and keys to the lower right. Two LCD displays with encoder wheels and softkeys occupy the space above the keypad, with no hard channel faders.  Further, the submasters  have LCD displays and additional buttons–probably “Go” and “Pause”  buttons to support a cue stack on each sub.

From my limited experience, both of these consoles series are worthy of further investigation.  They seem to be solidly built and well-engineered.  The Lehigh personnel that I spoke to were helpful and friendly, and I appreciate their assistance in answering my questions.

#!/usr/bin/env python

from numpy import *

array_len = 10000000

a = zeros(array_len, dtype=float)

#import pickle
#f = open('test.pickle', 'wb')
#pickle.dump(a, f, pickle.HIGHEST_PROTOCOL)
#f.close()

import tables
h5file = tables.openFile('test.h5', mode='w', title="Test Array")
root = h5file.root
h5file.createArray(root, "test", a)
h5file.close()

I first ran the program with both the pickle and the HDF code commented out, and profiled RAM usage with Valgrind and Massif (see my post about profiling memory usage of Python code). Massif shows that the program uses about 80MB of RAM. I then uncommented the Pickle code, and profiled the program again. Look at how the memory usage almost triples!

 MB
232.2^                                                                  #
  |                                                                  #
  |                                                                  #
  |                                                                  #
  |                                                                  #
  |                                                                  #
  |                                                                  #
  |                                                         @        #
  |                                                         @        #
  |                                                         @        #
  |                                                         @        #
  |                                                         @        #
  |                                                         @        #
  |                                                ,        @        #  .
  |                                                @        @        #  :
  |                                                @        @        #  :
  |                                                @        @        #  :
  |                                                @        @        #  :
  |                                                @        @        #  :
  |                                                @        @        #  :
0 +----------------------------------------------------------------------->Mi
  0                                                                   161.9

I then commented out the Pickle code and uncommented the HDF code, and ran the profile again. Notice how efficient the HDF library is:

    MB
81.62^                              ,.., .....,.. .,...,... .,......,..,:  .
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |                              @::@ :::::@:: :@:::@::: :@::::::@::#:  :
   |              .,..,. .....    @::@ :::::@:: :@:::@::: :@::::::@::#:  :::
 0 +----------------------------------------------------------------------->Mi
   0                                                                   246.6

I didn’t benchmark the speed because, for my application, it doesn’t really matter, because the data gets dumped to disk relatively infrequently. It’s interesting to note that the data files on disk are almost identical in size: 76.29MB.

Why does Pickle consume so much more memory? The reason is that HDF is a binary data pipe, while Pickle is an object serialization protocol. Pickle actually consists of a simple virtual machine (VM) that translates an object into a series of opcodes and writes them to disk. To unpickle something, the VM reads and interprets the opcodes and reconstructs an object. The downside of this approach is that the VM has to construct a complete copy of the object in memory before it writes it to disk. I’m not sure why the pickle operation in my example code seems to require three times as much memory as the array itself. 99% of the time, memory usage isn’t a problem, but it becomes a real issue when you have hundreds of megabytes of data in a single array. Fortunately, HDF exists to efficiently handle large binary data sets, and the Pytables package makes it easy to access in a very Pythonic way.

The Element is, in many ways, a much more sophisticated console.  While the Express didn’t have any real capability to run moving lights, the Element has many features to facilitate the use of moving lights and programmable LED fixtures.  It supports two external LCD screens with a full graphical interface, a keyboard, and a mouse. Unfortunately, the Element has lost all of the simplicity that made the Express so successful in its target market.  Let’s start with the physical design.

The greatest disadvantage of the Element, especially for untrained users, is that all of the forty faders (60 in some models) are multi-function.  With the bank switch in position 1, the faders represent channels 1-40.  Position 2 changes the fader function to channels 41-80, and Position 3 changes the faders to channels 81-120.  Position 4 changes the fader function to submasters.  While it’s nice to have 40 subs, it’s also extremely confusing to figure out which channel fader or submaster is currently controlling the output.  Here’s an example.

Let’ s say that you use faders 2, 17, and 31 to set a look on Bank 1.  If you switch to Bank 2, faders 2, 17, and 31 are still up, but they are not controlling anything.  Bring those faders down, and continue setting up the look on channels 41-80 using Bank 2.  Now switch back to Bank 1 to tweak the look on channels 1-40…but the faders are no longer up!  The LEDs on the bump buttons will flash to show which channel levels no longer match the fader positions.  To take control of these channels, bring the fader up until it matches the current channel level.  Then you can control the channel again.  Are you confused yet?  Did I mention that the faders have no numbers?  I find this slows me down when creating a look, and makes it harder to edit a look “on the fly.”  To top it off, the bank selector is a little plastic twist switch, and it’s hard to see which bank it’s pointing at.

With many consoles, you can work around the limited number of faders by adding an expansion wing with additional controls.  Unfortunately, the Element does not support expansions–you have to upgrade to the Ion to get that feature!  I’m not thrilled with the layout of the keys on the Element keyboard, either.  It’s difficult to guess where a key is going to be–they don’t seem to be grouped in any particular way.  Compare to the Hog 1000, in which the keys are grouped as “verbs” and “nouns” for command-line programming.  One final gripe about the hardware: it’s difficult to run my finger down the row of bump buttons to  find a particular light–this was easy to do on the old Express.

So, after all my complaining, I want to leave you with a great feature.  I love the “Exclusive” submaster setting that prevents the output from a sub from being recorded in subsequent cues and submasters.  I use this all the time to keep some lights up onstage or in the house without having them recorded into cues.  I’m sure there are more little gems built into the Express.

Here is my conclusion about the Element: it is NOT a replacement for the Express.  Do not expect this console to be a “drop-in” replacement for any traditional theater console.  The learning curve will be very steep for brand-new users, and slightly less steep for Express users.  In the end, the Element will be far more capable than the Express–but that’s not the target market for the Express.  If you are buying a console for a school, small church, or community theater where the users are generally inexperienced, there are probably better choices than the Element.

In 2007, I went to LDI to try out control consoles to replace our Hog 1000.  That plan fell through when the economy tanked, so this year I was just looking around.  Apparently a lot of people were, because the sales people were rather aggressive about jumping onto any apparent interest in their product.  One girl tried to scan my badge as I walked by–I don’t even know what she was selling!  Actually, that’s a common occurrence at LDI–it’s hard to tell what the actual product is in the booth.  All the larger booths seemed to consist of truss, truss warmers, banners, drapes, moving lights, and video.  I often had to stop and look for a minute to figure out which one was actually their product!

I will post some photos when I get a chance.

Building the Fortran shared libraries

I want to test a library called my_library.  However, this library relies upon another library, which is called cfdrc_user_access.  I want to compile a unit-test program that calls my library and makes sure it is working correctly.

gfortran -shared -fPIC -o cfdrc_user_access.so cfdrc_user_access.f90
gfortran -shared -fPIC -o cfdrc_user.so my_library.f90

Linking the shared libraries with a Fortran program

First, compile the program to an object file (.o), using the -c flag as shown on the first line.  Then use gfortran to link the object file with the shared libraries created in the previous step:

gfortran -c blocking.f90
gfortran -o blocking blocking.o cfdrc_user.so cfdrc_user_access.so

Remember, unless the shared libraries are in a directory that’s already on your  dynamic linker path, you  will probably need to modify your LD_LIBRARY_PATH in order to run the program.

export LD_LIBRARY_PATH=/home/yourname/current_working_directory/
./blocking

That worked for me–hopefully it helps you.

I also bought a Logitech wireless mouse, and found that the middle button works just as you’d expect (paste) in Gentoo running in Fusion.  I didn’t have to install the Logitech drivers in OS X.

Gentoo amd64 kernel config for VMWare Fusion

So far I am very pleased with its performance.  My only disappointment is that VMWare doesn’t support Linux graphics hardware acceleration.

Array arguments

Passing array arguments is a critical when working with numerical algorithms.  F2py handles this well, but it is difficult to figure it out how to do it correctly.  Here is a  simple example with some Fortran 90 routines:

module test

contains

subroutine foo (a)
    implicit none

    integer, intent(in) :: a
    print*, "Hello from Fortran!"
    print*, "a=",a
end subroutine foo

function bar (len_a, a)
    implicit none
    integer, intent(in) :: len_a
    real, dimension(len_a), intent(in) :: a

    real, dimension(len_a) :: bar
    !f2py depend(len_a) a, bar

    integer :: i
    real, dimension(len_a) :: b

    do i=1,len_a
        b(i) = 2.0*a(i)
    end do

    bar = b
end function bar

subroutine sub (a, len_a, a_out)
    implicit none

    real, dimension(len_a), intent(in) :: a
    integer, intent(in) :: len_a
    real, dimension(len_a), intent(out) :: a_out

    integer :: i

    do i=1,len_a
        a_out(i) = 2.0*a(i)
    end do

end subroutine sub

end module test

Function “foo” is quite straightforward. Function “bar” is a little more complex, because it accepts an array argument and returns an array. If you’re new to Fortran, it will seem strange to pass the length of the array along with the array, but you need that information to declare the output array. f2py needs to know that the input array a and the output array bar both depend on the argument len_a.  The special comment line

!f2py depend(len_a) a, bar

is mandatory!  It tells f2py that a depends on len_a.  If you omit this comment or the corresponding one for, the function will not work correctly.  You will get strange errors like

ValueError: failed to create intent(cache|hide)|optional array-- must have defined
dimensions but got (0,)

Fortran subroutines

Now look at the subroutine called sub.  On the Fortran side, it has three arguments: two inputs and an output.  However, Python only has functions,  and all non-array arguments are passed by value.  How do you reconcile this?  When the Fortran subroutine is called from Python, the intent(out) variables are returned as a function result, or a tuple of results if there are more than one.  Compare the Fortran code above with the Python call below to see what I mean.

Building

This code can be compiled using the “fast and smart” method described in the docs:

f2py -m -c hello hello.f90

Here is the Python code that calls the Fortran routines:

#!/usr/bin/env python

import hello
from numpy import *
a = arange(0.0, 10.0, 1.0)
len_a = len(a)

print "foo:"
hello.test.foo(len_a)

print "bar:"
a_out = hello.test.bar(len_a, a)
print a_out

print "sub:"
a_out = hello.test.sub(a, len_a)
print a_out

You might also want to check out this rather complicated f2py example.