So I wrote this wicked scripting engine for our top-end sampler engine, but since I’m the main GUI gui as well (call me mister high-level), I’ve been to busy to write any scripts or oversee any of our script writers’ work. This is important because the script writers are used to writing scripts for Kontakt 2, which has a horrible syntax and promotes some pretty ugly style.
Consider Exhibit A:
OK, OK, so the code that you have to write to get anything done in Kontakt is pretty clunky. That’s not to mention the fact that the editor is not resizable and the scrollbar is a total pain to use with the enormous scripts that ship with the product. So we hired these guys to write python scripts for us. The scripts that these guys are doing are very
cool in my opinion; they are writing realisitic note repetition, legato, portamento, overtones, to name a few that I’m actually told about. Also, as matter of fact I think maintaining this scripting engine and accompanying editing facilities is about the coolest thing I’ve seen.
So pretty sick, huh? Well, it’s cool until you go read The Python Style Guide then try to comprehend our scripts. Having my hands tied with C++ bugs, I haven’t had the opportunity to write any example scripts to show everyone how it’s done. The scripts are written like one huge C function, with tons of global declarations everywhere and incorrect use of parenthesis in conditions, poor variable names, and comments out the wazzu.
I guess the only way out of this is for me to re-write them in my spare time to show just how beautiful they might be, and how read: **RAD** this scripting engine could be. I need to re-integrate sys.path into my import hook so we can write some utility modules and get some friggin’ re-usability around here. Being the only python guy around, I guess the success of the engine is up to me, and I’d better jump in there in my spare time for the sake of their creativity and my own sanity:
Consider Exhibit B:
So thinking back to the days when I was writing python 16 hours day, I remember that the code style was everything, and that it worked like a picture. Well, actually more like a sculpture, because it would change face during the development phase and would end up more or less in an unchanging state, like a picture. Modules become between 100 and 300 lines long, each has are one or two classes, the names are short and small, blocks are scimmable and there is no second-guessing about the structure of the object. This is flowing hierarchy at it’s best – governments only which their bureaucracies could run this hot.
The difference is that you can step back and look at your program and get an immediate sense of it’s character with a single glance, which is nothing that you can do with these scripts, other scripts, or any of our C++ code. Remember how your grandma told you that the back of the quilt sheets should be as nice as the front? Same thing here.
My only hope is that I can get my hands dirty prodding the scripting engine a bit by re-writing these scripts correctly and discovering the pieces we really need. These include:
– Re-add sys.path to __import__ for better file system support.
– Include some utility modules as examples for re-usability.
– Allow using emacs as an editor (part of above FS support).
– Refine the editor by…ehem…using it.
Consider Exhibit C:
Code, style, editor. Nice.