torstenanders

> Does this mean gen-controller always returns at most the number of input values? Is that intended behaviour, and if so why? > It is important to make a DEF-SOUND-SET file for your system first. I understand the usefulness for libraries with key-switches etc, but why for a whole DAW? Would you define one for Logic or Cubase as well? > I just tested the Ableton Live and Opusmodus Live Coding system - no problems here, but only on 1 port. It sometimes works for me as well, but sometimes does't, which is a tricky problem. Would like to know if anyone else had that problem. > The :tuning has no timing resolution control. To control the timing you must use :controller keyword. Does that mean so far Opusmodus does not support continuously sending pitchbend messages, only per note onset? What about aftertouch? Thanks! Torsten

If you have Ableton Live, there is a MIDI bottom in the top-right corner. Click that to enter the MIDI map. Then just click on a supported controller in the Live interface and move any MIDI controller to activate a MIDI link. You can edit these in the left-hand list in the MIDI map. Torsten

Did anyone else of you sometimes have problem getting Opusmodus and Ableton Live talk to each other via an IAC bus (on a Mac)? I confirmed that Ableton can receive MIDI notes from other sources on this bus, and that MIDI data from Opusmodus is received by other programs on this bus. Also, the MIDI track indicator shows that the program receives MIDI input from Opusmodus, and just in case in the MIDI track I made sure that all MIDI inputs and channels are received. I also created a new Live set to make sure I did not accidentally do some stupid setting anyway. It worked earlier and strangely it works again after a restart, but I now ran multiple times into the situation that my Ableton tracks gets no notes from Opusmodus, so something seems to be fishy here. Anyone else ran into such problems? Any workaround perhaps? Thanks! Best, Torsten

Actually, in Ableton I can control more params with CC messages via its MIDI map, but it would still be interesting to hear how to control pitchbend and aftertouch. I am aware of the :tuning parameter of DEF-SCORE instruments, but does that support timing information as the :controller argument as well? Thanks! Best, Torsten

Having support for MIDI controller data is great, but is it also possible to send pitchbend and aftertouch? Some Ableton Live instruments need that for more complex control (e.g., Collusion), as otherwise only the Modwheel and no other CC message is supported. Also, I have difficulties understanding what exactly the gen-controller argument span does. Judging from the way the term span is used in the example Controllers 1, I assume this controls the time span the resulting controller movement takes, measured in symbolical note duration, where 1 means a whole note (the term span is used very differently elsewhere, easily causing confusion -- a slightly different argument name would help). So, in effect it should control the length of the resulting list (depending on the set time resolution). However, this is not always the case. What am I missing here? Is there a bug? ;; larger span values result in longer lists, as expected (length (gen-controller 1 (gen-sine 1024 4 1))) ; => 128 (length (gen-controller 2 (gen-sine 1024 4 1))) ; => 256 (length (gen-controller 4 (gen-sine 1024 4 1))) ; => 512 ;; however, for shorter input lists this is not the case length (gen-controller 1 (gen-sine 128 4 1))) ; => 128 (length (gen-controller 4 (gen-sine 128 4 1))) ; => 128 (length (gen-controller 1 (gen-sine 12 4 1))) ; => 12 (length (gen-controller 4 (gen-sine 12 4 1))) ; => 12 Does this mean gen-controller always returns at most the number of input values? Further, how does the span affect the result (if it does so) -- are the values simply looped/cut-off or are they interpolated to stretch/shrink over the specified time span? Thanks a lot! Best, Torsten

