Showing posts with label GDAM. Show all posts
Showing posts with label GDAM. Show all posts

Thursday, March 1, 2007

GDAM: time access

Once the beat (tempo and phase) of a song has been mapped via the Beat Calculator, time access can be very sophisticated. A number of these techniques seem to still be unique to GDAM, I am giving the descriptions here in hopes that all software might offer these powerful features.

Basic precision: position math is done inside the audio thread with sample accuracy. Although file playback may not start immediately(eg hard drive takes time to spin up), the server can keep track of how far behind it falls, and dump a little data to catch up... this makes the song start in synch regardless of file access/encoder delay.

Seeking smoothly: When seeking a song, it starts a new copy at the desired position. While that starts up, the current copy keeps playing. Once the new copy has started, data is dumped to make up for the small startup delay, a quick crossfade occurs, and the old copy is discarded. This keeps position seeks smooth while honoring the *exact* timing of the request.

Relative seeking: relative seeking is requested by the client, often seeking by an amount of time which is precisely calculated from the BPM to be an even number of beats. The jump is executed using the smooth seek functionality to keep sample accuracy. The medium-scale seek buttons seek anywhere from 1 to 32 beats forwards or backwards. Because the audio engine accounts for startup delay, the beat is *perfectly* maintained when relative seeking in this way. This gives incredible control over playback of the song... press "back 4 beats" every four beats, and you are looping a perfect bar. Because you are seeking by an amount, rather than to a position, you can time the jump however you want (at any point in the bar not just at an even bar boundary) while keeping the beat.

Jumping to any point in song while keeping beat: the client has an approximate idea of where song playback is... not sample accurate, but within 1/10th of a beat. The user can click on any point in a song, and jump there without dropping the beat. The client calculates the difference between where playback is and where you want it to be, rounds that difference to an even number of beats or bars, then issues a relative seek in that amount. This opens up music to be completely time-accessible, rearranged at will in real time, without dropping the beat.

Index points: When beatmatching, you can go beyond simple tempo and phase information, and add index points at certain places within the songs such as verse, chorus, breakdown, outro. These are clearly marked in the timeline, and you can jump to them in beat. When i'm playing a hip-hop song, I'll cut every chorus to half size and skip over the guest verse. I can edit a song down to just the meaty core, or do long remixes by extending each instrumental moment into 8 bars of beat juggling and effects.

Sub-beat time access: this is usually used to nudge a song into synch with another audio source. There is a ruler representing one beat, click anywhere along it to seek an amount between 1/2 beat back to 1/2 beat foward. The closer to the ruler's center mark, the smaller the seek. When I hear my song playing out of synch, I know from the rhythmic relationship (1/4 or 1/16 beat ahead or behind) where on the ruler to click. This allows me to instantly correct, rather than nudging it incrementally or guessing how far to seek.

Wednesday, February 28, 2007

GDAM: scratching

Scratching in GDAM is based on the Bender plugin - an inline filter which keeps a large buffer of audio and allows playback at any speed, backward or forward, from any point in the buffer. If you are familiar with the Buffer Override VST filter, I am told it uses this technique.

Bender plugin can manage the input to the buffer in various ways; it can keep the input at full speed, advance only when needed, or even drop bars of music to keep playing in beat, without making progress through the song.

Scratching in GDAM allows the user to set certain cuepoints in the audio stream, and jump to them, while playing backward or forward at any pitch. The ability to teleport between point in the audio stream breaks a major limitation of vinyl scratching: to get from one part of a sample to another, the vinyl DJ has to move the needle along the groove. To get there fast, the record spins fast and the sample plays at a higher pitch. The scratch DJ may selectively mute parts of the scratch to obscure some of the "incidental" pitch, but there is noneless a very rigid relationship between where in the sample you can be, how fast you are moving through the sample and what the pitch is at any moment.

GDAM's ability to jump to marks within the sample allows different parts of a sample to be played back-to-back in a way that is impossible in vinyls. On top of Bender, it is even possible to switch seamlessly into timestretching and pitch shifting, breaking the speed/pitch relationship. In theory a bit like going from pushing a car on a flat track to flying uninhibited through 3d space.

Another technique is to take timestretching to the extreme that position does not progress forward or backward on its own. It plays a microloop of the current position, and you can drag the playhead back and forth while changing the pitch independently. You can do a record stall in place by fading pitch down to 0, scratch back and forth at any consistent pitch, and all kinds of other tricks impossible with vinyl.

