White Noise - Audio, Programming and Multitouch

Bleep!BOX Released

2009-08-18T04:39:00.000-07:00

contact@bleepboxapp.com
www.bleepboxapp.com

White Noise Audio Software Releases iPhone App bleepBOX!, an Analogue Synthesizer / Drum Machine Combo that Fits in Your Pocket

KENNETT SQUARE, PA – August 17, 2009 – The beat box just got pocket sized. bleep!BOX, an analog syth/drum machine debuted in Apple’s iPhone App Store on Saturday, August 15, 2009. bleep!BOX allows users to arrange synthesizer melodies, program drum beats and edit dozens of parameters in real time. Unlike other music apps, bleep!BOX does not limit users with fixed sample sets or pre-made loops. It does not use any samples, only tweakable, analog-style sounds.

Developer Dave Wallin, owner of White Noise Audio Software created bleep!BOX after becoming frustrated with music apps available for the iPhone. “Only two types of music apps were available: simple music toys and music makers. The simple music toys become boring fast and had limited usefulness and the music makers didn’t offer enough options to make a song interesting. bleepBOX! strikes that balance between simplicity and creative potential.”

Similar to the controls on a vintage analog synthesizer, bleep!BOX gives users creative license over waveforms, filters, effects and modulation. It features 50+ parameters and can play up to 10 instruments simultaneously.

“There are a lot of musicians who don’t like using already-made loops,” said Wallin. With bleep!BOX you can program all of your own sounds and make the melodies you want instead of using canned loops or samples. Now users can produce real music on their iPhones.”

bleepBOX!, sold solely in Apple’s app store, costs $9.99 USD and requires iTunes. Click here for the iTunes store link for bleep!BOX.

White Noise Audio Software produces innovative computer based instrument plugins. Founded in 2003, the company is best known for 3 products: Additive, an additive synthesizer, Doppelmangler, a spectral resynthesizer and Zero Vector, a virtual analog synthesizer. bleep!BOX is the company’s first iPhone app. Dave Wallin is the founder and sole proprietor of White Noise Audio Software. www.whitenoiseaudio.com

# # #

Next Project..

2009-08-06T08:35:00.000-07:00

Now that bleep!BOX has been submitted to the app store, I've been relaxing a bit and thinking about my next project. Some of my old plugin users have asked when Doppelmangler or Zero Vector will see an update. Honestly, I haven't touched those plugins for years and some of the code is pretty bad or difficult to maintain (esp. in Doppelmangler's case). Those plugins were compiled for vst 2.3 and we're up to 64-bit and vst 3.0 at this point, so some updates definately are in order. With Doppelmangler, I've always wanted to do a full re-write since I've never been totally satisfied with the quality of the resynthesis and the amount of CPU it consumes. I've actually been brainstorming about how to revamp it for quite a while now.

Zero Vector also presents some challenges. I would love to port all my plugins to the Mac, now that I've gotten comfortable with XCode. However, Zero Vector contains massive amounts of SSE assembly code and I'm not sure how well that will port (maybe it will be fine.).

In general, I've developed my own audio framework for writing portable modules. This is used in Genome Studio and also in bleep!BOX. I'd like to port both those plugins into the new framework.

Finally, I do want to get back to working on Genome Studio. I've put way too much work into it to not finish it (plus I'm getting fairly close to being able to beta test it). Genome will need some more instruments built into it, and I always intended to include some variant of Zero Vector and Doppelmangler. So, maybe now is the time to update those plugins, rebuild them in my new audio framework so they are ready to include in Genome. At the same time I can produce up-to-date plugins for them.

Doppelmangler is the most interesting problem to solve, so I think I'm gonna tackle it first. ZV will be a more straightforward port (though not trivial..). The direction I want to take Doppelmangler is to focus on high quality sample manipulation rather than all the crazy spectral stuff. Warping and modulating sounds is still the focus too (just that DM2 won't use spectral resynthesis per se). It may be something that is more like specialized granular resynthesis synthesis (not wacky artsy fartsy granular ;). As always, the motto is to be able get greater control over your samples and to use them in new and creative ways. More soon - need to do some experiments. ;)

Oh, and I nearly forgot. I have a few updates planned for bleep!BOX. Those will happen first and they will mainly be centered around performance features, patch sharing, and synchronization (read: DSMI - wifi midi).

bleep!BOX video posted

