Jump to content

torstenanders

Members
  • Posts

    489
  • Joined

  • Last visited

Everything posted by torstenanders

  1. 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.
  2. 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!
  3. 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
  4. Yes, I understood that, and for a mere preview this is good enough (e.g., no nested layouts needed).
  5. 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.
  6. 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?
  7. 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
  8. 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 #()>)
  9. 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!
  10. 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
  11. 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...
  12. 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)
  13. > 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
  14. 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))
  15. > 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
  16. 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...
  17. 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))
  18. Brilliant, this is exactly the missing function I described And such a lightening-fast response too! Thank you very much indeed! Torsten
  19. Hi, Is there perhaps a way to adjust the overall duration of a nested (barred) OMN sequence? In particular, is there a function to cut notes etc. at the beginning/end of a sequence, so that the result has a specified overall duration? The first example just demonstrates what I would like to have. (setf phrase '((1/2 c4 1/4 d4) (1/4 e4 1/2 c4))) ;; Edit phrase such that the result is exactly 5/4 long by preserving the nesting structure (function-I-am-looking-for 5/4 phrase) ; => ((h c4 q d4) (q e4 c4)) ; cut material at end ; => ((q c4 q d4) (q e4 h c4)) ; cut material at beginning There already exist at least two functions that are close, but not quite what I need. ;; Does not keep nesting structure (length-span 5/4 phrase) ; => (h c4 q d4 e4 c4) ;; Adjusts individual sublists (length-adjust 5/4 phrase) ; => ((h c4 q d4 -h) (q e4 h c4 -)) Is there perhaps also a function that does what my example function-I-am-looking-for above does? Thanks a lot! Best, Torsten
  20. If your goal is for you as a teacher to create documents for your students to read containing Common Lisp and Opusmodus code, and where you want to evaluate the code directly from within that document, then Org mode with embedded Common Lisp + Slime is your friend. This is a very powerful combination, that can automatically create nice slides (with the LaTeX beamer interface), embed music notation (Lilypond) etc. I used this combination for years for teaching, had then all sessions of a course in a single document for easily moving content around etc. Nevertheless, you likely do not want to introduce your students to use Org mode... For that, Jupyter notebooks (or plain Opusmodus) will be more easy for the students. Org mode for Emacs – Your Life in Plain Text ORGMODE.ORG Org: an Emacs Mode for Notes, Planning, and Authoring Babel: active code in Org-mode ORGMODE.ORG However, I don't know of a way to automatically embed music notation output of Opusmodus in Emacs Org mode. What is missing for that, AFAIK, is some Opusmodus function that automatically creates a graphic file for a given snippet or score. If that would be there, that feature shouldn't be too hard to add (other Org mode babel programming language interfaces do already similar things, e.g., Lilypond, and the code for that is freely available).
  21. Are these sessions somehow recorded for a record perhaps?
  22. The best document combining both worlds is likely the following. This was an internal textbook of the algorithmic composition teacher Paul Berg at the Sonology course at the Royal Conservatory of The Hague (the author of the composition system AC Toolbox, https://www.actoolbox.net), but it is unprinted, just a copy of a text processor document for internal use, and difficult to obtain (I only have a hard copy I got from a friend). Berg, Paul (n.d.) Elements of Design. An introduction to Programming with Common Lisp.
  23. http://www.gigamonkeys.com/book/ Common Lisp Books | Common Lisp LISP-LANG.ORG Books about Common Lisp For a more music-related introduction to Common Lisp you might want to look at the following books. These books teach algorithmic composition with Common Lisp. The above books introducing only Common Lisp are far more comprehensive on that matter, but you might prefer learning some foundations first within a musical context. Morgan, N. & Legard, P. (2015) Parametric Composition: Computer-Assisted Strategies for Human Performance. West Yorkshire, UK: Tonality Systems Press. Sorry! Something went wrong! WWW.AMAZON.COM Introduces Opusmodus along with some Lisp. Taube, H. (2004) Notes from the Metalevel. London and New York: Taylor & Francis. Sorry! Something went wrong! WWW.AMAZON.COM Code examples online: http://www.moz.ac.at/sem/lehre/lib/cm/Notes from the Metalevel/00/contents.html This book introduces the algorithmic composition system Common Music, along with Lisp fundamentals. Algorithmic Composition: A Gentle Introduction to Music Composition Using Common LISP and Common Music https://quod.lib.umich.edu/s/spobooks/bbv9810.0001.001/1:3/--algorithmic-composition-a-gentle-introduction-to-music?rgn=div1;view=fulltext I have not read this one...
×
×
  • Create New...

Important Information

Terms of Use Privacy Policy