Jump to content

torstenanders

Members
  • Content Count

    439
  • Joined

  • Last visited

Posts posted by torstenanders

  1. It looks like conTimbre would be a considerably larger collection of articulations and also better documented (e.g., I guess if you play a certain multiphonic  you are able to learn how it was produced or vice versa, which is not the case with the IRCAM Solo Instruments), but its playability as a plugin from Opusmodus or a DAW seems to be less developed. In case you played already with it: how well does the latter work, now that they have support for VST and AU plugins? 

  2. Update:  

     

          It seems the samples are the same as in version 1 (which are now > 10 years old and with the
          original problems like rel. few samples i.e. few velocity layers or no round robins to avoid
          machine gun effect and all very closely miked), but now the scripting and instrument is much
          improved, e.g., with legato phrasing now supported, streching/shrinking notes like
          transitions, a timbre control (e.g., could be used for avoiding the machine gun effect).
          However, reviews report that these new scripts are not perfect, e.g., key switches can result
          the occasional glitch.

     

          How does conTimbre compare with that, i.e., how well is their current playback incl. switches
          between techniques and ideally also expressive playing from Opusmodus or a DAW working

          (i.e. when used as an AU or VST pluging)?

     

  3. I would very much appreciate some feedback, but I am already almost decided to get it in any case. 😊

     

    We might perhaps work on an Opusmodus sound set together. I will only use a few instruments (currently I just need the cello), but would like to make a wide range of techniques available in Opusmodus. However, instrument key-switches etc. hopefully share patterns, so once one instrument is reasonably covered it should be possible to scale that at least for the other instruments in the same family. 

     

    One problem might be that they keep standard (what they call classic) and extended techniques in separate key-switch groups (and even subgroups), so one might need multiple sampler instruments on different MIDI channels to cover a single acoustic instrument. Not sure whether it would be necessary in Opusmodus then also to have different instruments. I guess currently that would be necessary, as currently AFAIK in Opusmodus a single instrument can only be allocated to a single MIDI channel (different articulations cannot be assigned to different MIDI channels, at least not yet).

     

    If there are other ideas how the multiple key-switch groups could be merged into a single Opusmodus instruments, I would be all ears. 🙂 

  4. Hi guys,

     

    Did anyone of you already look into the rather new IRCAM Solo Instruments 2 by UVI? That might be nice to control from within Opusmodus with its wide range of extended techniques available. From what I can tell from the videos, this seems to be a clear improvement over the former version and also conTimbre in terms of sounds and playability. Anyone already tried it?

     

    351.jpg
    WWW.UVI.NET

    16 instruments, 550+ playing techniques, experience unparalleled depth and detail with classical and avant-garde articulations recorded at IRCAM Labs

     

     

    Some videos that give some impression: 

    https://www.youtube.com/watch?v=AFNzya5iOUc&vl=en
    https://www.youtube.com/watch?v=ugMPNtWtLvk
     

    Some review:

    https://soundbytesmag.net/review-ircam-solo-instruments-2-from-uvi/

  5. BTW: Common Lisp has built-in tracing mechanisms, which happen to be more fine-grained and work automatically without any need to sprinkle explicit function calls like do-verbose in any definition at all.

     

    For example, there is the builtin trace:  

     

    In case of an error (and only in case of an error), a full stack trace is usually automatically printed. This happens to be disabled in the standard Opusmodus editor, but works as normally in Common Lisp when using the Emacs Slime interface. For example, consider the following code.

     

    (defun function-causing-error (x)
      (/ x 0))
    
    (defun test (x)
      (function-causing-error x))
    
    (test 1)

     

    When I evaluate the code above in Slime, I get not only a stack trace showing which function called which, I can also get interactively further information on the function calls, like looking at which arguments they were called. Best of all, I can evaluate arbitrary code for testing in the context of any function of the stack trace, where all its local variations are bound, which can be very helpful for debugging.

     

    Here is a screenshot of the stack trace I get. You can see that the function test (frame 3 -- the leading number in the trace) calls the function function-causing-error (frame 4) which just a few frames up causes the error DIVISION-BY-ZERO.

     

    293775498_ScreenShot2020-11-19at19_06_45.png.6ad110cb6e16a5c8c39ee43e790b1379.png

     

    Now, in this case the error is rather obviously, but in case you have some local variables in the function that might contain a bug, it would be useful to be able to look at these. Indeed, you can. Just click on any frame, and all local variables are shown. Here it is simply the argument x, which we already know, as arguments are shown in the stack trace as well.

     

    84399631_ScreenShot2020-11-19at19_12_06.png.cd267adc3ad4e5a4d39f95a7738ab09c.png

     

     

    Now, sometimes just seeing the local variables is not enough, you want to play with them a bit. Again, you can do that. Move the cursor into/on the frame, press the shortcut e (for evaluate), and you are prompted to enter an arbitrary expression that is executed in the context of this frame (e.g, can use the local variable x). I cannot easily show this in a screenshot and would instead need to do a little video. Let me know if the explanation so far is not sufficient. 🙂

     

    Best,

    Torsten

     

     

  6. 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 

    LISPCOOKBOOK.GITHUB.IO

    A collection of examples of using Common Lisp

     

  7. 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...

  8. 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))

     

  9. 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? 

  10. 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 🙂 

  11. 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.  

  12. 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! 

  13. 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

     

  14. 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.  

     

  15. 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?
       
  16. 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 🙂 

  17. 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 #()>)

     

  18. 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! 

  19. 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 😊

  20. 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...

  21. 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)

×
×
  • Create New...

Important Information

Terms of Use Privacy Policy