torstenanders

I would like to use some instrumental playing techniques that are not yet explicitly supported by Opusmodus, specifically extended flute techniques: whistle tones, jet whistle, low hoots and the like. Should I just wait for version 2, or is there already some trick now to have user-defined playing techniques specified? Thanks! Best, Torsten

It seems there is a problem with the notation and MusicXML export of the "duration" of gradual tempo changes. The end of the tempo changes is shown too early, already at the beginning of the bar specified as its duration. (If a longer duration is specified to correct for that, then all subsequent tempo changes are delayed accordingly.) In the following example, the initial accellerando should last for 4 bars, but the final tempo q=200 is already displayed in the notation output at the beginning of bar 4, i.e., after 3 bars. Note that the tempo changes in the playback are correct, but the notation is not (nor the tempi in the exported Sibelius file). (setf pitches (gen-repeat 20 '((c4 d4 f4 g4)))) (setf tempo '((q :accel 70 200 1/32 4) (110 1) (:rit 100 60 1/32 2) (120 1) (60 1) (120 1) (110 1) )) (def-score test-tempo (:key-signature 'chromatic :time-signature '(4 4) :tempo tempo) (inst :omn (make-omn :pitch pitches :length (span pitches '(1/8))) :channel 1 :sound 'gm :program 'Clarinet)) By the way, the documentation of the tempo argument of def-score seems to suggest that the duration (argument count) of individual tempo statements can be independent of bars by specifying :length. However, I was not able to specify that. Please see below for a non-working attempt. What am I misunderstanding here? (setf tempo '((q 170 :length 3/2) (:rit 150 100 1/16 :length 1/2) (90 1) )) Thanks! Best, Torsten

Is there a way to define transitions of playing techniques over one and multiple notes? For example, how to notate for a string instrument the following? ord. -> sul tasto Thanks! Best, Torsten

Is there a way to append or even otherwise transform scores created with def-score? For example, it would be useful to have different sections created in different files, and then assembled together in one file. Of course, in principle I can currently create the individual parameters and parts in individual files, and then have only a single def-score definition in one place, but that is less convenient (intermediate results are not shown as score). More generally, is there a way to process intermediate results with multiple parts? If we would have access to a polyphonic score, then in principle there could be also score transformations that take the polyphonic context into account (e.g., Music21 allows for that). I understand that the meta information in the score header (title, composer etc.) can be inconsistent across def-score results if they are appended, but that should not prevent having some way to process intermediate results with multiple parts in principle. Perhaps there could be some simpler sibling to def-score that would leave out all information that should be defined globally only once, but allow for the creating of sections multiple parts, e.g., some def-particell (using a German word for a reduced/unfinished score, but still a score, not just a part)? Thanks! Best, Torsten

Finally it is the question whether you want to generate music with the help of blackboxes/tools (whether open source or OM)... or you want to think, to reflect and to program your own ideas, and not to take what tools can easily generate (in this case you are not/less "independent"). Actually, I don't see this necessarily as an either-or. As someone who spend many years developing a composition system from scratch on my own I would say that -- if your main goal is actually composing and not developing -- then you should welcome the tools that are useful for your purposes, and not necessarily trying to stay "pure". For own functions I would try to avoid any dependency on software not freely available, but not for a composition project. Best, Torsten

Would it help to have your transformation functions be related to explicit scales and its scale degrees (instead of measuring intervals in semitones)? That is what I did in my own computational harmony model. That allowed me to use arbitrary scales and the chords that belong to those scales. The tricky bit is that I am using constraint programming, where each variable can be controlled by multiple restrictions (constraints). So, I can restrict both intervals measured in semitones and in scale degrees independently. Would be tricky to translate that into plain functions. Attached is a related (unpublished) paper that outlines the approach in principle, though many details are missing in that paper. Tricky to share the code on that, because there is lots. Some core functionality (the data structure) is defined here (Oz programming language). https://github.com/tanders/strasheela/blob/master/strasheela/contributions/anders/HarmonisedScore/source/Score.oz Constraint programming is also possible within Common Lisp (e.g., with Screamer, https://nikodemus.github.io/screamer/, and other constraint solvers exist as well), and for mere harmony modelling (in contrast to modelling polyphonic music composition in general) this might be rather fast. Best, Torsten TorstenAnders-HarmonyModel-CP2016.pdf

> Package Management Simple answer: use a separate package for a larger code project, and use ASDF, http://www.cliki.net/asdf There are online tutorials available, and for your kind of projects so far you do not need much. > TDD (Test Driven Development) With a REPL-based development this is less of an issue, as you may have noticed already. If you really want to, there are various unit test etc. environments available for Common Lisp. I never consistently used any. http://www.cliki.net/test framework http://www.mozartreina.com/unit-tests-lisp.html > is it wise to "lock in" to the Opusmodus product when writing my own functions Good question. I would tend not to. Just ported a little library to Opusmodus that I once created for a plain Common Lisp project, and later used with PWGL. All I had to do was getting rid of some recent PWGL-specific extensions in the ASDF file... On the other hand, if some system drastically would simplify your work and thus save you development time, then that would be different. I would be pragmatic. > When to use a functional approach and when to use an object oriented approach This is not an either-or decision. With a multi-paradigm language, including Lisp, you can combine such paradigms. For example, you can have higher-order functions processing objects. Anyway, I avoid state-based programming and side effects when possible, and if state is necessary then I try to encapsulate it locally so that towards the outside the program still appears stateless. In such a context, objects are then just some convenient data abstraction with method dispatch and a potentially hierarchic data "type" tree. Nevertheless, do not underestimate the convenience of simple data types like nested lists. With these you can directly see the results of your computations, while with objects you usually need some form of accessor to see certain detail. > p.s. the books I'm using right now are: Here is another recommendation showing more advanced Common Lisp programming in action - Norvig, P. (1992) Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp. Morgen Kaufmann Publishers. This book uses Scheme instead of Common Lisp, but helps to learn fundamental concepts how to organise code. - Abelson, H. et al. (1985) Structure and Interpretation of Computer Programs. Cambridge, MA: MIT Press. For a more advanced understanding of CLOS User-level: - Keene, S. E. (1989) Object-Oriented Programming in Common Lisp: A Programmer’s Guide to CLOS. Addison-Wesley. Looking under the hood: - Kiczales, G. et al. (1991) The Art of the Metaobject Protocol. MIT Press. > How to structure your project There are no hard rule on this, but perhaps a few rules of thumb, like you try to avoid repetitions in code by abstractions, or that you may try to simplify your programs by extending your programming language. The above books make help. Best, Torsten

Very nice start! Unfortunately, the model results in some enharmonic problems. For example, (apply-tonnetz '(c4 e4 g4) '(n)) should result in f-minor, but instead results in (c4 f4 gs4). I assume there is no real way around that with Opusmodus and 12-EDO so far. I solved such problems once simply by using a different tuning system, e.g., 31-EDO, because that tuning has distinct pitch classes for tones like ab vs. gs, and distinct pitch class intervals for, say, a minor third vs an augmented second. Any plans to go beyond, e.g., having transformations for chords beyond major and minor, taking scales into account etc? Minor issue: some of your tests meanwhile fail, likely because of some later refactoring. (equal (triad-is-major '(c4 e4 g4)) 't) Also, you may want to introduce some function that allows for recursive transformations to avoid things like (move (move (move triad 'l) 'p) 'r)). Best, Torsten

> when I tried to eval your "cut-holes" function it throws an error What exactly is your function call? Best, Torsten

Thanks!

Dear Ole, I just created something similar for myself. Here the idea is that a binary list expresses whether a note should be kept (value 1) or turned into a rest (value 1). So, you can mute any pattern of notes by creating binary lists with all the tools available for that in Opusmusic. The main function is cut-holes, the rest is just a short demo. (defun cut-holes (lengths binary-list) "Expects a list of lengths and a binary list. Every length at a position of a 1 is left untouched, while every length at a 0 is turned into a rest. NOTE: For now, a flat list is returned, and OMN expressions are not supported." (mapcar #'(lambda (l b) (if (= b 0) (* l -1) l)) (flatten lengths) (flatten binary-list))) (setf pitches (gen-repeat 16 '(c4))) (setf lengths (span pitches '(1/8))) (setf melody (make-omn :length (cut-holes lengths (gen-repeat 16 '(1 0))) :pitch pitches)) This simple function needs a list of lengths (fractions). If you have already an OMN expression then you can extract the durations with (omn :length melody), e.g., in your extended version of such a function. Best, Torsten

Dear Wim, neo Riemannian functions and Tonnetz functionality has been implemented as part of Music21, or extensions of it. E.g., see https://groups.google.com/forum/#!topic/music21list/crDnYIx6kvo Perhaps you want to port some of that Python code to Common Lisp, that might be easier than developing the algorithms from scratch? BTW, some of the code discussed there is by Dmitri Tymoczko, the author of A Geometry of Music (which, I agree, is a book really worth reading for the likes of us :). Best, Torsten PS: I assume you are not only programming in Common Lisp, so you may already know Python. (If not, that is rather easy to learn if you know Lisp already...)

Me too.

Just to second that there would be more users interested in that ;-) T

> I think it is not feasible to introduce too many new symbols. They are not practical because hard to remember and therefore not commonly used. It would be ideal to let users define what accidental symbols they want to introduce. They can then decide themselves how many symbols they want to handle Several notation software packages do already support a wide range of microtonal accidentals. There are too many notation systems to list them all here, but the highly comprehensive sagittal notation alone is already supported by various notation software, e.g., built-in in the upcoming Dorico via its SMuFL (Standard Music Font Layout) alongside many other accidental sets (http://www.smufl.org/version/latest/, e.g., http://www.smufl.org/version/latest/range/spartanSagittalSingleShaftAccidentals/); built-in in MuseScore (https://musescore.org/en/node/41001); available in Sibelius via a script (http://dkeenan.com/sagittal/) etc. Yes, automatically exporting microtonal scores to notation software is indeed tricky, but even with the limited support we have with current notation software there are ways (admittedly hacks, but nevertheless -- see attached), and with the new Dorico, which internally represents pitch more flexibly, there may in the future be more strait-forward ways too. I don't know how Opusmodus internally creates its notation, but if at some stage in the future it can perhaps support arbitrary fonts, e.g., for user-defined articulations (e.g., various string techniques http://www.smufl.org/version/latest/range/stringTechniques/, or percussion beaters http://www.smufl.org/version/latest/range/beatersPictograms/ etc.) then why not also allow for arbitrary accidentals? Support for a simple mapping of the notation Janusz proposed to accidentals would allow users to define which pitch + accidental etc. to notate for which OMN pitch. E.g., ;; Notation of 31-EDO with common accidentals plus quarter tones (alternatively, this temperament can also be notated with double-sharps and double-flats) ;; I left out octaves in notation for simplicity and I rounded pitch deviations to full cent ;; Explanation of mapping notation ;; (<OMN notation> <glyph in SMuFL>+ [<pitch nominal if deviating from OMN notation>]) '( (c (nil U+E261)) ; Natural (c+39 U+E282) ; quarter-tone sharp (c+77 U+E262) ; sharp (cs+16 U+E260 d) ; flat ; ... ) The notation for quarter and sixth tones listed above could be encoded in the same way, but if users could encode their own notation this way, then this system would not be hard-coded to any notation. Using rounded cent values might not be enough for very high precision pitch notation, but is likely enough for practical cases. Best, Torsten EIGHTS_OF_TONES.pdf examples_and_libs.zip

On 2nd thought, users might be able to define some custom representation on top of OMN so that user-defined pitch and accidental symbols could be translated into the cent-based representation you suggest (e.g., C4+50). However, if at least users could define their own accidentals for specific tones, that would be charm. For octave-repeating tuning systems (which are the most common) it would be sufficient to have users define mapping of specific tones without octave component to accidentals (or accidental combinations). Basically, if users could freely define accidental mappings like those of 1/4 and 1/6 tones you used above, e.g. by mapping to special positions in certain accidental fonts. I know that this cannot be directly exported to MusicXML (although with some tricks using things like templates and Sibelius scripts certain things are indeed possible...), but the Opusmodus notation can also be directly exported to PDF already :) Such a proposal is likely more easy to realise, and it is also fully user-customisable. T

Dear Janusz, Thanks for your response. What you are suggesting here are special accidentals for 1/4 tones and 1/6 tones (24-EDO and 36-EDO) -- simple subdivisions of the standard 12-EDO proposed early on in the 20th century -- and you are suggesting a numeric pitch notation based deviations from 12-EDO in cent. Microtonality and microtonal notations offer to rethinking harmony from an acoustic foundation, like the figured bass notation offered to think about harmony in a different way than in Renaissance counterpoint, and the later thinking in triads and their inversions offered a next level of abstraction. But such rethinking needs suitable foundations. Notating all microtonal pitches as deviations of 12-EDO is about as cumbersome as trying to compose Wagnerian harmonic progressions in Baroque figured bass notation. Sure, that is possible in principle, but not suitable. If you take the 1/4 tones and 1/6 tones of your proposal, complement these by 1/12 tones, add some memorable ASCII representation (not cent deviations), and arrange these in a systematic way then you already have 72-EDO, a possible rendering of HEWM, the simplest notation I was proposing above, which is suitable for both notating 11-limit JI and at least a few equal temperaments. While HEWM is restricted (e.g., many widely used equal temperaments could be expressed in that notation; and JI intervals beyond 11-limit are not included), at least it is based on acoustic foundations and is therefore more future-facing than 24-EDO or 36-EDO. Please don't get me wrong. I don't want to appear here as a zealot for some obscure temperaments. I just suggest to have the microtonal pitch representation based on *musical* (e.g., harmonic) considerations, not just some cent figures. As I said in my first post, OMN supports pitch *names*, because they are more memorable etc. than mere frequency values. Microtonal pitches should be treated the same (while having numeric cent values as an option is certainly welcome as well). What would be truly great is if you would allow users to add such functionality (extending the OMN parser by adding new pitch symbols or accidental names, and allowing for defining how these accidentals are notated in the score). Anyway, if you feel that supporting a microtonal notation along the lines I sketched above is beyond what you have time for or are interested in then I understand that of course. After all, one should not aim for a perfect system, but one that is good enough for the purposes of the majority of its users. ;-) Best, Torsten

Great, thanks! Perhaps it would be useful to somewhat change the shortcut notation in the menu for other users. T

Dear Janusz, We were recently discussing potential microtonal support for Opusmodus. I understand that you suggested a representation based on 12-tone equal division of the octave (EDO) with free cent deviations as a flexible and generic solution. I agree that this could be a sufficient solution in the background, because all microtonal pitches, intervals, chords and scales can be specified that way. However, in my view it would be an insufficient solution as the only microtonal representation at the user-level, because it would be highly cumbersome. Imagine composing a melody in C-major by writing and reading only frequency values in Hz. Of course every tone in C-major can be expressed as a frequency in principle, but as a musician you rarely want to think in such numeric detail. Besides, a slight tuning variation would change all the figures. Composing microtonal music in cent values is equally awkward. I understand that for a CAC environment like Opusmodus it is important to have a generic representation, but there are so many microtonal tunings and notations. Luckily some efforts have been done my the community already towards more generic representations. Basically, there are three main microtonal directions in Western music: Just intonation (JI): Multidimensional tuning approach, where intervals can be represented as whole number frequency ratios, with theoretically an unlimited number of tones per octave. Examples for JI intervals are 3:2 (perfect fifth), 5:4 (major third), 7:4 (harmonic seventh), 7:6 (subminor third) etc. JI thinking is important, e.g., for extending harmony beyond traditional boundaries by intervals that musicians can intonate by ear, and it was useful for that already centuries ago. The Common Lisp support of fractions makes JI support particularly interesting for Opusmodus. Equal temperaments: Equal divisions of the octave (or other intervals). Some equal temperaments are particularly widely used and researched, because they approximate certain just intonation intervals particularly well, including 19-EDO, 22-EDO, 24-EDO (quartertones), 31-EDO (almost quarter comma extended meantone), 41-EDO (almost Pythagorean tuning), 53-EDO and 72-EDO. Other temperaments: Designed to reduce the total number of tones and that the cognitive workload using them, which approximate JI intervals. Examples are the various meantone temperaments, or well temperaments. My explanation already suggested that these different schools of thought are related. Various equal temperaments are widely used, because they approximate certain JI intervals rather well, while at the same time allowing for arbitrary transpositions within a limited number of tones overall. For example, our standard 12-EDO approximates 3:2 and its relatives (4:3 -- 3-limit intervals) almost perfectly, and 5:4 and its relatives (5:6 etc. -- 5-limit) reasonably well, while 7:4 (7-limit) or 11:8 ( 11-limit) are not part of 12-EDO. Some notations aim to present a unified format for multiple approaches. Such notations could be a useful foundation for a microtonal representation of Opusmodus. A relatively simple example of such an approach is the HEWM notation, which stands for Helmholtz / Ellis / Wolf / Monzo notation (Monzo, 2005a and 2005b). This staff notation is an extension of the common music notation designed to support both 72-EDO (a superset of 12-EDO, 24-EDO, and also 36-EDO), and 11-limit just intonation. The notation exists both as staff notation, and ASCII for written communication in emails (and potentially programming code). In this notation, all nominals (pitches without accidentals, like a, b, c, d...) are considered to be tuned in fifth (Pythagorean tuning, 3-limit). In other words, the interval C, E is considered a Pythagorean major third, not a just major third. For each higher limit, the notation introduces a pair of accidentals to raise or lower the pitch accordingly. For example, the JI major third is notated C, E-, where the minus sign (-) represents a transposition by a syntonic comma downwards. That way, the notation can distinguish between a Pythagorean major third and a just major third. In a performance situation, this interval can either be tuned in 72-EDO or justly -- but the notation is the same. Particularly comprehensive notations based on the same principles are Sagittal notation (Secor and Keenan, 2004) and the Extended Helmholtz-Ellis JI Pitch Notation (Sabat and Schweinitz, 2005). Sagittal is explicitly designed to support both just intonation (including highly complex intervals) and many equal temperaments, but Extended Helmholtz-Ellis JI Pitch could do that in principle as well to a certain degree. It is more simple than Sagittal (while more complex and HEWM), and could therefore be preferable. However, only Sagittal offers also ASCII representations for all its accidentals, so for a programming environment it could be a more natural choice. If Opusmodus would support any of these notations both in OMN and the resulting notation, then it would offer a highly flexible environment for composers interested in microtonal music, and it would allow for a variety of tunings with a single notation. The existing ASCII representations could likely not be directly translated into OMN, because many special characters are reserved in Common Lisp, but having them would be a starting point. I would be happy to help designing a notation suitable for Opusmodus, i.e., taking the restrictions of Lisp syntax into account. What do you think? Best, Torsten PS: If you also want to support other temperaments beyond equal temperaments and JI then we should discuss how to represent regular temperaments (Milne et al. 2007), but then the notation gets even more tricky. References Milne, A., W. Sethares & J. Plamondon (2007) Isomorphic Controllers and Dynamic Tuning: Invariant Fingering over a Tuning Continuum. Computer Music Journal. 31(4), 15–32. Monzo, J. (2005a) 72-tone equal-temperament / 72-edo. In: Encyclopedia of Microtonal Music Theory. Available from: http://tonalsoft.com/enc/number/72edo.aspx Monzo, J. (2005b) HEWM notation. In: Encyclopedia of Microtonal Music Theory. Available from: http://tonalsoft.com/enc/h/hewm.aspx Sabat, M. & Schweinitz, W. von (2005) The Extended Helmholtz-Ellis JI Pitch Notation. [online]. Available from: http://www.marcsabat.com/pdfs/notation.pdf Secor, G. D. & Keenan, D. C. (2004) Sagittal. A Microtonal Notation System. Xenharmonikôn, An Informal Journal of Experimental Music. 18. Available from: http://sagittal.org/sagittal.pdf Torsten Anders http://www.torsten-anders.de

This sounds like a stupid question, but what is the keyboard short-cut for stopping stopping snippet playback? I know that there is a short-cut given in the respective menu, but I cannot decipher that. I am on a Macbook. The first key is the cmd-key, but I don't find the 2nd key on my keyboard. (I was putting up with this for a while now, but I though now that this might be an issue for others as well.) Thanks. Best, Torsten

Brilliant! Thanks for the quick response. T

Minor addition for clarity: split-lengths does not what I am after.

Concerning general literature on algorithmic composition and spectral music consider the following book. It contains a nicely detailed article by Rozalie Hirs on Tristan Murail's use of OpenMusic for a specific composition, which Rozalie wrote while or after she was his pupil. Hirs, R. & Gilmore, B. (eds.) (2009) Contemporary Compositional Techniques and OpenMusic. Collection Musique/Sciences. IRCAM/Delatour.

> If it’s Lisp expressions you’re commenting out, you can always prepend #+not Thanks, but I think added a block comment with M-# is more clear, as the comment is formatted as such... Torsten

Dear all, Is it possible to split a given list of lengths (or omn) into sublists (bars) according to a given sequence of time signatures? That would be very useful for all sorts of operations. e.g., imposing a meter on unmetered music generated by whatever algorithm; metric shift where some note or rest is added at the beginning of a rhythm, but the metric structure is kept the same and all notes/rests move "to the right" as necessary etc. Here is an example of what such a function could do. ;; the hypothetic function gen-bar expects a list of time signature forms (or bar durations as ratios) and a (flat) list of lengths or OMN. It returns the lengths/OMN split into sublists according to the time signatures. (gen-bar '((3 4 2)) '(1/4 1/4 1/8 1/8 1/2 1/4)) -> ((1/4 1/4 1/8 1/8) (1/2 1/4)) (gen-bar '((3 4 2)) '(1/4 1/4 1/2 1/8 1/8 1/4)) -> ((1/4 1/4 1/4 tie) (1/4 1/8 1/8 1/4)) The hypothetical gen-bar is quasi an inversion of the existing function get-time-signature. Such functionality seems so basic considering the OMN representation that perhaps something like this is already there and I simply cannot find it? Thanks! Best, Torsten