I think it would be nice to have some figured bass functions. I started with these simplistic functions and I am wondering if anyone has thoughts on how to generalize them. I think it'll probably be best if eventually one would be able to simply input a list of bass notes and figures - something like (figured-bass '(c3 (5 3) d3 (4 3) e3 (6) '(c major)) and the function would return the figured bass realized. 

(defun five-three (degree root type) 
  (tonality-map `(,type :root ,root :map shift) 
              (chordize (pitch-transpose (- degree 1) (interval-to-pitch '(2 2))))))

(five-three 2 'd 'major) 
=> (e4g4b4)

(defun six-three (degree root type) 
  (tonality-map `(,type :root ,root :map shift) 
              (chordize (pitch-transpose (- degree 1) (interval-to-pitch '(2 3))))))

(six-three 3 'c 'minor)
=> (eb4g4c5)

(defun six-four (degree root type) 
  (tonality-map `(,type :root ,root :map shift) 
              (chordize (pitch-transpose (- degree 1) (interval-to-pitch '(3 2))))))

(six-four 5 'e 'minor)
=> (b4e5g5)

 

 

Hi,

 

you can have a look to GEN-CHORD3 function who is based on roots and intervals spec.

 

SB.

Thanks, Stephane!

 

for some reason, the gen-chord3 examples provided with opusmodus don't seem to work. 

 

However, I think perhaps harmonic-progression could do the trick.

For example, the following creates a series of 6/5 chords  (harmonic-progression '(0 3 4 4) '(c major) :size '4 :step '((2 1 2)))

and here are some 4/3 chords - (harmonic-progression '(0 3 4 4) '(c major) :size '4 :step '((2 2 1)))

 

perhaps this is enough - although I do think it gets a bit cumbersome. If you have ideas on how to create a function that would streamline this process, I'd appreciate hearing them. I think something more similar to traditional figured bass notation format would be easier to work with (at least for me....)

 

Thanks!

Avner 

So here's what I have so far.  Any suggestions would be welcome

 

;;;; a function that splits a list ;;;;

(defun split-list (lst)
  (if lst
      (if (cddr lst)
          (let ((l (split-list (cddr lst))))
            (list
             (cons (car lst) (car l))
             (cons (cadr lst) (cadr l))))
        `((,(car lst)) ,(cdr lst)))
    '(nil nil)))

 

;;; figured-bass function ;;;;

 

(defun figured-bass-progression (progression)
  (harmonic-progression 
   (car (split-list progression)) '(c major) :size (loop for i in (car (cdr (split-list progression))) collect (+ (length i) 1))
   :step (car (cdr (split-list progression)))))

 

 

;;;; test

(figured-bass-progression '(0 (2 2) 1 (2 2 1) 2 (2 3) 3 (2 1 2) 4 (2 2 2) 5 (2 3) 6 (2 3) 7 (2 2)))==>

(c4e4g4 d4f4g4b4 e4g4c5 f4a4c5d5 g4b4d5f5 a4c5f5 b4d5g5 c5e5g5)

 

 

My questions are: 

 

1. Why would (2 2 1) create a 4/3 chord? Why would (2 1 2) create a 6/5 chord? Shouldn't this be the other way around? 

 

2. Would it be possible to convert this to traditional terminology? So one could write '(f4 (6 5)) and get the chord '(f4a4c5d5)? Obviously, this is not crucial, but I am curious to learn how to program better in lisp.

 

Thanks!

Avner

 

 

 

 

 

(gen-chord3 '(c4 eb4 g4) '((6 5) (5 3) (4 2)))

Thanks Stephane,

 

I must say that I don't quite understand gen-chord3 - every time I evaluate the expression (gen-chord3 '(c4 eb4 g4) '((6 5) (5 3) (4 2))) I get a different result. 

 

Also, what I was hoping to do was to convert traditional figured bass (i.e., use steps in the key) into chords. Perhaps there isn't an easy way to accomplish this in opusmodus right now. 

 

Either way, would you mind explaining why gen-chord3 evaluates to different pitches every time? 

 

Thanks!

Avner 

(gen-chord3 '(c4 eb4 g4) '((6 5) (5 3) (4 2)) :seed 42)

 

Without the :seed argument the result  should be random.

 

/Lasse

you can use :cycle t keyword and in this case, the choice will cycle in place to random choice.

(gen-chord3 '(c4 eb4 g4) '((6 5) (5 3) (4 2)) :cycle t)

S.

Thanks so much! :-)

 

Perhaps it's too 'old school' for opusmodus - but I think it would be great to have something like this at some point (especially for teaching purposes) - http://web.mit.edu/music21/doc/moduleReference/moduleFiguredBassExamples.html

 

Thanks again for the help with this. 

The example of music21 is great, indeed, but it is a lot of works to create such rules system.

 

S.

Thx for the link to music21.

I thought I had found most algo music thingies but this one i have missed completely.

/Lasse

You're very welcome :-)

music21 has so much to offer - I just wish there was an easy way to convert its tools and objects into opusmodus functions.  I really enjoy the workflow of opusmodus and using lisp. Perhaps when opusmodus can read xml files directly into omn it would be easy to combine the two. 

 

All the best,

Avner 

critical thought about this:
I think in the near future this will work through "deep learning". So it is questionable how useful it is to formalize such manual and traditional "activities", such "complex rules systems" in CODE. this question generally arises in areas that focus on imitating and executing existing styles.

greetings

andré

 

André,

 

i think you are absolutely true about deep learning for replacing the old way of hard coded rules for this type of works.

It is indeed, the actual tendency.

S.

...except that makes you a fun and makes you happy - and that is just as important!

added 10 minutes later

so the question will be what can be better, which will be more exciting than what deep learning (or traditional algorithms) can produce. very fast then - in my opinion - the production becomes quite simple and well done, but this has nothing to do with art (if you want) - it will be the "imitation of art", also algorithmic tools pushing you in this direction - is it "music" or the simulation of "music"?. but as VON FOERSTER said: "the map is the territory"... counteracting (radical-constructivistic) the phrase "the map is not the territory"...