For MIDI control for scratching I like to use the pitchbend wheel - pulling it towards me to rewing and pushing it away from me to play > 100% speed. A nice thing about the pitch bend wheel is that it returns to its detente position when you remove your hand, in the same way that a record returns to full turntable speed when you remove your hand from it.

So of course pitchbend 0 always mapped to 100% speed. But I have a number of different mappings for the rest of pitchbend range. The two most common are 1) pulling back from detent slows from 100% to stalled then increases to -200% or -400% at pitchwheel full back 2) pulling back from detente instantly trigger 0% and from there increases to -400%. 1) gives a snappier scratch, 2) is useful if you want to stall a record but GDAM also offers plugins which do this perfectly so it didn't get as much use.

Although I've often dropped a bit of scratching into sets and demos, I never really spent time developing routines and pushing the limits of what is possible.

Beatmatching in GDAM


At the end of the last century, as we developed GDAM, we got a lot of questions about automatic beatmatching. Non-DJ's wanted a solution to let them string songs together without error. And there was a growing body of academic work on automated pitch and rhythm tracking.

However, by that time I was listening to music complex enough that auto detection is, even today, far from sufficient to track it. Also, I wanted to have complete control over the music, and was willing to spend a bit of prep time on the music I was going to play. So I decided that regardless of any automated beatmatching, my software needed an ironclad solution for defining the rhythm of music which was too complex to rely on automatic beat detection.



The solution I came up with was the Beat Calculator a tool which assisted the user in
manually mapping out the beat for each song once, and a Song Database which stores and retrieves the beatmatching data for each file. Once you know tempo and phase of music, you have the ability to make perfect loops, synchronize effects, and even jump around in the song without dropping the beat. In fact, I'm shocked that I've still not seen another piece of DJ software which allows the user complete freedom to reorganize the song in real-time without ever dropping the beat. I get a lot of dropped jaws when I show this feature, but it is the simplest little bit of math and logic, which we've employed for over a decade.

We did at one point also support a bit of automated beat-tracking software, if i recall correctly it was called pitchtrack and was part of some grad student's paper. However by this point I had a huge library of perfectly-beatmapped files, and it was clear that automated beatmatching may be a good bullet point for selling an app to non-DJ's, but my simple assisted manual solution offered far better results.

GDAM

GDAM is audio software I've been developing for almost a decade, and provides the foundation for a lot of my experiments in audio and control.

Dave Benson, a brilliant fellow who had ten times my programming experience, started the project with me around 1997. It began as an engine for crossfading playlists controlled by clients across the network, but very soon grew to encompass live mixing. The early GUI was written in JAVA, this was rewritten in GTK in 1998.

When we started, there weren't many options for digital DJ mixing software... if I recall, VTT by carrot interactive, virtual 1200s, maybe an early version of PCDJ. Early DJ software was either winamp with crossfades, or an attempt to clone vinyl turntables or CD decks. The field was young, there wasn't existing software to learn from, these were the first attempts. There was TerminatorX on linux, focused on scratching, but nothing which really treated the problem in terms of manipulating audio files with rhythmic content.

Although I had a turntable and sample, beat, and hip-hop records, I didn't have a large body of experience tied to the turntable interface. I wanted a tool geared towards arranging and presenting a mix of digital music files.

By 1999 we had a tool with a database of beatmaps for song files, sample-accurate beatmatching, and different techniques for arranging song files in real time. A number of GDAM's groundbreaking features have made their way into modern apps, but many still seem to be unique to GDAM.

At first we talked about "going beta" and the version number crept to 0.9, 0.912, 0.945... I think we were both interested in working on it for our own reasons, and didn't focus the effort on a single bugfree release with all the niceties of a finished product. GDAM is available in projects such as planetCCRMA and on bootable discs such as dynebolic. I've kept extending GDAM to accomodate my experiments and music projects. Although I haven't made a tarball release in years, I still commit new features to CVS and it keeps getting more powerful. There was an OSX version for a while, but as OSX grew from 10.0 to 10.1 and later versions, every minor update was breaking the install and I didn't feel it was worth the effort to keep up. Lately, GTK-based apps such as ARDOUR have been ported to native OSX versions, so an OSX install may be easy in the near future. I do still have instructions for compiling on OSX for the brave ones willing to type in terminal, these worked at least as recently as OSX 10.4.

Other posts detailing aspects of GDAM:
Beatmatching
Time Access