2009-07-26T08:26:00.000-07:00

Posted a video overview of bleep!BOX - check it out:

Apologies for my spastic mouse movements. ;) Gonna work on finishing up the new website today and hopefully get this bad boy submitted.. Gotta do some more testing today too just to make sure everything is good to go.

bleep!Box almost finished

2009-07-21T11:03:00.000-07:00

My iPhone Application, bleep!BOX is almost finished. It's an electronic drum / synth box and I'm pretty pleased with how it's come out. More info and sounds are at http://www.bleepboxapp.com/

BTW, in case anyone is interested, I'm on twitter now. My personal twitter is here and bleep!BOX now has it's own twitter here. Follow me!

Just had an awesome idea

2009-07-21T10:43:00.000-07:00

Just had a great idea for an augumented reality application. What if you were an architect and wanted to pitch some people on a building. They could wear VR goggles and see the building in the spot you intend to build it, as it would look (rendered in 3d of course). Could be really useful for selling clients on a concept. I would think that being able to picture how the building would fit in with the surrounding buildings to be very useful. They already do renderings like this - being able to walk around it and stand in front of it would be even better ;)

Future Genome Posts

2009-02-06T10:17:00.001-08:00

All future Genome posts will now be put on http://www.genomestudio.net/ . This blog may be used for my personal interests or I may just switch everything over there.

Genome Work Log

2008-12-13T09:21:00.000-08:00

Been quietly plugging away on the Piano roll / Parameter Automation portion of Genome. Note patterns are pretty far along - you can input notes, drag, tweak length, transpose, copy, cut, paste, etc. One nice thing is full keyboard control - something sorely lacking in a lot of big name studio software. Keyboard and mouse commands are 100% the same. Bi-manual editing is much faster than mouse only. Also, no toolbars are needed for editing notes. There is no 'eraser mode', 'selection mode' or 'note mode' - having to switch modes only slows you down. A simple grid-based cursor system is very intuitive and gives you all you need without having to juggle different editing modes.

Working on the automation half of the interface next, and I'll be looking to keep it just as simple and intuitive.

Genome Work Log

2008-10-27T10:56:00.000-07:00

Began working on coding new Input interfaces (such as piano rolls, drum editors, etc). These will have a more generic data type which can be re-used between interfaces. The data type has been created now - next I will write the Module (the actual note generator), and then start working on the various interfaces.
I also plan on generalizing the input components so they can be swapped out (ie, the standard Keyboard can be swapped out with the Hex style interface). I may even allow people to build their own interfaces and musical scales using an xml based format. More info to come..

Genome Work Log

2008-10-14T14:45:00.000-07:00

Working on adding 'Objects' to my DNA programming language. Objects are very crude built in classes with member variables / functions. This will be a nice way for me to implement Tables (memory buffers), and other simple helper classes such as filters, oscillators, etc, without having to add any additional instructions to my instruction set. My goal is to keep the language stripped down to the bare necessities for maximum speed. Still working on finishing this feature.
Once that is done, I am eager to get started building some real interfaces, such as paino rolls, drum rolls (?), and automation curves. I think it will feel a lot more complete once those are in there.

Genome Work Log

2008-09-22T08:48:00.000-07:00

Fixed 'control' issue
Minor fixes
Tested DNA scripting module. Works well so far, and it's cool to be able to drop DNA modules into the graphical 'builder' environment. I have a simple FM module written in .DNA and easily created a synth out of it with very little effort. I would like to add a little more functionality to the language in the form of 'tables'. A table could be a waveform, a delay line or used for a waveshaper (anything involving a block of memory). Not too sure on the syntax of it yet, but I will definately be looking to keep my instruction set small. Looking forward to running these programs on the graphics card, a table would correlate to a 'texture'. I also need to add some more syntax checking to the language, since there really isn't any to speak of right now. It might also be nice to have a little standalone application for testing and writing DNA modules. It could include a simple text editor and enable you to test the code right away.

Genome Work Log

2008-09-20T13:38:00.000-07:00

DNA modules are now loaded automatically, you can create custom UI's for them. Added some new language features.
Broke note events.. need to fix

Hiatus

2008-09-13T06:42:00.000-07:00

I took a few weeks break from Genome to work on a Flash game for the Grand Master Flash competition. Unfortunately, I don't think I'll be able to finish the game on time since I didn't find out about the contest until 3 weeks in and I ended up having to work a decent amount of overtime at my job. The deadline for the contest is monday.

