torstenanders

Just evaluate this. (defparameter *do-verbose* nil "Enable or disable traces printed by do-verbose.") For some context see

Concerning own GUI applications: you can already do that. This is independent of Opusmodus. For example, on a Mac CCL (the Lisp compiler on which Opusmodus is built) has a built-in Cocoa Interface and Objective-C bridge. There also exist other GUI libraries for Lisp. For example, check out GUI toolkits LISPCOOKBOOK.GITHUB.IO A collection of examples of using Common Lisp

I cannot answer this for Janusz, but I can provide some further reflection on this. You could investigate how the Emacs-Slime interface talks to the CCL compiler, on which Opusmodus is based, and then use that same protocol for your purposes. Of course, this will always only work if on the machine in question Opusmodus is installed. Also, Opusmodus must be started first (which currently always starts the full IDE as well, AFAIK -- at least it does for me, and I use Opusmodus meanwhile mainly via the Slime interface). It is likely possible in principle to get around starting the full IDE each time and instead only start CCL with the relevant Opusmodus definitions, but users of your plugins or custom applications will always need to buy Opusmodus themselves, so this is pretty much a niche in a niche market... Not sure whether there is a market here for Opusmodus Inc. to spend development resources, which would make this more suitable for your purposes. Obviously, this company is not someone like Apple. It cannot afford throwing out development tools for free, I guess. Perhaps Opusmodus Inc. could ask for a licence fee from developers who build applications based on Opusmodus definitions. That might open a market that would pay Opusmodus for investing the necessary development resources for something like that. If there are a few developers willing to pay such a fee, this might actually be quite workable for both sides, the developers and Opusmodus Inc. It then might be possible to use Opusmodus definitions in a "normal" Common Lisp application (perhaps even supporting tools like roswell for easy executable creation). Just my 2 Euro-cent on this question...

OK, no problem. Thanks for the feedback.