> in my view it would be nice to EXTEND the "make-omn/single-events"-structure by x-add-datas... Yes, I was wishing for that as well for some time -- I designed extendable music representations myself for other applications before... However, meanwhile I understand that this is not really possible nor desirable for Opusmodus. The current OMN format is already rather flexible (kind of a language), that already allows for pretty much arbitrary symbols as articulations, and articulation combinations (as single symbol joined with +). Allowing for an arbitrary number of symbols as articulations or other data would make parsing (detecting note boundaries) much harder, or would require that OMN would do what many other music representations out there are doing: that individual notes are represented as separate data elements (e.g., separate lists, as output by single-events). Such a representation would be less concise -- you would less want to directly type it by hand anymore. Either approach to extensions would also break very many existing functions. The good news is that by merging multiple articulations in a single articulation symbol you do not need to break the existing functionality, and can still have all the extensibility you need. The only restrictions are that an articulation is always a symbol that has been declared as such before (e.g., numerical data is a bit tricky here, yes). Beyond that, nothing stops you from rolling you own music representation in whatever format you want, but you may want then to always have two additional functions that transform your format into the OMN format and back :) > b) in my way i see completely transparent and easy what's up, and not a mixture of text-attributes/data...? Multiple articulations combined in a single symbol are well readable, I would say -- something that cannot always be said of, say, object-oriented data abstractions of other algorithmic composition systems. I would argue that together with functions such as merge-articulations and disassemble-articulations that I defined above, you can see this as a data abstraction [1], which is extendable. > c) if I could change the OPMO SINGLE-EVENTS-structure, i would extend it like I did ...and not mixing it, isnt' it much more "logic" (but perhaps not for a programmer-brain :-)) In principle there is not really much of a difference between these two positions here, it is up to you to decide. The main downside of your custom format is that you loose all direct interoperability with OMN functions and functionality (e.g., snippet preview), but occasionally the advantages will be outweighing such downsides. In this particular case the only advantage of your approach that I see is that you can (more easily) add numerical data. > a) isn't it better to "seperate" the BASIC-OMN-structure from the additionals? in a way, i'm more independet if OPMO changes some things? That is better answered by Janusz. Best, Torsten [1] https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-13.html#%_chap_2, chapter in Abelson, H. et al. (1985) Structure and Interpretation of Computer Programs. Cambridge, MA: MIT Press; a book that is extremely useful for every Lisp programmer, though it uses the Lisp dialect Scheme.

> You might find the function OMN-RECONSTRUCT useful in your work: Thanks! As always, would be great to have this documented so that users can find this on their own :) More generally, are their some reasons to prefer length symbols beyond their conciseness? Fractions are often more easy to comprehend for me, but I guess this is just a question of time... Best, Torsten

