Saturday, May 20, 2006

Py eq Better Performance

Are python programmers better than other programmers, or is python just better than other programs? If the added overhead of writing tools to use our tools still allows the code to be written faster and better than with their tools, isn't there something wrong?

In my general discussions about problem-solving, the talk almost
always comes back to "how can we get that into python?". Python
programmers being more agile means that they can work in more places
because writing extensions for it is so bloody easy.

When I found PyQt, the first thing I thought was "how can I write
an audio app with this?" When I needed midi input - I found a C++
libary and wrote an extension - in one day. When tasked with writing a
sampler interface that is aimed to become the industry standard, I
decide its STILL faster to write an extension so I can prototype in
python. In the corporate world my co-workers and I were consistently
solving problems light-years ahead of others - we were even doing
other departments' work because they couldn't deliver their product
fast enough!

The scary and confusing part is that I find myself falling into a
rut where I am constantly writing code as proof that my tools are
better, but its not doing anything for me. WHY WHY WHY!? Why can't
they see that even a dodgy grasp of client/server computing allows for
ANY graphical toolkit? Why can't they see that ONE man can write and
maintain the whole bloody site if it uses plone? Why are they so
afraid of success? WHY?!?

Tuesday, May 16, 2006

Iterations and Testability

A streaming system is easier to test if modelled at its smallest resolution.

For example, in stream.render(window), window could be a floating-point time window in seconds. If your system has a resolution of 1 nano second, make stream.render call stream.render_nano(). That way if you know render_nano works, you can safely move to testing render() all together.

Monday, May 15, 2006

The Ideal Code

I found a light at the end of the tunnel of my portion of the cone of learning tonight. It involves resolution of the conflict behind comments, whitespace, prototyping, and optimized (reading, running) code.

Ideal code is atomic. It is divided into separate coherent blocks,
each with one and only one purpose. There are no comments, and each
block is atomic; it cannot be divided any further. Each block fits
into a grand and dynamic scheme of how it can be used, almost like a
tree. The leaves of the tree are the most frequently used blocks of
code, and as you follow each branch inward toward the trunk the code
is used less often, but uses a higher total number of aggregate
functions, and so becomes "higher level" code. At the trunk, starting
just below the lowest branch is the application, which cannot be
reused. It is an executable script, or a compiled program that defines
the end user.

Now, how can you imagine code without comments, or no newline
whitespace, or with that 300-line drawPerson() member method? I find
that all of these are used in intermediate steps toward that perfect
peice of code. You absolutely *must* write code that has gaps and
holes and yes, bugs, in order to massage the solution out of the
problem. My comments are # optimize for anti-aliasing?, or # ugly! My
methods that have double newlines or comments like ## PUBLIC ACCESS
really should be delegated to another, more specific method.

Learning how to write code to assist your understanding of the
problem is 100% of the battle. Leaving yourself notes in places where
you and only you know you'll find them is critical to the evolution of
your solutions. Jumping the technological hurdles for your problem
first and staying out of the write-the-app the solve-the-problem
metality will save you time and sanity when you are put under that
hammer of a deadline, personal or professional.

These are the reasons that highlevel languages that encourage
prototyping are essential to approaching time-comsuming and
energy-sucking problems, and why a language that looks as nice on the
inside as on the outside is just as important. This is also why I
choose python. I guarantee that I can optimize any Qt app written in
python using C++ with minimal effort, having fully understood the
problem by writing the python code.

Wednesday, May 10, 2006

Intel or Almost Intel

I bought an intel iMac and have found that most of the programs that i want to run on it are still compiled for ppc, so they are quite slow.

OK, Ok, granted I've become a bit of a snob lately about the tools I use according to their availability, but shoot, I don't want to compile ardour's massive dependency tree! libsndfile - that's as far as I go! sheesh. I'm actually considering going from jack to gtk, while this iMac is supposed to be a virgin deployment ground for the pksampler. ewwww

Tuesday, May 9, 2006

Functioning Sequencer

So the pksampler has a nice draggable synth/effect/pattern interface, a pattern editor, and nice fat scrollbars. The guts of the whole thing is the OSC sequencer interface, which remains very buggy but at the same time very slick. I'm going to sit back and enjoy the code, try to get it some publicity, and let the next step fizzle its way into my brain.

So yes, the current code gets you noise right off the bat. Make sure you download and unpack pksampler-patches.tgz. The current code exhibits the fundamental pksampler concepts, which are very similar to Ableton Live. You drag synths and effects onto the mixer, and drag patterns onto the synths to get them to make sound.


New synthesizers can be defined by writing synthdefs for supercollider and putting the compiled files in ~/.pksampler/synthdefs, then adding a Synth subclass in pk.sampler.synths to provide access to the synthdef's name arguments. Currently pksampler-patches only has a sine generator.


The synthesizer/sequencer concept is complete, so the new phase will focus on getting it to be more of a wav file player for dj's. This will include very nice beat-matching controls, tighter starting/stopping, and volume.

Tuesday, May 2, 2006

Elements of Artistry

I had a vision today of some really advanced graphical interface characteristics that are waaaay out of my reach.

People that make the kind of UIs I want to make spend all of their time on UIs. They are graphic artists, and smart enough to peice their art together into a functional interface. Thinking about how I currently dwell somewhere in between systems, app, and UI-level code made me realize that I know about as much about where I am going to end up professionally as a high-school graduate knows about what he's going to do for a living.


Everythin I'm doing right now is a lot of fun, but amounts to nothing in the grand scheme of my life in code. I am doing nothing more than gaining the experience to one day learn where it is I really want to land.


I'll tell you what, if I could make music like the stuff I'm listening to on friskyradio right now I'd be pretty well chuffed with my life.