Hiatus alert
I'm going to be taking a short hiatus from Genome to work on an iphone app. Should take 1-2 months. I hope to still do one or two things on genome each week so I don't get totally rusty on the codebase. I am planning to do an analog synth/drum machine (think of a Korg Electribe A and R combined). There are already a ton of drum machines on the iphone but most are sample based and the output is not really anything unique or interesting. For instance, there are several Rebirth clones, but they don't offer parameter automation which results in some boringly static basslines. Other synths don't feature drums or are limited to mono sounds. I'd like to make a flexible drum/bass synth with up to 16 parts. Each part could be a synth drum sound or a mono bassline. All parameters would be automatable with easy to draw graphs. The goal would be to give it a lovable character of it's own similar to how LSDJ on the gameboy has spawned an entire genre of music with it's unique sound. We'll see whether the iphone's 667 mhz processor is up to the challenge.
I am already learning a lot about how to design a touch-based application for a small screen, especially one that involves a lot of parameters like a synthesizer. I'll post a few of my wireframes oon.
I'm looking to use LibNUI for this project since it supports iphone development in C++. I'd love to use Juce, but no telling when it might support the iphone. (With my luck it will be out just as I am finishing this project up). Expect a post comparing LibNUI and Juce. They are both pretty similar in terms of design goals (cross platform frameworks supporting sound, gui, networking, etc). I still like Juce better, but there are some interesting features features of libNUI that deserve a look.
Currently I have a simple application up and running on my iphone and I already coded my first custom NUI GUI widget.. I have lots of code ready to go in the synthesis department, so it will mostly be a lot of GUI work. I will be using a version of the same audio framework I developed for Genome. It will give me a chance to try out some optimization tweaks I've been thinking of for Genome, on the iphone.
Module View I
- Implemented tags for modules
- Added a more proper module menu. It can be configured via XML and is based off tags.
Work Log
- modified alt-drag behavior in piano roll. No longer destroys notes as you drag
- fixed a bug that was breaking undo behavior in the piano roll
- Other bug fixes and updates to the piano roll. One or two other fixes left to do here, but I am gonna move over to the module view next.
To do:
Implement tagging of modules and improve the module creation process.
Optimizations I
- Optimized Piano roll rendering. 2-3x faster now for most things.
- piano roll: made some visual tweaks
- piano roll: added new commands, insert time, delete time
- piano roll: made it possible to bring up menu with keyboard (ctrl-space)
Updates
Finished up a few more items on the song view. Tempo changes are now possible. I also fixed some bugs and updated the current mac build. There are still a handful of issues with the song view that need to be fixed, but I may move on to other areas to beef them up. One important area is optimizing the screen redrawing of the piano roll and song view. I'm very interested in music apps on small form factor devices at the moment. I've been toying around with the idea of doing an iPhone or PSP music app. The easiest solution though is just get Genome working on a netbook. That should be no problem, but I want to be sure that it runs fast enough on those less powerful processors. Currently it's struggling a bit on my quad core, so that's a problem. No optimization has been done, so no worries yet. I think a netbook with a touchscreen would be a pretty cool way to run genome.
Song View VI
Nearing the light at the end of the tunnel for the song view
- Many fixes and additions concerning mouse / keyboard selection and control. This is one of my favorite areas to work on (though it can be time consuming) since sometimes small changes to the feel can have a big impact on usability
- added keyboard shortcut for adding markers. other fixes concerning markers (missing undo's, added doubleclick to split a marker, etc..).
Still to do in this phase:
- Tempo markers, tempo box
- 6 or so small fixes and additions
Next Phase: Improve control surface functionality
Song View V
- Added GUI widgets for pan / volume on tracks.. Still not set on how to lay them out exactly
- Double Clicking on a pattern now takes you directly to the editor for that pattern (such as the piano roll)
- ctrl-space sets current pattern to whatever pattern is under the cursor
- numerous usability tweaks and fixes
Song View IV
Been a while since I've posted, but I've been hard at work on the song view. Keyboard controls are working now - you can use the arrows to move through the list of tracks and move a cursor. Overall I mirrored the piano roll for consistency - the cursor works essentially the same. Spacebar inserts a pattern, you can select/cut/paste using the 'cursor'. The mouse also controls the cursor and allows you to select, add pattern (double click) and remove patterns.
The UI in genome is going to be all about speed and ease of use. Whereas most sequencers rely heavily on the mouse and toolbars packed with different editing modes, genome can be controlled entirely with the keyboard, a combination of keyboard and mouse, or just with the mouse. There are no toolbars required for standard editing. Genome's toolbar is purely for navigation, file i/o, copy/paste, etc.. I find having to switch tools only slows a person down (ie, having to click the 'eraser' if you want to delete something, or the scissors if you want to split a pattern, etc..). A lot of sequencers don't even have keyboard shortcuts for common actions. While keyboard shortcuts should never be relied exclusively (since they are 'hidden' from the user), they are a great help for advanced users who already know the ins and outs of a program and want to get things done faster.
Another thing that really irritates me about today's sequencers (and even a lot of VST's) is that they try to pack too much information on one screen. A lot of musicians seem to think that having 100 knobs, all exactly the same size and color is acceptable, as long as they have access to all the parameters. 'Maximize your space', I've heard people say. What a load of crap. Space is part of the design, and never wasted. A good UI design has a hierarchy of information. More important or commonly used controls should be bigger, set apart or otherwise distinguished. Less common controls can be made smaller or shifted to another logical tab or page. Trying to cram everything on one page does not make things faster or easier - usually the opposite, since people will need to spend more time scanning for what they are looking for. It's okay if the user needs a couple clicks to find something, as long as he has no trouble figuring out where he is going. The layout of the controls on a page should reflect a typical user's workflow - the first items they need to edit should be first on the page, and the sequence should follow left to right, top to bottom, the order that a user would need to go through them. Buttons should be big enough that pressing them (or finding them for that matter) is not tedious. Icons, unless totally self explanatory, need labels! I can't tell you how frustrated I get when I open Cubase, Live or almost any other big-name seqeuencer/workstation software. The learning curve is so high. If the web has taught us anything, it's that it IS possible to write software that is intuitive enough for people to figure out without needing an instruction manual - we just need good design. Unfortunately, a lot of design decisions end up getting made by programmers or people who don't have good UI experience (or who are trying to save themselves some work). Also, a lot of music software tries to immitate the look and feel of music gear, which (though cool looking) is rarely well designed. Try to program a beat on a typical drum machine, I guarantee you can do the same thing 10 times faster on the computer, where you don't have to memorize esoteric combinations of buttons, and aren't limited to a 2 line display. Why try to imitate devices that have had to make UI sacrifices in the name of hardware limitations?
It's also been said that good design involves removing features until you are left with the bare essentials and I'm going to be experimenting with this. Maybe we don't need to see audio waveforms or every note in a pattern, on the song screen. Does that information really help you make a song? Maybe we just need to know what pattern it is or maybe we can just hear what pattern it is. Taking away features like that reduces the visual complexity and should make it easier to find what you are looking for. It's also less intimidating for new users. Keep the UI simple. This is music, not nuclear physics.
SongView II
- Added 'Play Section' buttons to sections
- Began adding keyboard shortcuts for switching current track, adding patterns
- Added ability to have a 'focused track'. Focused track expands to show extra info.
Song View II
- Successfully rewrote Song module internals
- Next up - implementing tempo changes