Here is a revision (defun make-corresponding-rest (event) "Turns a single OMN note into a rest of the same note value. Rests remain rests, and rest articulations are preserved. Example: (make-corresponding-rest '(h c4))" (let ((len (omn-encode (first event)))) (cons ;; rests should remain rests (if (> len 0) (* len -1) len) (omn :rest-articulation event)))) (defun insert-articulation (flat-omn-list &rest articulations) "Merge in one or more lists of articulations to an OMN expression. Example: ;; added nil for the rest (extended-single-events '(e c4 mp arco e. d4 -h e. p pizz e e4 arco) '(ponte tasto nil ponte tasto)) => (e c4 mp arco+ponte e. d4 mp tasto -h e. d4 p pizz+ponte e e4 p arco+tasto) BUG: does not skip rests. Wait for omn-replace supports composite articulations to fix" (apply #'append (loop for event in (single-events flat-omn-list) for data in (matrix-transpose optional-data) when (length-notep (first event)) collect (let ((event-art (fourth event))) (append (subseq event 0 3) (list (merge-articulations (if event-art (cons event-art data) data))))) else collect event))) #| ;; automatic orchestration application (add-text-attributes '(trp "trp") '(fl "fl") '(clar "clar")) (extended-single-events '(e c4 mp stacc e. d4 -h e. c4 p ord e e4 stacc) '(trp fl trp trp fl clar) '(flt tr1 tr2 flt tr1 tr2)) ; => '(e c4 mp stacc+trp+flt e. d4 mp fl+tr1 -h e. c4 p ord+trp+flt e e4 p stacc+fl+tr1) |# (defun filter-note-parameters (flat-omn-list parameter &key (remove-non-matching? nil)) "Checks every note whether it contains `parameter'. All notes containing the parameter are preserved, all other notes are turned into rests. If a note contains a combination of articulations, all of them are checked. Args: flat-omn-list: flat OMN list parameter: a length, pitch, OMN velocity or single articulation remove-rests? (default nil): if true, all notes that do not match are removed instead of turned into rests. Examples: (filter-note-parameters '(e c4 mp arco+ponte e. d4 mp tasto -h e. c4 p pizz+ponte e e4 p arco+tasto) 'e.) => (-1/8 e. d4 mp tasto -1/2 e. c4 p pizz+ponte -1/8) (filter-note-parameters '(e c4 mp arco+ponte e. d4 mp tasto -h e. c4 p pizz+ponte e e4 p arco+tasto) 'arco) => (e c4 mp arco+ponte -3/16 -1/2 -3/16 e e4 p arco+tasto) (filter-note-parameters '(e c4 mp arco+ponte e. d4 mp tasto -h e. c4 p pizz+ponte e e4 p arco+tasto) 'arco :remove-non-matching? T) => (e c4 mp arco+ponte e e4 p arco+tasto) " (remove :not-matching (apply #'append (loop for event in (single-events flat-omn-list) when (and (length-notep (first event)) (member (omn-encode parameter) (append (list (omn-encode (first event))) (subseq event 1 3) (disassemble-articulations (fourth event))))) collect event else collect (if remove-non-matching? '(:not-matching) (make-corresponding-rest event)))))) #| ;; continue automatic orchestration application (filter-note-parameters '(e c4 mp stacc+trp+flt e. d4 mp fl+tr1 -h e. c4 p ord+trp+flt e e4 p stacc+fl+tr1) 'trp) ; => (e c4 mp stacc+trp+flt -3/16 -1/2 e. c4 p ord+trp+flt -1/8) (filter-note-parameters '(e c4 mp stacc+trp+flt e. d4 mp fl+tr1 -h e. c4 p ord+trp+flt e e4 p stacc+fl+tr1) 'e.) |#

Feel free to roll your own OMN extensions, if that benefits you, but in this case I don't think that is necessary. It is one of the strength of Opusmodus, that it has a rather simple music representation that is used by so many functions, because that allows you to combine them all. Once you roll your own data you cannot apply other OMN functions anymore to that data. Put differently "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures." (Alan Perlis -- you can search the web for that quote, lots of discussion there :) OK, I suggest you slightly change your functions such that all your data is wrapped up in a single articulation symbol. This function can handle an arbitrary number of additional data streams to merge into your OMN list. Also, I kept it a flat list, as you do not mean to have bars here. (extended-single-events '(e c4 mp stacc e. -h e. p ord e e4 stacc) '(trp fl trp trp fl clar) '(flt tr1 tr2 flt tr1 tr2)) ; => '(e c4 mp stacc+trp+flt e. c4 mp fl+tr1 -h e. c4 p ord+trp+flt e e4 p stacc+fl+tr1) If you declare all your data first as text attributes, then you can even show it in a score (add-text-attributes '(trp "trp") '(fl "fl") '(clar "clar")) Now lets do the filtering you suggest. I changed your keyword argument into a standard argument, because that argument is always required. Keyword arguments are best suited for optional arguments that document themselves. Also, the result is again a flat list. After declaring your attributes you can directly notate it :) (filter-events-by '(e c4 mp stacc+trp+flt e. c4 mp fl+tr1 -h e. c4 p ord+trp+flt e e4 p stacc+fl+tr1) 'trp) ; => (e c4 mp stacc+trp+flt e. -h e. c4 p ord+trp+flt e) With a slight change of the function below you could also turn all notes that do not meet your test condition into a rest. The function definitions are below. BTW: your function memberp does pretty much what the function member already does and is therefore not needed, because in Lisp any value that is not nil is considered meaning true. Best, Torsten (add-text-attributes '(trp "trp") '(fl "fl") '(clar "clar") ) (defun extended-single-events (flat-omn-list &rest optional-data) (apply #'append (loop for event in (single-events flat-omn-list) for data in (matrix-transpose optional-data) when (length-notep (first event)) collect (let ((event-art (fourth event))) ; (format t "event: ~A, data: ~A, event-art: ~A~%" event data event-art) (append (subseq event 0 3) (list (merge-articulations (if event-art (cons event-art data) data))))) else collect event))) #| ; test (extended-single-events '(e c4 mp stacc e. -h e. p ord e e4 stacc) '(trp fl trp trp fl clar) '(flt tr1 tr2 flt tr1 tr2)) ; => '(e c4 mp stacc+trp+flt e. c4 mp fl+tr1 -h e. c4 p ord+trp+flt e e4 p stacc+fl+tr1) |# (defun filter-events-by (flat-omn-list value) (apply #'append (loop for event in (single-events flat-omn-list) when (and (length-notep (first event)) (member value (append (subseq event 0 3) (disassemble-articulations (fourth event))))) collect event else collect (list (first event))))) #| ; test (filter-events-by '(e c4 mp stacc+trp+flt e. c4 mp fl+tr1 -h e. c4 p ord+trp+flt e e4 p stacc+fl+tr1) 'trp) ; => (e c4 mp stacc+trp+flt e. -h e. c4 p ord+trp+flt e) |# (defun merge-articulations (arts &key (empty-articulations '(default -))) "Merges list of OMN articulations to a combined attribute. Args: arts: a list of OMN articulations empty-attributes: articulations to ignore in a combination. Examples: (merge-articulations '(ten ponte ubow)) => ten+ponte+ubow (merge-articulations '(- stacc)) => stacc (merge-articulations '(default default)) " (intern (reduce #'(lambda (a1 a2) (format nil "~A+~A" a1 a2)) (let ((interm-result (mappend #'(lambda (art) (unless (some #'(lambda (a) (eq art a)) empty-articulations) (list (symbol-name art)))) arts))) (if interm-result interm-result (list (symbol-name (first empty-articulations)))))))) (defun disassemble-articulations (art) "Splits a combined OMN articulations into a list of its individual attributes. Example: (disassemble-articulations 'leg+ponte) => (leg ponte)" (mapcar #'intern (split-string (symbol-name art) :separator "+")))