I just noted that the code I shared above depends on other definitions in my library (e.g., the function preview-score). Below is an update that instead uses only builtin Opusmodus functions. Holler in case this is not working for you, as the code on my machine is a bit different, and I did not test the code below... (specifically, the version below only works for the scores with instruments from the ps set gm, while my own code is more flexible, but then again depends on other custom definitions). ;; Emacs lisp code: put into your Emacs init file, e.g., ~/.emacs ;; Custom function for previewing Openmusic snippets etc (defun slime-eval-and-preview-opmo-snippet-before-point () "Evaluate the Openmusic snippet (an expression) preceding point and preview that snippet." (interactive) (let* ((score (slime-last-expression)) (full-expr (concat "(ps 'gm (list :treble " score "))")) ) ;; (print (concat "debug: " full-expr)) (slime-interactive-eval full-expr))) (defun slime-eval-and-preview-opmo-score-before-point () "Evaluate the score (an expression in the tot score format) preceding point and preview that score (notation and playback)." (interactive) (let* ((score (slime-last-expression)) (full-expr (concat "(ps 'gm " score ")")) ) (slime-interactive-eval full-expr))) (defun slime-stop-opmo-playback () "Stop the currently playing Openmusic sound playback." (interactive) (slime-interactive-eval "(sequencer:sequencer-stop *audition-sequencer*)")) (defun slime-opmo-midi-playback () "(Re-)play the last Opusmodus score with a separate MIDI playback window." (interactive) (slime-interactive-eval "(display-midi *last-score* :display :window)")) (add-hook 'lisp-mode-hook (lambda () (local-set-key (kbd "<A-f2>") #'slime-eval-and-preview-opmo-snippet-before-point) (local-set-key (kbd "<A-f3>") #'slime-eval-and-preview-opmo-score-before-point) (local-set-key (kbd "<A-f4>") #'slime-opmo-midi-playback) (local-set-key (kbd "<A-f1>") #'slime-stop-opmo-playback) )) ;; Creating a new "Opusmodus" menu in the menu bar to the right of "Lisp" menu. ;; This new menu is only shown when in lisp-mode (define-key-after lisp-mode-map [menu-bar opusmodus] (cons "Opusmodus" (make-sparse-keymap "hoot hoot")) 'lisp) ;; Creating a menu item, under the menu by the id “[menu-bar opusmodus]” (define-key lisp-mode-map [menu-bar opusmodus preview-score] '("Preview score cmd-f3" . slime-eval-and-preview-opmo-score-before-point)) (define-key lisp-mode-map [menu-bar opusmodus preview-snippet] '("Preview snippet cmd-f2" . slime-eval-and-preview-opmo-snippet-before-point)) (define-key lisp-mode-map [menu-bar opusmodus stop-playback] '("Stop playback cmd-f1" . slime-stop-opmo-playback)) (define-key lisp-mode-map [menu-bar opusmodus replay-score] '("(Re)play last score cmd-f4" . slime-opmo-midi-playback))

Has there perhaps been some change with the HTML rendering in the Assistant in recent months since August? On my Macbook Pro (OSX 10.12.6) with the latest Opusmodus version, (most) links are not followed anymore, and the CSS rendering is unreliable (can be missing but when the same page is reloaded it might be there -- sometimes multiple reloading is required; when reloading it again later, the CSS might be ignored again). Most importantly, however, I cannot select any text on the HTML page anymore, i.e. I cannot evaluate example code from HTML pages anymore. I export all the documentation of my own Opusmodus extensions into HTML mainly for that reason, so that the various examples of the docs can be evaluated from within Opusmodus, but that seems to be broken currently. Can others reproduce such problems?

Yes, I can specify that the attribute sends some MIDI messages like key switches or CC messages at the moment when the event with the attribute starts. However, for defining an attribute like ped1 I need to additionally specify a MIDI message to be send at the end of the note in question. And for defining an attribute ped I would need to be able to specify the following behaviour. ;; Pedal depressed for exactly two notes '(q c4 ped e4 g4 c5) ;; Pedal depressed for the whole phrase '((ped q c4 e4 g4 c5)) > You can define any attributes with DEF-SOUND-SET. Can I define with def-sound-set an attribute like ped1 where a MIDI message is send at the beginning and another message is send at the end of a note? Can I define an attribute like ped with the behaviour shown above? If that would be possible, that would be great, then I can define things like half-pedal1 myself Currently, I don't know how I could do that. For me personally the export to MusicXML and the proper notation of pedalling lines is less important. I can later translate a textual notation inserted by Opusmodus by hand into the proper notation with a scoring application. Here is an example of what Dorico can do in that regard and I don't need Opusmodus to be able to control such graphical detail as well, I will need to revise it manually anyway https://steinberg.help/dorico/v1/en/dorico/topics/notation_reference/notation_reference_pedal_lines_piano_retakes_changes_c.html However, being able to control the pedalling MIDI output from Opusmodus during the composition process would be nice

Thanks a lot! Brief question just to clarify: the MIDI output of the existing ped and ped1 attributes cannot be defined with def-sound-set? Confirmation: The MIDI output of sost-ped and una-corda is working as well. For completeness, harm-ped (available for Pianoteq) is not. One of the reasons is that at least with Pianoteq 6 it should use CC 69 instead of CC 68 as specified in the pianoteq sound set, but that is not the only reason (seemingly the relevant text attribute is not even existing. Anyway, that is an only rarely used technique and available on only few real pianos, so this is perhaps less of an issue.

I am trying to add a new text attribute for half pedalling (later in my scoring application Dorico I can translate that into the proper pedalling notation) and then specify for playback the MIDI CC messages it would need to send (e.g., the new attribute half-pedal sets the damper-pedal CC set to 64). Naively, a simple solution seems to be to complement this half pedalling with a text attribute for releasing the pedal (rel-pedal sets damper-pedal to 0) as shown below. So, I added the following to my pianoteq sound set (besides defining these text attributes). :group omn full-pedal (Ped 127) half-pedal (Ped 64) rel-pedal (Ped 0) This is partially already working: all these attributes by themselves work as intended. For example, the following works as intended. And sonically with Pianoteq the difference between half and full pedalling is very clear, so this would really be nice to have '(q c4 half-pedal e4 g4 c5 g4 full-pedal e4 c4) However, besides the fact that this is inconsistent with the use of ped, ped1 and friends, it also does not work fully: releasing the pedal is tricky with this approach. The following two examples do not work as intended. In the first, the requested pedal release is quasi ignored (the change possibly happens to quickly for making a difference) and in the 2nd example, releasing the pedal adds a further unintended note (as rests cannot have user text attributes). '(q c4 half-pedal e4 g4 c5 g4 rel-pedal+full-pedal e4 c4) '(q c4 half-pedal e4 g4 c5 -q rel-pedal) Also, ideally, the new attributes would be consistent in its use with the existing ones, so we would need half-pedal. Any suggestion? Thanks a lot!

Is it safe to completely delete the folders fr.lproj and it.lproj in /Applications/Opusmodus.app/Contents/Resources when I only need the English version? HD space is somewhat limited on my laptop and this amounts to half a GB which I seemingly do not need. The tricky bit is that I would need to delete these folders with every update, but hey Thanks! Best, Torsten

Yes, I understood that, and for a mere preview this is good enough (e.g., no nested layouts needed).

OK, I see. Thanks for making that clear again.

Just for context: my function preview-score (link to doc) in the tot library -- which was perhaps the inspiration for the later function ps -- expands in the background simply into a call to def-score. In def-score, we can specify a layout of nested brackets, braces etc. separately of the actual music, which is expressed by individual single-nested OMN sequences. The function preview-score retained this separation: individual single-nested OMN sequences on the one hand, and the specification of the nested layout separately. By contrast, in the function ps this separation of concerns -- the actual music and the nested layout -- is seemingly gone. The input to ps seemingly must already be nested as required by the layout. That may be more convenient in some situations, but is limiting in others. For example, in a full orchestral score we can have a layout of multiple nesting levels (e.g., brackets for orchestral sections wrapped in "squares" for divisions or the standard combination of the violins in a string section, below is an example). (bracket-group (square-group (violin1-layout 'vl1) (violin2-layout 'vl2)) (viola-layout 'va) (violoncello-layout 'vc) (contrabass-layout 'cb)) Can the function ps handle such nested layouts, or is it only designed for sketches and a full score should be created separately afterwards? In principle, it would be possible with shorthand functions like ps to allow for arbitrary layouts when it expands to def-score in the background (again, as demonstrated by preview-score), but keeping the actual music and the layout separately would likely then be preferable. ... I am just trying to make a switch from preview-score to ps to unify efforts, but I don't want to loose too much functionality I will soon share a version of ps that supports the tot score format (https://tanders.github.io/tot/sources/score.html) so that we can have ps together with various score processing functions.

Apologies. Found the reason for problem 1 in my own setup and fixed it. I had defined a custom articulation ped (expressing a coupler for the organ), which interfered. I renamed that coupler articulation. Anyway, I still would be grateful for a response to the following: Is it correct that the attributes ending in 1 (e.g., ped1) denote a pedalling that is always released (or re-pedalled) at the end of a note, while the other attributes (e.g., ped) can continue to the following note? Can I perhaps somehow change a def-sound-set definition so that the damper pedal is only depressed half for the attribute half-ped?

Thanks! Yes, as I said I know that I can write the following, where rh and lh etc. are standard single-nested OMN sequences. (ps 'my-instrument-set :p (list rh lh)) (ps 'gm :sq (list vl1 vl2 va vc)) Perhaps I just need to define some custom function that automatically translates my preferred representation -- where all parts (including rh and lh) are represented individually for simplifying further processing -- into the representation above

Apologies, this is a lengthy message, but I want to provide all the relevant technical details to demonstrate the problem. I would like to control piano pedalling (e.g., with Pianoteq). Many things seemingly work out of the box once the predefined pianoteq sound set is specified (nice!), but some things I would like to refine. The PDF document 4th Element Attributes lists the attributes related to pedalling: ped1 ped half-ped1 half-ped sost-ped1 sost-ped una-corda1 una-corda First a question (could not find the in the docs): the attributes ending in 1 (e.g., ped1) denote a pedalling that is always released (or re-pedalled) at the end of a note, while the other attributes (e.g., ped) can continue to the following note. Yes? While some of these attributes work as expected, a few do not. For example, ped1 results in MIDI CC messages as expected (:damper-pedal pressed before the note start and then released again before its end). Note the two lines with the :damper-pedal controller events in the result below. Also, the music notation includes some standard piano pedalling notation. (show-midi-events '(q c4 p ped1)) => (#<meta-event :sequence/track-name delta: 0 len: 10 "INSTRUMENT"> #<midi-event :controller time: 0 delta: 0, chan: 1, (:reset-all-controllers): 0> #<midi-event :program-change time: 0 delta: 0, chan: 1, program number: 0> #<midi-event :controller time: 0 delta: 0, chan: 1, (:main-volume :msb): 92> #<midi-event :controller time: 0 delta: 0, chan: 1, (:pan :msb): 64> #<midi-event :pitch-bend time: 0 delta: 0, chan: 1, pitch value (LSB): 0, pitch value (MSB): 64> #<midi-event :controller time: 0 delta: 0, chan: 1, (:damper-pedal): 127> #<midi-event :note-on time: 0 delta: 0, chan: 1, note number: 60 (c4), velocity: 47> #<midi-event :controller time: 256 delta: 256, chan: 1, (:damper-pedal): 0> #<midi-event :note-off time: 256 delta: 0, chan: 1, note number: 60 (c4), velocity: 0> #<meta-event :end-of-track delta: 0 len: 0 #()>) Problem 1 (Fixed) In contrast to ped1, the attribute ped is completely ignored in the MIDI output. There are no :damper-pedal controller events in the result below. This is true for both using this attribute for individual notes and for a group of notes. This is true for both the gm or the pianoteq sound set specified for snippets. It is also true for both snippets and scores. Also, in music notation this attribute does *not* result in a standard piano pedalling notation, but instead in some textual technique Ped above the stave -- this may help to pinpoint the problem. How can I get the attribute ped working? (show-midi-events '(q c4 p ped)) => (#<meta-event :sequence/track-name delta: 0 len: 10 "INSTRUMENT"> #<midi-event :controller time: 0 delta: 0, chan: 1, (:reset-all-controllers): 0> #<midi-event :program-change time: 0 delta: 0, chan: 1, program number: 0> #<midi-event :controller time: 0 delta: 0, chan: 1, (:main-volume :msb): 92> #<midi-event :controller time: 0 delta: 0, chan: 1, (:pan :msb): 64> #<midi-event :pitch-bend time: 0 delta: 0, chan: 1, pitch value (LSB): 0, pitch value (MSB): 64> #<midi-event :note-on time: 0 delta: 0, chan: 1, note number: 60 (c4), velocity: 47> #<midi-event :note-off time: 256 delta: 256, chan: 1, note number: 60 (c4), velocity: 0> #<meta-event :end-of-track delta: 0 len: 0 #()>) (show-midi-events '((ped q c4 p c4 c4))) => (#<meta-event :sequence/track-name delta: 0 len: 10 "INSTRUMENT"> #<midi-event :controller time: 0 delta: 0, chan: 1, (:reset-all-controllers): 0> #<midi-event :program-change time: 0 delta: 0, chan: 1, program number: 0> #<midi-event :controller time: 0 delta: 0, chan: 1, (:main-volume :msb): 92> #<midi-event :controller time: 0 delta: 0, chan: 1, (:pan :msb): 64> #<midi-event :pitch-bend time: 0 delta: 0, chan: 1, pitch value (LSB): 0, pitch value (MSB): 64> #<midi-event :note-on time: 0 delta: 0, chan: 1, note number: 60 (c4), velocity: 47> #<midi-event :note-off time: 256 delta: 256, chan: 1, note number: 60 (c4), velocity: 0> #<midi-event :note-on time: 256 delta: 0, chan: 1, note number: 60 (c4), velocity: 47> #<midi-event :note-off time: 512 delta: 256, chan: 1, note number: 60 (c4), velocity: 0> #<midi-event :note-on time: 512 delta: 0, chan: 1, note number: 60 (c4), velocity: 47> #<midi-event :note-off time: 768 delta: 256, chan: 1, note number: 60 (c4), velocity: 0> #<meta-event :end-of-track delta: 0 len: 0 #()>) Problem 2 (Still open) It would be nice if half-ped would actually result in a half-depressed pedal. Instruments like Pianoteq support that. However, the :damper-pedal is also fully depressed with that technique (see the first :damper-pedal controller event in the result below). Can I perhaps somehow change a def-sound-set definition so that the damper pedal is only depressed half for the attribute half-ped? (show-midi-events '(q c4 p half-ped1)) => (#<meta-event :sequence/track-name delta: 0 len: 10 "INSTRUMENT"> #<midi-event :controller time: 0 delta: 0, chan: 1, (:reset-all-controllers): 0> #<midi-event :program-change time: 0 delta: 0, chan: 1, program number: 0> #<midi-event :controller time: 0 delta: 0, chan: 1, (:main-volume :msb): 92> #<midi-event :controller time: 0 delta: 0, chan: 1, (:pan :msb): 64> #<midi-event :pitch-bend time: 0 delta: 0, chan: 1, pitch value (LSB): 0, pitch value (MSB): 64> #<midi-event :controller time: 0 delta: 0, chan: 1, (:damper-pedal): 127> #<midi-event :note-on time: 0 delta: 0, chan: 1, note number: 60 (c4), velocity: 47> #<midi-event :controller time: 256 delta: 256, chan: 1, (:damper-pedal): 0> #<midi-event :note-off time: 256 delta: 0, chan: 1, note number: 60 (c4), velocity: 0> #<meta-event :end-of-track delta: 0 len: 0 #()>)

The functions ps and def-instrument-set allow some control over the resulting layout of the score (grouping of instruments by brackets etc.), e.g., by using some predefined ensemble "instruments" like :sq for string quartet. Is it perhaps also possible to somehow set the layout options supported by def-score in this context? For example, would it be possible to specify the music for the left and right hand of a piano separately (i.e. not together in a triple-nested list), but then have both parts notated on a grand staff? Here is an example (not working) -- amended from the ps documentation. How can I define an instrument set such that this score would wrap the two parts below in a grand staff? (ps 'my-instrument-set :rh '(((s a4 leg d5 leg fs4 leg d5 leg g4 leg d5) (s a4 leg d5 leg fs4 leg d5 leg g4 leg d5) (s a4 leg d5 leg cs5 leg b4 leg a4 leg g4 leg) (s fs4 leg d4 leg e4 leg cs4 leg e d4))) :lh '(((e fs3 d3 e3) (e fs3 d3 e3) (e fs3 g3 a3) (e d3 a2 d2)))) Another example would be the four strings of a string quartet specified separately etc. I know of course that I could include both parts in a triple nested list for the instrument :p with the gm instrument set, or the strings with the instrument :sq (as demonstrated in the ps documentation). However if possible, I would prefer to specify the left and hand right hand (upper and lower stave) separately, e.g., because I am further processing partial polyphonic scores before they are given to ps (e.g., appending multiple partial scores into a larger score), and for this processing it would help me to know which part is which by its keyword label. Thanks!

I provided a variant for unfold that has some advantages (support for arbitrary function arguments instead of a custom symbol for each argument combination set up with def-unfold-set), but I did not say that it would replace it In addition to what you said, the unfold function is also baked into your counterpoint function, while this alternative is not. > apply the the unfold method to a specific bar Sure. That also works with this variant, as shown above by using the argument section supported by most OPMO functions. (fn-unfold '((tr 12) (ld (2 3) :section 1)) mat) > even to an event Yes, that is something currently not supported by the alternative fn-unfold (except individual functions would support it). As you can see, the definition of fn-unfold is pretty short, more stuff could be added, if we want to. > Why so may users do not read/examine the function documentation. Actually, I was aware of that, which is why I included an example showing the same feature (applying a specific function only to a certain bar) in my original post

Common Lisp does usually not distinguish between lower and upper case in its symbols. Standard Common Lisp compilers always return symbols with only upper case therefore by default, but Opusmodus seemingly does internally some trickery to change that to always lower case. It is possible with Common Lisp to specify symbols that distinguish between cases by wrapping the symbol names within bars (|) like so. ? '|TesT| |TesT| ? '(|TesT|) (|TesT|) Unfortunately, this does not to work fully in Opusmodus for all cases, possibly because of the internal symbol trickery that Opusmodus does. ? '|3M| 3m This symbol does not require the bars in standard Common Lisp, because it only contains upper cases. However, the mentioned Opusmodus magic then turns this case down, so therefore this uppercase preservation does not work here. Summary: if you wrap your symbols in bars and use only symbols that contain both upper can lower case letters or only lowercase letters, the distinction works...

Copied from doc: The 'arp-adlib' arpeggiation needs special mention because it responds to the ordering of pitches in the chord. Look at the third list (bar), third chord. (-e - a5d5fs4 f c6f5fs4 d5b5g4 arp-adlib g5d5a4 gs5ds5gs4 gs5e5gs4) Audition this with Cmd-1 (d5b5g4 arp-adlib)

> can we ... a file with our customized methods with your function? You can put this function fn-unfold wherever you want, as long as that file is loaded at startup, and likewise also any other function including functions like tr above > we can call the specific sets in the unfold function without having to evaluate the complete procedure of each method ? Questions concerning the original unfold function are better answered by Janusz, I guess... Good night (its 23:00 over here...), Torsten

I like how the function unfold allows for rather concisely expressed transformations. I also like that with this function, methods can easily by commented out or added without changing the nesting structure of the overall Lisp program. However, what I do not like is that the unfold methods don't support any further arguments, and as a result the required preliminary work with def-unfold-set is rather cumbersome. So, I rolled by own version of unfold that addresses this shortcoming. This new function works as follows: you can use the names of arbitrary Opusmodus functions, as long as they expect an OMN sequence as first argument. The following example applies first the function gen-retrograde and then quantum to the material mat. (setf mat '((q c4 d4 e4) (h f4 q b3))) (fn-unfold '((gen-retrograde) (quantum :fraction -0.2)) mat) => ((7W B3 7H._QT F4 -E..) (E E4 D4 S. C4 -ET)) If you would like to have functions with more concise names (as unfold does), just define functions with shorter names. Here are some examples. (defun tr (sequence transpose &key (section NIL) (exclude NIL) (ambitus 'piano) (omn NIL)) "Like pitch-transpose, but sequence as first param." (pitch-transpose transpose sequence :section section :exclude exclude :ambitus ambitus :omn omn)) (defun ld (sequence values &key set ignore seed (section NIL) (exclude NIL) (omn NIL)) "Like length-divide, but sequence as first param." (length-divide values sequence :set set :ignore ignore :section section :exclude exclude :omn omn :seed seed)) With the definitions above, we can now use fn-unfold as follows for computing an octave transposition of mat and then applying length-divide to the second bar with the given settings. (fn-unfold '((tr 12) (ld (2 3) :section 1)) mat) => ((Q C5 D5 E5) (3H E5 FS5 G5 3Q A4 BB4 CS5)) BTW: The definition of fn-unfold is pretty short. By far the longest part of this definition is the doc string (defun fn-unfold (fns sequence) "Much like the buildin Opusmodus `unfold`, but instead works with functions and additional arguments can be given to the functions. Apply to `sequence` all fns in order. * Arguments: - fns (list of lists): Each sublist has the form (<omn-fn> &rest <args>), where <omn-fn> is a function expecting an OMN sequence as first argument and arbitrary further argments, and <args> are the further arguments beyond the OMN sequence given to the function. - sequence: OMN sequence * Examples: Some material to use ;;; (setf mat '((q c4 d4 e4) (h f4 q b3))) Remember: all functions used must expect a OMN sequence as *first* argument. ;;; (fn-unfold '((gen-retrograde) (quantum :fraction -0.2)) mat) Some short-hand versions of common functions are defined for conciseness. ;;; (fn-unfold '((tr 12) (ld (2 3) :section 1)) mat) " (reduce (lambda (seq fn) (apply (if (functionp (first fn)) (first fn) (fdefinition (first fn))) seq (rest fn))) fns :initial-value sequence))

> I don't think that modes and scales are archaic systems I also agree that while the distinction between flats and sharps is old it is not outdated. In my view, (eb4 bb4) is a fifth, while e.g. (ds4 bb4) is not, regardless of the tuning system. > the system translate integers 0 1 2 3 4 5 6 7 8 9 10 11 = c, cs d eb, e, f, fs, g gs, a, bb b. That is one way to map tone names to integers. There exist other ways that preserve the enharmonic notation and still allow for the pitch class arithmetic that those 12 pitch class integers allow for. One approach is to translate these tones (cs, db) into another Meantone-EDO that tunes these tones differently, e.g., 31-EDO pitch classes (0, 1, 2, ... 30). With that approach, transposing an eb up a fifth results in the pitch class integer representing bb, which differs from the pitch class integer for as. So, for functions that need to translate the pitch symbols into integers for their magic and then back to symbols, there would be ways that allow to preserve the enharmonic notation. Another approach to do this would be the base-40 pitch representation, a very similar idea, that maps enharmonic pitches to numbers up to 40. Happy to provide further details. Feature request: What I really would like to see in Opusmodus is a pitch representation that is forward looking by generalising as many as possible of the past and alternative tuning systems so that the choice of tone system can be part of the compositional process like any other compositional choice. A particular flexible way to implement that would be by adding support for arbitrary regular temperaments.[1] That system supports in a unified framework Arbitrary equal divisions of the octave (incl. the currently supported 12, 24 and 48 EDO, but also the commonly used 19, 22 and 31 EDO etc.) Just intonation of arbitrary limits Temperaments like Meantone (which brought us these distinction between flats and sharps in the first place) and any other regular temperament (e.g., https://en.xen.wiki/w/Tour_of_Regular_Temperaments) There even exist notation systems that allow to express a rather large range of all this (arbitrary EDOs, just intonation and various other regular temperaments) with a single set of accidentals (http://sagittal.org; http://sagittal.org/sagittal.pdf). Now, I don't expect Opusmodus to introduce any new notation system; expanding the OMN parser is probably too much of a hassle (although a generalised OMN pitch representation would be really nice). However, as we now already have support for microtonal playback output for some tuning systems, why not generalise the playback for playing back arbitrary regular temperaments (or perhaps even arbitrary tuning systems) defined by users. Ideally, this would be expressed at two levels. On the one hand, user-defined tuning tables would specify a mapping how tone names (c, cs, db, ...) should be tuned. For example, tunings like 19-EDO or 31-EDO could be implemented that way (they can be notated with our standard accidentals, they are just Meantone variants). However, this would only work if the system could reliably distinguish enharmonic notation (e.g., ds and eb are tuned differently in these systems), otherwise only the 12 tones of 12-EDO should be tunable. On the other hand, a detuning of a tone (e.g., measured in cent) could somehow be part of the attributes of a note. That was one of the earlier proposals for introducing microtonal pitches. Sorry for somewhat hijacking this thread with a feature request and for a rather long message. However, a more refine pitch representation would be really important for me EDIT: Simplification: just introducing support for arbitrary user tunings should actually be sufficient. Users then can care for implementing their own tuning systems (e.g., based on the regular temperament paradigm or otherwise defined). Anyway, it would still be nice to have such tuning support at two levels: user-defined tuning table specifying how notated pitches (c, cs, db...) are tuned and a note-wise tuning deviation probably as part of the note attributes. Torsten [1] A video explaining regular temperaments. Unfortunately, it goes through concepts rather quickly, expects some music theory background, and is part of a series of videos in a playlist, but I found no better video on this. Link to playlist: https://www.youtube.com/watch?v=DB2aHGW45fY&list=PLF6XElTgRwmNgzWUXIJrVbSHjux8pAQAQ

I can confirm that audition and notation of snippets unfortunately does not work for me either with the builtin Slime in Opusmodus. E.g., I am trying to place the cursor behind an Opusmodus function call an execute the relevant short cut (e.g., C-c o a), but nothing happens. C-c o ? seems to work, though. Anyway, my own Slime interface works, at least for me...

I cannot answer for the builtin Opusmodus Slime functionality, but I developed something similar some time ago on my own, which works in Aquamacs for me. Try copying the Emacs Lisp code below into your Emacs initialisation file (e.g., ~/.emacs), start Aquamacs again and open a Lisp file. The code below adds to Emacs buffers in Lisp mode an Opusmodus menu with some standard commands like for previewing a snippet, stopping the playback etc. together with shortcuts shown in the menu. It is all a bit hacky, but works for me and perhaps also for others It should also be easy to add menu items and keyboard shortcuts for any other commands (like plotting) that work from Lisp. ;; Custom function for previewing Openmusic snippets etc (defun slime-eval-and-preview-opmo-snippet-before-point () "Evaluate the Openmusic snippet (an expression) preceding point and preview that snippet." (interactive) (let* ((score (slime-last-expression)) ;; wrap call to preview-score around the score before point (full-expr (concat "(preview-score (list :snippet " score "))"))) (slime-interactive-eval full-expr))) (defun slime-eval-and-preview-opmo-score-before-point () "Evaluate the score (an expression in the tot score format) preceding point and preview that score (notation and playback)." (interactive) (let* ((score (slime-last-expression)) ;; wrap call to preview-score around the score before point (full-expr (concat "(preview-score " score ")"))) (slime-interactive-eval full-expr))) (defun slime-stop-opmo-playback () "Stop the currently playing Openmusic sound playback." (interactive) (slime-interactive-eval "(sequencer:sequencer-stop *audition-sequencer*)")) (defun slime-opmo-midi-playback () "(Re-)play the last Opusmodus score with a separate MIDI playback window." (interactive) (slime-interactive-eval "(display-midi *last-score* :display :window)")) (add-hook 'lisp-mode-hook (lambda () (local-set-key (kbd "<A-f2>") #'slime-eval-and-preview-opmo-snippet-before-point) (local-set-key (kbd "<A-f3>") #'slime-eval-and-preview-opmo-score-before-point) (local-set-key (kbd "<A-f4>") #'slime-opmo-midi-playback) (local-set-key (kbd "<A-f1>") #'slime-stop-opmo-playback) )) ;; Creating a new "Opusmodus" menu in the menu bar to the right of "Lisp" menu. ;; This new menu is only shown when in lisp-mode (define-key-after lisp-mode-map [menu-bar opusmodus] (cons "Opusmodus" (make-sparse-keymap "hoot hoot")) 'lisp) ;; Creating a menu item, under the menu by the id “[menu-bar opusmodus]” (define-key lisp-mode-map [menu-bar opusmodus preview-score] '("Preview score cmd-f3" . slime-eval-and-preview-opmo-score-before-point)) (define-key lisp-mode-map [menu-bar opusmodus preview-snippet] '("Preview snippet cmd-f2" . slime-eval-and-preview-opmo-snippet-before-point)) (define-key lisp-mode-map [menu-bar opusmodus stop-playback] '("Stop playback cmd-f1" . slime-stop-opmo-playback)) (define-key lisp-mode-map [menu-bar opusmodus replay-score] '("(Re)play last score cmd-f4" . slime-opmo-midi-playback))