[LAD] Open-source Band-in-a-Box replacement

Michael Niemeck michael at niemeck.org
Thu Jun 27 06:41:22 UTC 2013


Quoting conrad berhörster <beat.siegel.vier at gmx.de>:

> maybe this helps
> http://welltemperedstudio.wordpress.com/code/lemma/

lemma looks cool. I will definitely give it a try as soon as I get my  
daw back from the repair shop...

> and take a look at
> impro-visor
> http://www.cs.hmc.edu/~keller/jazz/improvisor/

I also worked with impro-visor a lot. Basically it has too many  
features for my requirements. I just want an easy-to-use tool to  
provide a playback track for practice sessions for those of us that  
lack the skill or the extra hands to accompany themselves on the piano  
during practice. I remember the playback quality to be very good,  
though. I never got to use all the melody-centered functionalities,  
it's a different use-case really. That's also one of my design goals -  
focus on the central requirement, keep everything out that's not  
absolutely necessary, make it as easy to use as possible, and in the  
end really focus on the quality of the output (i.e. the music that can  
be heard).

> And maybe you can explain a little bit about your ideas about the
> pattern-less approach

Happy to, though it might get a bit longish from here on. Bear with  
me. My reasoning  goes like this: Take the bass part of a very  
simplistic straight 4-beat groove. In a fictional  
pseudo-pattern-defining-format you may specify something like this:
  -) Play the bass note of the chord on beat 1.
  -) Play the bass note of the chord on the off-beat after 2.
  -) Play the bass note of the chord on beat 3.
  -) Play the bass note of the chord on the off-beat after 4.
This will sound fine on straight-forward one-chord-per-bar tunes. Even  
if you change chord every two beats it will sound reasonably good. But  
what of bars with a chord change on every beat, such as happens often  
in Jazz, especially in turnarounds and the like? The bass player will  
miss every other chord! Sure, you could add a rule like
  -) In addition, play the bass note of the chord at every chord change.
assuming your pseudo-pattern-defining-format allows this. But then the  
notes on the off-beats defined earlier will not sound too good. A real  
life bass player would in such turnaround bars probably play a single  
note on every chord change and leave out the off-beat notes. Or  
consider off-beat chord changes, also a common thing. Just think about  
what a typical pattern definition will make of them, and what a real  
player would play.
Still, it's possible to express all this in a pattern definition. But  
always provided the engine reading the pattern files supports it! And  
I think that sooner rather than later you reach the point where  
understanding the syntax of a sufficiently powerful pattern format and  
actually writing good patterns in it is not that much easier than  
programming in any well-structured contemporary programming language.
Bottom line: I think everyone able to define patterns so complex that  
they actually sound really good is just as able to program them given  
a well-structured framework to work in.
What you gain by actually programming a groove is that you are no  
longer limited by the abilities of the pattern interpreter, but have  
the full expressive power of the programming language at your  
disposal. Random elements, variations in timing and volume to make it  
sound more human, even the occasional wrong note, all that is possible  
without any changes to the engine itself.
BTW, the same holds for the voicing of chords. Consider the ugly but  
simple progression D7 C9 Bb6. By defining for the bass to
  -) Play the root note of the chord in octave #3
will give you a not only ugly but also quite unrealistic jump of a  
seventh up at the last change. It gets worse if the voicing of the  
pianists right hand just builds the chords up from the root. Playing  
the above progression with all the chords in root position will not  
only violate a lot of voicing rules, it will also sound pretty crappy.  
A real-life pianist would probably play all three chords with the D at  
the bottom, or maybe even move up through D E F or something similar.  
Actually programming such rules is doable, defining them in a  
declarative fashion is much much harder.
So how does this actually work? At the lowest (and most convenient)  
level you just define your Groove as a number of Players, each  
representing typically one instrument. In your Player you have two  
hook methods, one that gets called once for every bar and one that  
gets called once for every chord change. Within these methods you  
define (actually you program) what notes should be added to the final  
music. For that you have not only methods to actually add notes to the  
track, but also a (hopefully still growing) number of convenience  
methods, for example to get the proper notes for the current chord  
from a voicing engine or to get not only the current chord but also  
the previous and next chord(s) (for example to program cool walking  
bass lines you need the full context) as well as their suggested  
voicings, etc. In addition you can do basically everything that can be  
programmed.
In the most simple case, programming in that layer is not harder than  
defining patterns. The simple pattern from above would look something  
like this:
  void createEvents(Bar bar) {
    addNote(getVoicing(getChordAt(0.0)).get(0), 0.0, 1.0, 0.35);
    addNote(getVoicing(getChordAt(0.375)).get(0), 0.375, 1.0, 0.12);
    addNote(getVoicing(getChordAt(0.5)).get(0), 0.5, 1.0, 0.35);
    addNote(getVoicing(getChordAt(0.875)).get(0), 0.875, 1.0, 0.12);
  }
The difference is that you are not limited anymore. You can even skip  
the convenience layer and directly implement your own Player object,  
in which you receive a list of music information (Bars, Chord changes,  
Volume changes, Tempo changes), an assigned MIDI channel number and  
the set MIDI resolution, and must return simply an arbitrary list of  
MIDI events.

To everyone who made it this far: Thanks for listening ;-)

Mike

-- 
Michael Niemeck
Krausegasse 4-6/3/6
1110 Wien
michael at niemeck.org
+43 1 9417017
+43 660 9417017


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


More information about the Linux-audio-dev mailing list