To briefly follow up: support of multiple sound libraries for a single instrument by def-score would be preferable over an extended definitions with def-sound-set, because then individual def-sound-set definitions are independent and clean (even sharable, as Stephane did for EWQLSO), and details like the MIDI channel and port remain in the def-score definition. Thanks! Best, Torsten added 2 minutes later BTW: the Xsample library requires so many key-switches, that they layered them in multiple velocity zones. Would that be something def-sound-set should support? Best, Torsten

could you give me an example (input, output) of what you are trying to do. Why would you like to use separate channel for each of the articulations. What samples (virtual instrument) you are using. I would like to use multiple orchestral sound libraries that support different articulations in parallel for "preview mock-ups". For example, one library with standard articulations (e.g., EWQLSO) and one for extended techniques that I am considering to buy (e.g., IRCAM Solo Instruments, https://s3.amazonaws.com/uvi/SCP01-Ircam+Solo+Instruments/ISI_manual.pdf, or Xsample Acoustic Instruments Library, http://www.xsample.de/index_htm_files/Xsample_Library_en.pdf). So far, I used custom Kontakt instruments of extended techniques for the latter. Gilreath (2010) also recommends to combine libraries for adding variety etc. My above-mentioned function would be a workaround to realise such playback, but at the cost of additional explicit staffs in the notation output, so some built-in support for multiple libraries in def-sound-set or a support for specifying multiple libraries for a single instrument in def-score output to different MIDI channels/ports would be welcome! Best, Torsten Gilreath, P. (2010) The Guide to MIDI Orchestration. 4th revised edition. Focal Press.

If optionally it would be possible in def-sound-set to specify MIDI channels and ports and/or specifying that as an articulation for individual notes that would be great. Best, Torsten

Dear Alain Jamot, here is a function that may help you. This function is useful for customising sound playback with multiple sound libraries or for algorithmic orchestration. The function expects an OMN expression and returns a list of multiple OMN sequences (multiple parts). It basically sorts notes from the OMN sequence into different parts, depending on the articulations of individual notes. All notes with certain articulations go in one resulting parts, and notes with other articulations in another part. Here is an example. It sorts all notes with pizz or arco articulations into one part, and notes with trem articulations into another part. Each time, notes are substituted by rests in other parts, so that timing relations of notes in different parts are preserved. (separate-parts '((h c4 pizz q arco) (h trem q h pizz) (h arco+stacc -q fermata)) '((pizz arco) (trem))) => (; part 1: pizz and arco ((h c4 mf pizz q arco) (-h q c4 mf h pizz) (h c4 mf arco+stacc -q fermata)) ; part 2: trem ((-h -q) (h c4 mf trem -q -h) (-h -q fermata))) You can then assign your first part to on MIDI channel in your def-score call, and the next part to another MIDI channel, e.g., like so. (setf omn-expr '((h c4 pizz q arco) (h trem q h pizz) (h arco+stacc -q fermata))) (setf parts (separate-parts omn-expr '((pizz arco) (trem)))) (def-score two-violins (:title "Title" :composer "Composer" :copyright "Copyright © " :key-signature 'chromatic :time-signature '((1 1 1 1) 4) :tempo 100 :layout (bracket-group (violin1-layout 'violin1) (violin2-layout 'violin2))) (violin1 :omn (nth 0 parts) :channel 1 :sound 'gm :program 'violin :volume 100 :pan 54 :controllers (91 '(48)) ) (violin2 :omn (nth 1 parts) :channel 2 :sound 'gm :program 'violin :volume 100 :pan 74 :controllers (91 '(60)) ) ) The function definition of separate-parts is below. Best, Torsten Janusz: This is another example of a function showing how processing polyphonic music with double-nested OMN expressions can be useful. Once we have a standard notation for polyphonic OMN expressions with multiple voices/parts in Opusmodus 2, as discussed earlier, then this function can easily be adapted to output that format. (labels ((make-corresponding-rest (event) (let ((len (omn-encode (first event)))) (cons ;; rests should remain rests (if (> len 0) (* len -1) len) (omn :rest-articulation event)))) (push-event-and-rests (event matching-position result-omns articulation-sets-length) (push event (nth matching-position result-omns)) (loop for i in (remove matching-position (gen-integer 0 (1- articulation-sets-length))) do (push (make-corresponding-rest event) (nth i result-omns))))) (defun separate-parts (sequence articulation-sets) "The function `separate-parts' is useful for customising your sound playback with multiple sound libraries or for algorithmic orchestration. The function breaks an OMN sequence (a single part) into a list of multiple OMN sequences (multiple parts). It basically sorts notes from the OMN sequence into different parts, depending on the articulations of individual notes. All notes with certain articulations go in one resulting parts, and notes with other articulations in another part. In all other resulting parts, notes are substituted by rests, so that timing relations of notes in different parts are preserved. This function can be useful, when you have multiple sound libraries that support different articulations of the same instrument. You can then perform notes with certain articulations on one software instrument (on its own MIDI channel etc.), and notes with other articulations on another instrument. Alternatively, you can use the function for algorithmic orchestration, where you assign custom articulations (typically declared with add-text-attributes first) such as instrument labels with your custom algorithm, and then use this function in a second step to separate your instruments. Remember that the result of this function is a list of multiple OMN sequences (multiple parts). You have to split it into its individual parts for use in OMN. Args: - sequence: OMN sequence, can be nested - articulation-sets: list of list of articulations. All notes with articulations contained in the first articulation-set end up in the first resulting part, notes with articulations in the second set end up in the second part and so forth. The decision which part a note belongs to is always made based on the first articulation that matches an articulation-set. If a note contains no articulation, or an articulation contained in no set, then it is matched to the first articulation-set. If an articulation is contained in multiple articulation-sets, then the earlier match in articulation-sets is used. Examples: (separate-parts '(h c4 pizz q arco) '((pizz) (arco))) => ((h c4 mf pizz -q) ; part 1 with pizz articulations (-h q c4 mf arco)) ; part 2 with arco (separate-parts '((h c4 pizz q arco) (h trem q h pizz) (h arco+stacc -q fermata)) '((pizz arco) (trem))) => (((h c4 mf pizz q arco) (-h q c4 mf h pizz) (h c4 mf arco+stacc -q fermata)) ; part 1: pizz and arco ((-h -q) (h c4 mf trem -q -h) (-h -q fermata))) ; part 2: trem " (if (listp (first sequence)) ;; sequence is nested (matrix-transpose (mapcar #'(lambda (seq) (separate-parts seq articulation-sets)) sequence)) ;; sequence is flat list (let* ((articulation-sets-length (length articulation-sets)) (result-omns (make-list articulation-sets-length :initial-element nil))) (loop for event in (single-events sequence) do (let ((event-articulation (fourth event))) (if event-articulation (let ((matching-position (position-if #'(lambda (articulation-set) (some #'(lambda (art) (member art (disassemble-articulations event-articulation))) articulation-set)) articulation-sets))) (if matching-position (push-event-and-rests event matching-position result-omns articulation-sets-length) ;; if no match, then add event to first omn result (push-event-and-rests event 0 result-omns articulation-sets-length))) ;; if no articulation, then add event to first omn result (push-event-and-rests event 0 result-omns articulation-sets-length)))) (mapcar #'(lambda (result) (flatten-omn (reverse result))) result-omns))))) ;; for your convenience, I include the following definition already shared earlier (defun disassemble-articulations (art) "Splits a combined OMN articulations into a list of its individual attributes. Example: (disassemble-articulations 'leg+ponte) => (leg ponte)" (mapcar #'intern (split-string (symbol-name art) :separator "+")))

As you likely already know, what you can do in a single voice/part is specifying various articulations, which can result in different timbres of your playback, including user-defined specifications with the function def-sound-set. Beyond that, you could split your part into multiple parts, in the score, where each is performed by its own MIDI channel (basically reproducing how a Klangfarbenmelodie would be realised in an orchestra setting). The advantage of expressing different timbres of different instruments with multiple parts is that it allows for dove-tailing, where the last note of one instrument and the first note of the next are shared by both for a better connecting. Anyway, if you want to generate only a single part with timbre specifications, why not defining a function that allows to split it into multiple parts for the orchestra later. I proposed such a function for your convenience at Best, Torsten

Great, thanks! Would you consider adding a documentation file for that function? If not, could you at least add a doc string to the code, so that it could be of use for at least more advanced users? For everyone else: when you are searching for a function that is not documented by its own RTF file and thus cannot be found via the standard Opusmodus documentation search, you could use the following function. Some internal Opusmodus functions without standard Opusmodus documentation have at least a documentation string. ;; return all functions that contain 'omn' in their name, together with their documentation string (if there is any). (apropos-function-documentation "omn") The function apropos-function-documentation is defined below. Best, Torsten (defun apropos-function-documentation (my-string &optional (package *package*)) "Lists all functions that contain `my-string' alongside their documentation in a list of pairs (<function-symbol> <doc-string>)" (mapcar #'(lambda (x) (list x (documentation x 'function))) (remove-if-not #'fboundp (apropos-list my-string package))))