Here's the site that I've been working on at work: www.wawacoffeetopia.com. I think it came out pretty well, and I am happy with the coding work that went into it (especially considering that I only had 2 weeks to code the entire site). I definately learned some things that I will take into my next project. It uses Tweener very heavily. I am finding more and more uses for that thing and relying less and less on timeline animation. I also used SWFAddress for deep linking, and Google Analytics for tracking.

In other news, I got an iPhone. It's the type of device I've been waiting for since I got my first PDA. The fact that it brings together so many technologies really allows for some interesting potential for applications - GPS, wireless internet anywhere, camera, accelerometer, multitouch, and mp3 playing. Small games, 'dashboard' applications that allow you to monitor your online presence and apps that allow you to find information you need quickly are all big wins on this platform. I will probably be looking into developing some apps for the iphone at some point - Genome on the iphone would rock :) Hopefully Jules is hard at work on porting Juce to the iphone.

I'm going to be getting back into Genome a bit now - picking up where I left off rewriting some of the plugin system and getting my DSP coding languages working.

Genome Work Log

2008-08-11T09:14:00.000-07:00

Made a few minor changes to the DNA programming language. It now pretty closely mirrors ARB GPU assembly language (sans dot product and some other things which aren't terribly useful for audio). I'm leaving the door open to someday running plugins on the GPU. I may also do some naive tests to see how well it works and what cpu usage looks like (even though it won't be terribly optmized).
Refactored my 'Plugin' classes a bit. Elimited about a dozen classes and replaced them with one class that uses C++ 'templating'.
Restructured my plugin directories to make more sense in light of my new scripting languages.
Next step will be to automatically read .EEL and .DNA programs and create plugins for them.

General Purpose GPU roundup

2008-08-09T06:26:00.000-07:00

I spent quite a few hours yesterday researching what's currently available utilizing graphics cards to do processing. Graphics cards are essentially stream processors - meaning they are well suited to doing repeated operations on arrays of data. Audio processing is a stream process and could benefit from being run on a GPU. Since GPU's are used to tailored for graphics, essentially we would be using textures as our audio buffers. Currently there are several options available for exploiting GPU's that help make it more like regular programming and hide the complexities of dealing with textures and other strictly graphics based idioms. Here's what I've found:

Brook. Brook takes programs written in a special language and converts them into C++ code. That code generates custom GPU instructions at runtime, which are
tailored to your specific hardware.
CUDA. Specific to NVidia GPU's, but a very nice package overall. Uses a custom compiler to compile special programs which are linked into your code. You can call these functions right from your code.
Sh. A library that allows you to create GPU programs by interacting with objects just as you would in a regular C++ program (adding, multiplying, etc). It uses overloaded operators and other tricks in order to leverage C++ as a language, rather than making it's own custom language like CUDA and Brook. The advantage of SH is that it's all done in realtime - there is no need for compilation of special programs (like with Brook and CUDA). Sh also does graphics programming if you want to use it for that.
And while not really a general purpose library, there's also nvidia Cg which can compile programs in realtime.

Now for my needs, I was looking for something that doesn't require me to compile programs ahead of time. I'd like to be able to take my intermediate audio language (DNA) and either run it on the CPU or on the GPU at runtime. This leaves out Brook and CUDA. Sh might kind of be OK for this, but isn't really aimed at this sort of thing and I would probably be circumventing a lot of stuff to get it to work how I want. Plus it's probably not worth the extra overhead and dependencies if I am just stripping out a lot of the functionality. So, that really leaves me with writing my own backend.

Now the other big downside to using the GPU is that there is a lot of overhead getting data on and off the graphics card. It's best to use the GPU when you can offload all or most of your processing to the card. It's not worth it to process little chunks, one at a time. So, for an audio system what would be cool is if I can offload the entire song (all modules) to the GPU card. This would require a significant reworking of Genome's internals so I am not sure I want to go this route just yet. Plus, it remains to be seen how many people have GPU's worth taking advantage of and how many people would be interested in buying such a product. It might be better suited to a research project some day. For now, it might be better to target Multi-core CPU's as opposed to GPU's.

In the near term though, I can think of a couple audio applications that might be suited to using CUDA (or another of the above libs):

My planned Doppelmangler rewrite. Doppelmangler uses FFT's for analysis. CUDA already has an optimized FFT written for it. The Doppelmangler of my dreams is able to take audio samples and manipulate them in fantastic ways without loss of quality. If it can do that in realtime, with low CPU usage then it would be awesome.
Physical modelling. True 'physical' modelling using actual 3d models might be interesting (and might be possible to do using Vertex programs), in addition to the more traditional numerical models using waveguides and such (fragment programs). I think it would be awesome if someday I can actually 'build' an instrument in 3D (rather than just dealing with DSP processes). In theory anyway..
Reverbs and convolution effects (already been done, I know)

Looking ahead, Stream processing promises to make it's way into everyone's machines eventually. Intel is working on the Larrabee processor which will perform GPU functions in addition to General Purpose streaming functions. Multicore is great for the average user who is running several programs at once, but difficult to program efficiently for. Stream processing can be orders of magnitude faster for the kinds of tasks I'm interested in. Future processors will probably include multiple cores and multiple stream processors - essentially everyone will have a supercomputer on their desk.

Audio Scripting Experiments

2008-08-07T14:41:00.000-07:00

I got the first run of my DSP scripting language (which I am calling DNA) up and running. Initial results were pretty encouraging. The same script that took 15% cpu in EEL only took a couple percent in DNA script. The code is very similar to assembly language, so it would be possible to make a higher level version of the language that compiles down to DNA assembly. Assembly code is very efficient and also is easy to parse/compile - it only took me two days to get the parser and the core VM up and running. It should also be possible to take the same code and run it on on a GPU which would be very cool. I'll be working on optimizing the DNA VM and investigating GPU stuff this weekend.

Elgg 1.0 Due August 18th

2008-08-06T10:55:00.000-07:00

Elgg one of the Social Networking platforms I've been watching is due to be released august 18th. Elgg is one of the few free / open source options out there for doing a social networking site and it promises to offer a much improved interface and a very nice API for developing plugins and widgets for new types of user generated content. The 18th will be the first day that the new code is available to download, and I expect that lots of user made plugins and mods will follow. There's still a lot of features lacking, but I think the base has been laid down with this new version is pretty strong and it promises to be a good platform to build on. Plus it's free. :) I'll post my impressions of the API once the 18th rolls around.

EEL Scripting for audio

2008-08-04T10:48:00.000-07:00

I did my first test getting an EEL DSP script up and running under Genome. Only a few minor syntax changes were necessary to get the script to compile under Visual Studio (though it did take the better part of a day to get it working). Overall I am happy with the features of the language and the fact that it has so few dependencies (and is generally written in ansii C, which hopefully means it's fairly fast). Initial speed tests were a bit disappointing. A simple FM synth (one operator, one modulator) ended up taking about 15-20% of my cpu time. Ideally I'd like a simple EEL module to take a percent or two. A C++ version of the same synth would take 0.1% or less of the cpu. So, I am currently looking into optimizing eel to tailor it to my needs a bit more. The eel core is fairly easy to understand (despite it's overly aggressive use of macros). These days I have been using AMD Code Analyst, which is a nice, free version of VTune, for my optimization needs. The latest version runs right inside visual studio and doesn't require any special instrumentation. You just run the app and it starts collecting results. For those unfamiliar with these kinds of applications, basically they can tell you which functions are consuming cpu resources and then allow you to go line by line and see which lines are taking up the most time. This is essential for helping decide how to go about optimizing a large and complicated program. Obviously it doesn't make sense to optimize everything. Your code will become a mess. You want to target your optimizations to the inner loops - the things that are done the most often.

Most of the EEL execution time is spent looping through instructions, computing arithmetic operations and copying variables. I spotted some areas that could see huge gains in the arithmetic function. Basically there is a gigantic case statement which checks every possible combination of operation and variable type. Instead of one monolithic case statement I could see this being broken down into several nested comparisons and have at most 5 or 6 comparisons per operation, instead of the dozens that an average operation would take now. I also plan on moving up common operations and moving down uncommon ones. I am debating whether the instruction set can be simplified. The smaller the instruction set, the less time I'll be spending figuring out which instruction to execute. For my audio/dsp needs I am going to be operating on floating point numbers most of the time. Some variable types or operations might be removable. So, it should be interesting work to try to speed this up. Already I am learning a lot about VM's and the internals of scripting languages just by going through the code.

UPDATE:
In my searches I found that some compilers will convert a case statement into a what is known as a 'jump table' or 'branch table', which is basically an table of jump locations keyed by the variable you are evaluating in your switch statement. This is much faster than evaluating a huge case statement. Not sure if my compiler is doing that - if it is, then my optimization hopes are dimmed.

Right now I am toying around with making my own ASM-style scripting language with a very reduced opcode and ability set which. The language would be very specifically focused on processing streams of floating point audio data. I am hoping that these two things will make it a lot faster than EEL, which is fairly high level and provides a lot of functionality that isn't important for processing a stream of audio. It might be possible to combine EEL and this ASM language to cover both the high-level and low level bases. The language follows what I posted previously. I coded the 'compiler' last night and I'll work on the VM tonight. I'll post when I get some results.

Genome Work Log

2008-07-27T14:17:00.000-07:00

Investigated Realtime-suitable scripting languages (for use in audio plugins). So far, not too many options exist. There is LLVM / FAUST (both of which generate and compile C++ code). There is also EEL which seems a little promising, and I will be digging into it more. I am tempted to try to write a compiler and VM solution myself. What I think is needed is something very similar to Shaders (used in the graphics domain). It's a simple program that defines inputs and ouputs (and any variables or parameters needed) then processes the inputs and generates outputs. I shouldn't need any of the additional overhead of garbage collection. Variables should be strongly typed for speed. Function calling will be minimal. Also it will need to compile to byte code (not be interpreted). Mirroring shaders could also make it easier to offload plugin processing to a graphics card (or use CUDA?) which is also of interest to me. Anyway, it's an interesting topic and I'll be investigating it more.
Fixed numerous bugs with control surface and builder module..
Fixed broken Reverb module

Reactogon - ooh

2008-07-26T08:44:00.000-07:00

Saw this on youtube today. This is a really cool example of the kinds of alternative interfaces I would love to experiment with in the future for Genome. Also, it uses Reactivision.

Genome Work Log

2008-07-25T11:58:00.000-07:00

Fixed a couple bugs with the builder module(s)
Fixed some Module menu items

Genome Work Log

2008-07-23T10:33:00.000-07:00

Identified several bugs with the Builder module
Fixed Knob control
fixed SVF module config file
Other misc fixes
Will need to spend some time fixing the Builder before working on a new Piano roll style module (which will also make way for an automation module). I'm making it my practice to fix all bugs as soon as I find them, rather than waiting for later (even if they don't affect what I'm working on).
Would like to come up with a system where people can write module plugins in a shader/scripting type fashion and still have them run fairly efficiently - advantages being that the plugin can be included in the song, shared, sold, etc, and that it is cross-platform. Some options already exist. Will need to do more research on the topic.

Genome Work Log

2008-07-20T06:52:00.000-07:00

More event refactoring
Container control inputs now possible
Bug fixes
friendlier names for container inputs / outputs..

Genome Work Log

2008-07-18T15:02:00.000-07:00

Bug fixes. Fixed some things that have been broken for a while
Internal improvments to the song module
Events changes now complete
designed pianoroll and automation editor modules

Genome Work Log

2008-07-15T06:59:00.000-07:00

Added 'audio settings' dialog box and saved current settings to xml file
Finished fixing up some stuff with Control Events.. wasted a lot of time tracking down a bug (multithreaded programming can be a pain..)
Next I will be making some more changes for Automation and OSC control.

Genome Work Log

2008-07-10T10:42:00.000-07:00

Working on modifying some low level stuff with Genome's Control Events. When the dust settles, Genome will have hooks for automation.
Part of this change will also allow for 'meta patterns'.. Ie, a pattern that may be composed of several different sub patterns patterns.
As per the comments in my last post, Ben from Curverider was kind enough to inform me that Elgg is in fact close to it's 1.0 release (though no specifics yet on when that will be, and they haven't set me up as a beta tester.. *cries* :) I am very closely watching developments with both Elgg (which is hitting 1.0) and Social Engine (which is hitting 3.0). Based on Screenshots of Elgg 1.0, they have definately made some great UI improvements. Also, the underlying code changes promise to make writing plugins even easier and allow for easier sharing and displaying of user generated artifacts. The new social engine is also looking extremely sexy over at it's public beta site even though no plugins have made available yet (elgg people: put up a public beta!).