Jump to content

torstenanders

Members
  • Posts

    489
  • Joined

  • Last visited

Everything posted by torstenanders

  1. Dear Janusz, Thanks for taking the time to explain the :add argument in such detail. > The :add value is an interval number (not a pitch) of the tonality in question. I see -- this could be a bit more clear in the documentation. The result of the function EXPAND-CHORD makes now perfectly sense (except for the enharmonic change, but we already discussed that), however I still do not get the result of TONALITY-MAP -- the effect of adding pitches by expand-chord and tonality-map seems to differ! Here are all the chords with a single interval added as expanded by EXPAND-CHORD (apologies for such long code example, you likely have a more concise way to do this, which I do not know yet). (setf tonality1 (tonality-series chords :add '(2) :closest '(up))) (pprint (mapcar #'(lambda (c) (list c (expand-chord (flatten (list (first c) :add (getf (rest c) :add) :row t))))) tonality1)) => ((((c4 maj) :add 2 :shift up :mod piano) (c4 d4 e4 g4)) (((f4 m) :add 2 :shift up :mod piano) (f4 g4 gs4 c5)) (((f4 m) :add 2 :shift up :mod piano) (f4 g4 gs4 c5)) (((g4 maj) :add 2 :shift up :mod piano) (g4 a4 b4 d5)) (((c4 maj) :add 2 :shift up :mod piano) (c4 d4 e4 g4))) Now, here is the result by TONALITY-MAP instead. (tonality-map tonality1 rows) => ((q c4 d4 d4 d4 e4 e4 g4 g4 g4 g4 c5 c5) (q f4 f4 gs4 gs4 gs4 b4 b4 b4 eb5 eb5 eb5 f5) (q f4 f4 gs4 gs4 gs4 b4 b4 b4 eb5 eb5 eb5 f5) (q g4 g4 g4 c5 c5 c5 c5 c5 e5 e5 e5 g5) (q c4 c4 d4 e4 e4 e4 g4 g4 g4 g4 c5 c5)) Note that instead of adding a single interval, the pitches of the chord are shifted. The C-major chord is fine, but not the others. For example, instead of f4 g4 gs4 c5 we get f4 gs4 b4 eb5. Is this intended, and if so, what is meant here? When setting the roots explicitly to the roots of the chords the result seems to be the same, so I left those out. Best,Torsten --http://www.torsten-anders.de
  2. Thanks! Unfortunately, TONALITY-MAP does not work with a chord progression, as in the example above. We established that already earlier in this thread (a series of tonalities is not a tonality). So, how to use :add likewise with TONALITY-SERIES to do the same with a harmonic progression? As I said, perhaps there is simply a bug in TONALITY-SERIES for that argument? Best, Torsten
  3. Dear Stephane, Thanks, respell does some enharmonic respelling, but only to avoid certain clashes in dense chords, AFAIK. However, it does not fix "wrong" enharmonic notation. Consider the following example, expressing a C-minor triad. Obviously, it should be notated with an eb, not ds, otherwise it is at least confusing for musicians, if not causing a wrong intonation. (respell '(c4 ds4 g4)) Any way to correct this triad, or to avoid wrong re-spellings of an originally correct spelling in general? Best, Torsten -- http://www.torsten-anders.de
  4. Dear Janusz, > This is how the microtone will be coded in OMN. So, this is planned for future releases. Thanks! If you are interested, I am happy to be part of design discussions, as I implemented similar features (automatic microtonal playback and notation) myself before. > We can use microtones in Opusmodus but they are not a part of notation. Yes, I understand that there is already some support of adding explicit tuning. However, from what I read so far, this is not integrated into the OMN language, and therefore the algorithmic potential of Opusmodus cannot be used. Best, Torsten -- http://www.torsten-anders.de
  5. More generally, is there a standard OMN way to express multiple staff lines beyond the abstract data type of a score? Thanks! Best, Torsten -- http://www.torsten-anders.de
  6. The subject says it all... Best, Torsten LENGTH-DIVIDE2 Documentation seemingly not updated (neither reference nor examples) after function has been changed for the argument :position. For example, the following example call throws an error (length-divide2 '(1 2 2) '(1/16) '(1/4 1/4 1/4 1/4) :type 'n :position 'e) > Error: There is no POSITION named: e. > Allowed POSITION: 'f (first) 'l (last) 'c (center) and '? (at random). BTW: Unfortunately, that helpful error message is not shown if I try to directly output the above expression (e.g., with cmd-2). Instead it then says > Error: OMN Parse Error: (annotate (parse-omn-audition-phrase) (fail nil nil)) Ideally, when creating output the original exception with the much more clear error message would be thrown. Anyway, thanks for such clear error messages! BINARY-LENGTH-MAP reference doc uses seemingly undefined function PITCH-VECTOR-MAP LENGTH-ADJUST reference shown output of first example call to LENGTH-ADJUST incorrect (seemingly the value of my-phrase was changed later). There are several similar errors in the documentation -- do you want such cases reported? GEN-LENGTH-CARTESIAN again, shown output of some calls to GEN-LENGTH-CARTESIAN incorrect (possibly the see changed later?) Some functions used in code are reported as undefined by system (downloaded version 1.0.15665) function INTEGER-TO-PITCH used in harmonic-path.rtfd BTW: Calls to the function klangreihen in harmonic-path.rtfd also result in errors. LENGTH-MODIFY If the count argument is not given to LENGTH-MODIFY, then seemingly count is randomised. That should be documented, otherwise it is confusing. In the following example I would otherwise expect always the same result (a 1/16 added to all notes, but not the rests), but notes are randomly modified or not. (length-modify 1/16 '(1/8 1/8 1/8 1/8 -1/8 1/8 1/8 -1/8) :operator 'add :type 'n) Also, the value 'all for :type is not documented (but thanks for your error messages pointing that out!!) VELOCITY-INVERT VELOCITY-INVERT ignores dynamics marks like cresc. It would be useful if (and users may expect that) those are also inverted. If not, then at least the documentation should mention this for completeness. VELOCITY-RETROGRADE VELOCITY-RETROGRADE reverses the order of dynamics, including marks like cresc., but it might make more sense for users if such dynamics are "turned around" in the result, e.g., (f> p) -> (p< f) Of course, this is a bit more tricky :-) Again, if not then the the documentation should perhaps at least mention this for completeness.
  7. Dear developers, Below I report another bug (or at least what I assume is a bug). Thank you! Best, Torsten LENGTH-ADJUST If arg value is below the overall length (duration) of the given phrase, then the result is nevertheless longer than the input, seemingly by the absolute difference. This corner case is not covered by the documentation, but for consistency it would likely be better to shorten the input sequence, if the given length value is shorter than the sequence. Examples: (length-adjust 3/4 '(q c3 e d3 e3 q f3 e g3 a3)) (length-adjust 2/4 '(q c3 e d3 e3 q f3 e g3 a3)) BTW: No quote necessary before ratios or numbers in general, those evaluate to themselves. 3/4 -> 3/4
  8. Dear developers, Following up with my previous post: more generally, can users extend the OMN language, or is this planned in future? After all, it is impossible for a software designer to add every idiosyncratic music notation option some composer may be using (or which has been used in the past), but ideally (power-) users would be able to extend the language according to their needs. You are probably knowing better than me all those special notations that you are not yet supporting, and likely understand the need easily. Particular important would be additional expressions. Users would likely need to define some mapping to the equivalent MusicXML markup. I understand that adding such feature could be very tricky, just asking :-) At least adding free user-expression text might not be hard. Best, Torsten -- http://www.torsten-anders.de
  9. Dear developers, Are you considering to support microtonal music at some stage? In particular, this would mean allowing for additional (or, even better, custom) accidentals in addition to the current b and s in the OMN language. Quartertones are already supported even by MusicXML and out-of-the-box by standard music notation software like Finale and Sibelius, so adding at least those would be welcome. For example, some ASCII microtonal music notations use | for quarter tone sharp (meaning and arrow upwards) and ! for quarter tone flat, but other characters could be used as well, if that would cause problems for your parser. A consistent interpretation of enharmonic notation would be essential in this context as well, as a ds can be tuned differently to an eb (see my previous post). Doing so is possible even when translating pitches into integers (both for absolute pitches and pitch classes), if you go beyond 12 pitches per octave in the translation. For example, if you internally would use 31-tone equal temperament (meantone) then the standard pitch and pitch class arithmetic still works. For the conversion you simply do mod 31 instead of mod 12 for 12-tone equal temperament. I do not know what kind of abstraction layers you use internally in the functions for parsing, processing pitches etc. and how hard it would be to extend the software accordingly. With the right abstraction, however, it might be possible to have a single user-level setting to switch between such pitch representations (e.g., this is supported by my software Strasheela, http://strasheela.sourceforge.net, though Strasheela does not have your notation parsing layer). Are you considering to support microtonal notation at some stage? Best, Torsten Anders -- http://www.torsten-anders.de
  10. Dear Opusmusic developers, > an internal conversion to integers takes place, once the process is completed, the integers are converted back to pitches this is why ds4 becomes eb4 I noticed that some functions enharmonically respell pitches. Is there a way to switch this conversion off, or at least control the default integer->pitch transformation? After all, only in purely dodecaphonic music is ds4 = eb4. Best, Torsten -- http://www.torsten-anders.de
  11. Dear Janusz, Apologies for my late response. >> I tried adding the d4 as your suggested. However, this results in an added eb4 instead, and the harmony is seemingly otherwise shifted as well. Could there perhaps be a bug with that keyword? > When processing pitches ie. transposition, inversion etc... an internal conversion to integers takes place, once the process is completed, the integers are converted back to pitches this is why ds4 becomes eb4. Sorry, we misunderstand each other. What I actually want is to restrict/transform some pitch/omn sequence such that it expresses some underlying harmonic progression (for testing just some simple traditional cadence, later much more complex and not necessarily tonal chords). However, I would like to join the pitches better by not only using harmonic tones, but additionally non-harmonic tones from some given scale. Ideally, such non-harmonic tones should be further restricted, as detailed in my first message in this thread, but for now lets keep things a bit more simple. You therefore suggested > With the TONALITY-MAP you can add other intervals which are not part of the scale you are using. OK, so here is an example doing that.(setf simple-cadence '((c4 maj) (f4 m) (f4 m) (g4 maj) (c4 maj))) (setf size 25) (setf rnd-pitches-smooth (gen-divide 4 (vector-to-pitch '(g3 g5) (vector-smooth 0.2 (gen-white-noise size))))) (setf rhy-pattern (append (gen-divide 5 (gen-repeat (- (/ size 5) 1) '(q q q e e))) '((q e e q q)))) (setf rnd-melody-smooth (make-omn :pitch rnd-pitches-smooth :length rhy-pattern)) (setf tonality (tonality-series simple-cadence :root '(c4 f4 f4 g4 c4) :add '(d4) :closest '(down up))) (tonality-map tonality rnd-melody-smooth)Perhaps I simply do not understand well what the keyword :add of the functions TONALITY-SERIES and TONALITY-MAP does, as it is hardly documented. Given you suggested using it for the above scenario, I expect it allows adding certain (scale) pitches, which can be used freely in addition to any chord.However, it appears that instead of adding the pitch d it adds the pitch eb. Also, it seems that the harmony is also otherwise shifted at times. Sorry for the long response, but hopefully that was clear now.
  12. > Note: Function throws error if no harmonic rhythm is given. Sorry, that doc line is a relict of a previous version of this function, which does not make sense anymore. T
  13. Dear opmo (apologies, cannot really guess your name), I tried adding the d4 as your suggested. However, this results in an added eb4 instead, and the harmony is seemingly otherwise shifted as well. Could there perhaps be a bug with that keyword? Thanks! Best, Torsten
  14. Dear Stéphane, Thanks for your detailed response. Yes, that is some way around that -- re-organise the sublists of the arguments of tonality-map (the tonalities and the pitch/omn-expression), and afterwards to rearrange the sublists of the pitch/omn-expression as before. However, I need some more cleaned up code, otherwise I would soon be lost. Luckily you provided all the pieces, so here is a function that behaves like tonality-map, but the given tonalities can now also express their harmonic rhythm. (defun harmonic-rhythm-tonality-map (harmonic-rhythm tonality-form sequence &rest other-args) "harmonic-rhythm-tonality-map behaves largely like tonality-map, but the harmonic rhythm can now be given explicitly and independent of sublist arrangements. harmonic-rhythm: A list of length values, one for each tonality. Example: (harmonic-rhythm-tonality-map '(1/2 1/2 1) '((f4 m) (g4 maj) (c4 maj)) <sequence>) Note: Function throws error if no harmonic rhythm is given. " (let* ((sequence-aligned (length-span harmonic-rhythm (flatten sequence))) (tonality-mapped (apply #'tonality-map tonality-form sequence-aligned other-args))) (length-span (get-span sequence) tonality-mapped))) #| ; test (setf simple-cadence '((c4 maj) (g4 maj) (c4 maj))) (setf harmonic-rhythm '(2 1 1)) (setf rnd-pitches (gen-divide 5 (integer-to-pitch (mapcar #'round (rnd 20 :low -12 :high 12))))) (setf rhy-pattern (append (gen-divide 5 (gen-repeat 3 '(q q q e e))) '((q e e q q)))) (setf rnd-melody (make-omn :pitch rnd-pitches :length rhy-pattern)) (setf simple-cadence-t (tonality-series simple-cadence :root '(c4 g4 c4) ;; selects randomly per chord either :up or :down :closest '(down up))) (harmonic-rhythm-tonality-map harmonic-rhythm simple-cadence-t rnd-melody) |# #| ; test 2 -- slightly different rhythm (setf simple-cadence '((c4 maj) (f4 m) (g4 maj) (c4 maj))) (setf harmonic-rhythm '(1 1/2 1/2 1)) (setf rnd-pitches (gen-divide 5 (integer-to-pitch (mapcar #'round (rnd 15 :low -12 :high 12))))) (setf rhy-pattern (append (gen-divide 5 (gen-repeat 2 '(q q q e e))) '((q e e q q)))) (setf rnd-melody (make-omn :pitch rnd-pitches :length rhy-pattern)) (setf simple-cadence-t (tonality-series simple-cadence :root '(c4 f g4 c4) ;; selects randomly per chord either :up or :down :closest '(down up))) (harmonic-rhythm-tonality-map harmonic-rhythm simple-cadence-t rnd-melody) |# Unfortunately, this function does not do what I expected -- chords are still changed at bar boundaries. What am I missing?
  15. Thanks for your quick response! Yes, I see now that the combination of tonality-series and tonality-map does a better job "quantising" into a harmonic progression than harmonic-path. Is there perhaps already some way to control the harmonic rhythm beyond changing chords per bar? > With the tonality-map you can add other intervals which are not part of the scale you are using. I tried adding more scale pitches using the keyword :add of tonality-map (even though this simply extends the set of tones allowed, without further restrictions). (setf simple-cadence-t (tonality-series simple-cadence :root '(c4 f4 f4 g4 c4) :closest '(down up))) (tonality-map '(simple-cadence-t :add '(d4)) rnd-melody-smooth)Seemingly that does not work with something defined with tonality-series, instead expects a result of create-tonality, yes? At least that is what I guess from the error message: > Error: There is no tonality or chord named: simple-cadence-t.Thanks! Best, Torsten
  16. Dear developers, Opusmodus has a nice and rather extensive documentation. Nevertheless, I wondered why you use manually written rtf files for that. As you most likely know, Common Lisp already supports facilities to add documentation to symbols (e.g., functions) themselves. Example: try (documentation 'list 'function). With such facilities some automatically generated documentation could be created (at least partly), which would at least avoids certain typos. I ran in only a few typos so far in the documentation, but they exist. Here is an example: In reference, the first argument of TONALITY-SERIES is root, but that is wrong, as documentation of function itself reveals. I understand that missing formatting of the documentation strings could be a problem. However, the doc string could use a syntax like markup, which could be automatically translated into a richer formatting with headlines etc. Of course, I do not expect you to switch the documentation system now any time soon, considering all the work that went into the manual documentation. I only wonder why you did not use the existing facilities provided by Lisp itself. Best, Torsten
  17. Dear Opusmodus developers and users, Apologies, this post is rather long, but it actually consists of two posts, a general user questions, and then a feature request or question how we could implement some feature together. Opusmodus provides nce tools for expressing and processing harmonic information. I would like to use that to "quantise" some given OMN expressing into a harmonic progression. More specifically, I have a harmonic progression (for now created by hand) and as a starting point a random melody. The melody should use pitches of the harmonic progression. Below is a first attempt at this. (setf simple-cadence '((c4 maj) (f4 m) (f4 m) (g4 maj) (c4 maj))) (setf size 25) ; number of melody notes (setf rnd-pitches-smooth (gen-divide 4 (vector-to-pitch '(g3 g5) (vector-smooth 0.2 (gen-white-noise size))))) (setf rhy-pattern (append (gen-divide 5 (gen-repeat (- (/ size 5) 1) '(q q q e e))) '((q e e q q)))) (setf rnd-melody-smooth (make-omn :pitch rnd-pitches-smooth :length rhy-pattern)) (harmonic-path simple-cadence rnd-melody-smooth :type NIL :octave 'seq :seed 1) Here are my questions. I would like to "maps" the incoming melody to the closest harmony note, but instead HARMONIC-PATH seemingly always looks only at a single harmony note at a time, and the order of notes in the harmony is changed by the arg type. Also, is there a way to control the harmonic rhythm? Ideally, I would like to express the harmonic rhythm directly in the harmonic progression, e.g., like:'(w (c4 maj) (f4 m) h (f4 m) (g4 maj) w (c4 maj))However, this information is seemingly not supported by the above approach. Here starts the second part of this message. I understand that this is now a bit more tricky, but is there a way to include and control non-harmonic tones, which still belong to some scale (and this scale may also change over time...)? I assume this is not yet implemented, but I figure it should be possible in principle. Here is a first sketch how the interface could look like.(follow-underlying-chords-and-scales scale-tonality chord-tonality omn-expression :non-harmonic-tones #'boolean-function)Here is a usage example, using variables from above.(harmonic-path major simple-cadence rnd-melody-smooth :non-harmonic-tones #'short-notes-on-easy-beat?)Instead of expecting a function where users freely define what they intend a non-harmonic tone should be, there could of course also be a limited number of cases predefined, which are then only specified by the user like so.(harmonic-path major simple-cadence rnd-melody-smooth :non-harmonic-tones :short-notes-on-easy-beat?)I hope I explained myself well enough, so that you see the purpose and expressive power of such a function. This function would traverse over the given omn-expression (e.g., using some variant of mapcar) and transform the pitches of the omn-expression as necessary. It needs to look not only at a single pitch at the time, but also takes the context into account, which is a bit tricky, but not impossible to do. Would such functionality make sense for you? How would you go about to implement it yourself? BTW: Fixing the random seed with the :seed argument seemingly does not stop generation of different results. Is this a bug? Thank you! Best,Torsten --Dr Torsten AndersCourse Leader, Music TechnologyUniversity of BedfordshirePark Square, Room A315http://www.torsten-anders.de
  18. Dear Opusmodus developers, Congratulations on your software! This is some nice algorithmic composition system. What I like in particular is that you make algorithmic transformation of music more strait forward compared to previous systems (and I used quite a lot of them). Your new music representation format OMN represents the different "dimensions" of music (rhythm, pitches, ...) together in a rather simple way, which makes it more easy to process such multi-dimensional data. I already have many concrete questions, after playing around with the system for several hours now, but I better post these separately. (I am not quite sure always what the right sub-forum would be for every question, so please bear with me.) Torsten Anders --Dr Torsten AndersCourse Leader, Music TechnologyUniversity of BedfordshirePark Square, Room A315http://www.torsten-anders.de
×
×
  • Create New...

Important Information

Terms of Use Privacy Policy