What is it ?
Or what was it, rather. One Bar Loop (OBL) was an in-browser, Flash based application in which users could create a piece of music... of exactly one bar/measure in length. To generate sound, OBL did not use samples but would synthesize audio on-the-fly.
Users could shape their synthesizer sounds, apply an effects chain and share their stored creations online, having the ability to vote on the loops made by others.
While OBL had its own website at www.onebarloop.com, there was also a shadow version hosted on Newgrounds (communicating with www.onebarloop.com keeping the content of the two in sync). All content generated in OBL was deeplinkable and indexedable by search engines.
Wait... just one measure ?
Yep. Users has access to three instrument channels, multiple oscillator waveforms, eight octave polyphonic range, adjustable tempo, multiple stereo effects modules... but could only write one measure of music per song.
Most computer centered musicians compose their ideas while repeating a single pattern, repeatedly adding new layers while polishing up the initial spark of inspiration. Entire tracks are built around the ideas that were spawned from this single basic groove.
One Bar Loop existed to discover what kind of music could be created with such a severe limitation. Is there magic to be had in a single repetitive idea, often a handful of seconds in duration ?
Adobe Flash ? Why not HTML5 ?
With the advent of Flash Player 10, Flash gained the SampleDataEvent class which basically provided you with the means to write data into an audio buffer that would be enqueued for live playback.
OK. So SampleDataEvent made it work ?
Yes... but it needed considerable help. Whereas the Web Audio API offers satisfactory-to-great performance on the average device, the latency of audio in Flash was high. Also the single threaded nature of Flash required doing all the math to generate the sound on the same thread that would also be rendering the UI, handling events, etc.
To overcome this, a toolkit known as Alchemy (later CrossBridge) was used. Alchemy basically allowed porting C/C++ code to run inside the Flash Player, offering a performance boost of up to 10 x that of ActionScript.
The DSP code to generate and manipulate audio was executed in ActionScript 3, whereas buffer manipulation and memory allocation was handled through Alchemy.
And then it worked ?
Yes... but it needed even more help. Instead of recalculating what would be deterministic code, rendered audio could be written to and read from a cache. This greatly alleviated the stress on the CPU and even made the application run satisfactory on tablets supporting Flash Player (this was a different era after all).
In retrospect, the caching might have made matters worse in the sense that tweaking an audio signal on the fly would require invalidating the cache, re-rendering the audio and writing it into a new cache. All of which is fine, but not as cleanly executed as it should have been. This lead to changes in signal flow to pop a "caching audio" progress bar (though existing audio kept playing).
Further more, a lot of the DSP implementations were quite naive and DC offset problems were ubiquitous. As it stands, OBL was the first real application in which I used audio synthesis, and buggy as it was, it was the jumping board which eventually led to other apps, most of them listed on this website.
As a community in which people (mostly onboarded through Newgrounds) would continually write loops, share their work and critique others, it was great fun.
Languages and technologies used:
DSP / synthesis-related
The core framework and audio code is archived but available to this day on GitHub.