torstenanders

>> While I can create a canon, counterpoint and a fugue myself with a bit of time, it would be much less time-consuming for me if I were able to use existing examples. Is there an existing library of OMN examples of these types of compositions? > I cannot offer ready-made examples, but a constraint-based library with various counterpoint (and also harmony) rules ready-made. Following up my own comments, some entry level introduction to the libraries Cluster Engine and Cluster rules is offered by a video I prepared for my students last autumn. https://www.youtube.com/watch?v=xPXIRmH9rZc&list=PLmbpscTxjn_DrdDXD5v7z0GzQRNKM5VyQ&index=9 This video uses PWGL instead of Openmusic, but you only need to mentally replace PWGL boxes with Lisp functions of the same name to get pretty much the equivalent Opusmusic code. Also, this tutorial only scratches the surface of what can be done with these libraries, but I hope it can give an initial idea how things are approached in these libraries and for going beyond that a relatively easy approach is simply to study the pre-programmed rules in the Cluster Rules library and trying to combine rules for your own purposes. Once you miss a specific rule you would like to have, the library Cluster Engine provides the tools for defining your own rules on a high level of abstraction (specifically, it provides many abstractions that help to easily apply your rule to a specific score context, like the pitches of simultaneous notes of certain parts). This video is the last of a series of introduction-level videos on algorithmic composition with PWGL... https://www.youtube.com/playlist?list=PLmbpscTxjn_DrdDXD5v7z0GzQRNKM5VyQ

Brilliant. Now my most-used Opusmodus shortcuts also work in Emacs. That helps my workflow a lot! Thanks!! Could you perhaps also share some example of one of the Opusmodus keyboard shortcut definitions (e.g., something like OMN Audition). Then I could hopefully use that to define a shortcut for starting playback with my custom score data structure in Opusmodus. It does not matter if that example definition would be complex and you do not need to provide any user-friendly abstraction. Just some example code would help a lot. Thanks again! Best, Torsten

Thanks, but what is the Lisp function, not the shortcut, for stopping playback. I can start playback of the last score with (audition-last-score), how can I stop it Thanks! Best, Torsten

What is the Lisp function for stopping playback (bound to the shortcut cmd-esc)? ... I could never add a custom keyboard shortcut to the Opusmodus text editor Hemlock (and I tried), but I just managed adding keyboard shortcuts and a menu for playing Opusmodus snippets and my polyphonic score format to Emacs (thanks to the fact that scores now can be displayed in a separate window). Only need some key for stopping playback as well. (The main thing I will then miss when using Emacs as the Opusmodus IDE is the close integration of the document, but well, you cannot have everything On the plus side, I have a more stable editor and in particular a very good debugger.) Thanks! Torsten

>> Common Music does not "see" CLM and the interface to it is broken, because CLM is now seemingly defined in another package. > It looks like you don't know how to use CLM in Opusmodus I understand that CLM can be used directly from Opusmodus, but there also exists an interface between Common Music and CLM (I used that already in the 90s...), which is broken in the CLM port to Opusmodus when loading Common Music into it was well. Anyway, I doubt anyone with miss that Best, Torsten

Do you mean as an option for the function length-divide? That would be great, but my preferred solution would be to have some extra function complementing gen-swallow for added notes -- which then could be called within functions like length-divide -- because that would be a generic solution for all sorts of functions that somehow add notes. The slightly tricky bit would perhaps be for the function to notice which are the new notes, so it should likely get as an input both the original material and the material with the added notes to find out... I would be happy to help sketching such a function... One approach might also be if functions adding notes would somehow mark such notes with some custom articulation only used for that purpose, but that would only work for full OMN results, not single parameters (e.g., length-divide supports single length values). An alternative idea would be for functions adding notes to simply specify the positions in the resulting list that they added (with some special notation for nested lists). Anyway, if it would be much more simply to refactor only length-divide and friends, that would be welcome too...

The function LENGTH-DIVIDE and friends are a useful device for introducing some rhythmic variation to some material. However, when the processed sequence is a full OMN expression (see example below), then the added notes cause all other parameters to shift forward (additional parameters are added at the end by looping). For introducing only a slight variation to some existing material (e.g., motif) these functions are therefore not so useful, because this shift of all parameters to basically "fill" the new added notes with pitches etc. greatly change the varied material for a listener. (length-divide 1 2 '(q f3 leg+m1 q ab3 leg e c4 leg bb3 leg ab3 leg g3)) Basically, this is the opposite situation of the situation addressed by swallowing. Swallowing (e.g., with GEN-SWALLOW and the swallow argument of many other functions) avoids the shift of parameters like pitch etc. that would result from removing notes and turning them into rests. For addressing the situation above properly we would need something like the opposite of swallowing, some way to fill in parameters like pitch etc. for new notes to avoid shifting existing notes. I hope my explanation makes sense and you can see why something like the opposite of swallowing would be useful for functions that add notes to some input material. Now, the tricky question is of course, what parameters (pitch etc.) should be added in such cases. Musically useful and common in the classical literature would be, e.g., repeating the parameters (pitch etc.) of the predecessor note (though that might be a bit too simplistic and annoying at times) or somehow interpolating some pitch gap between the previous and next note with a little scale or arpeggio and only repeating the other parameters like articulations (resulting in some variation that is likely most similar to the input material, so it would be good to have that as an option). If the pitch interval between the two original notes is too small to add some pitch in between for the new now (or as an option in general for variety), it would also be good to add some ornamentation (e.g., using PITCH-ORNAMENT), but for a close similarity between the original material and the variation it would be best as an option to apply such ornamentation only to the newly added notes, not all notes. Of course, other options could also be useful for variations that vary the input material a bit more strongly, e.g., some random pitch for the new notes within certain interval bounds. Does some function that kind of is the opposite of GEN-SWALLOW in that it adds parameters like pitches for subdivided rhythmic values (to avoid the shifting) sound like a good idea? The idea with the interpolation of gaps could be implemented by turning the original duration values and pitches into some envelope and then reading that envelope with the new rhythmic values. So, that is rather strait forward. However, that would not allow for some ornamentation, because such algorithm would not recognise which notes are new that should be ornamented. Any other idea perhaps? Thanks!

Thank you very much indeed! Torsten

Thanks for coming back. Here is a little demo example snippet. This example shows a very simple motif and its repetition. I would like to annotate some motif label (I will use such labels also for segmenting parts for further processing -- that works fine). (add-text-attributes ;; motif start signs '(m1 "m1") '(m2 "m2") '(m3 "m3") '(m4 "m4") '(m5 "m5") '(m6 "m6") '(m7 "m7") '(m8 "m8") '(m9 "m9") '(m10 "m10") ) '(q c4 m1+leg d4 q c4 m1+leg d4) By contrast, the attribute num1 behaves differently. '(q c4 num1+leg d4 q c4 num1+leg d4) I would like to be able to define custom text-attributes that behave like num1 and friends. Thanks again! (If I am the only one who wants such a feature this does not need to have high priority :)

Thank you for coming back. Of course, different approaches and workflows are possible, but these tend to influence what kind of musical results we are getting (e.g., certain approaches and workflows make certain musical results more easy to achieve, and therefore ending up generating these is more likely). Specifically, the functions you mention (and most of the Opusmodus functions in general) are designed for processing the part of a single instrument, and individually generated parts are then almost always combined into a polyphonic score only in a rather late or a final step. Composing in this order (creating individual parts separately and combining them into a score only rather late) is currently easier, because most functions work that way, and most examples are using that approach. Instead, I would prefer to work with polyphonic combinations of multiple parts from early on in the composition process. To state a conventional example, when composing something like a sentence or period theme, I would like to be able to vary and then string together polyphonic phrases. And that is only the lowest hierarchic level, of course such a way of working can be used on higher levels too. Or when creating more complex textures, I might generate them by superimposing multiple phrases that are already polyphonic and for multiple instruments in themselves. As a composer, I find it rather natural to use building blocks that already consist of multiple parts for multiple instruments, and then transform such building blocks in various ways for creating variations. Anyway, I can already do that with my music representation discussed above, I only would find it more convenient to see intermediate results with a mere shortcut. I guess at some stage we might have support for user-defined keyboard shortcuts, and then I can define one for myself for notating and auditioning intermediate results that are polyphonic score representation with explicitly annotated parts. In the meantime, I just explicitly call my function preview-score, not too much of a deal

Some attributes are sticky (they do not need to be repeated to maintain being set, and when they are repeated they are not shown again in the score) -- while others are not. For example, the articulation pizz is sticky, while stacc is not. It seems that add-text-attributes declares only sticky attributes. Is it perhaps possible to also have custom non-sticky attributes? For example, want to annotate certain motif or phrase names, and if I repeat the same motif the text label is not shown again. Just in case this is already possible... Thank you! Best, Torsten

I am trying to clarify my point by adding an example. With the new multi-voice snippet previews we can now do arbitrary processing of polyphonic score snippets. In the code below, some short polyphonic snippet is transposed, but different parts are transposed differently. With this approach, arbitrary Opusmodus functions defined for single parts can be used for processing full polyphonic score snippets on one go, and arbitrary combinations of arguments for such Opusmodus functions can be provided. The trick is to include some special symbol (_) for marking the position of the actual part in the argument list (as different functions expect an OMN sequence at different argument positions), and then in the loop to replace that symbol with the part itself. (setf poly-snippet-1 '(((q g4) (q. c5 e d5 q e5 f5) (h. e5)) ((q g3) (q c4 b3 a3 g3) (h. c3)))) (loop for part in poly-snippet-1 for args in '((2 _) (7 _)) collect (apply #'pitch-transpose (substitute part '_ args))) Side note: #'pitch-transpose is the function pitch-transpose (instead of a variable named that way). The function apply takes such a function as a first argument and its arguments as a second argument and calls that function. It is somewhat similar to using eval (in case you came across that before), but apply (or its cousin funcall) is preferable in almost all cases over eval (if you are interested in the details, see the link below, interestingly labelled Why exactly is eval evil?: Why exactly is eval evil? STACKOVERFLOW.COM I know that Lisp and Scheme programmers usually say that eval should be avoided unless strictly necessary. I’ve seen the same recommendation for several programming languages, but I’ve not yet seen a While my transposition example above is all good and dandy, for more complex cases and even more so when multiple such transformations are nested -- which is after all what we do all the time -- I would prefer a somewhat more concise notation, and ideally be able to refer to individual parts by the name of their instrument. Below is an example that does that (using code from my library linked above). (setf poly-snippet-2 '(:vln ((q g4) (q. c5 e d5 q e5 f5) (h. e5)) :vlc ((q g3) (q c4 b3 a3 g3) (h. c3)))) (map-parts poly-snippet-2 #'pitch-transpose '(:vln (2 _) :vlc (7 _))) The function map-parts above could obviously be rewritten for the format of poly-score-1, where parts are referred to only by position, but I find naming by part more clear for more complex cases. It would likely be best to have both The function map-parts also provides a bunch of other features, that would be far more complex to reproduce with an explicit loop, check out the documentation linked above if you are interested... BTW: I reconsidered what I mentioned above concerning including information like the tempo etc. in the format of the score snippet. While that is possible in principle, perhaps it makes things unnecessarily complex. If we represent a score by a list with keywords labelling instruments (a plist), information like the tempo, key signature etc. could not easily be distinguished. We would better adapt the format (e.g., wrap all parts in an extra list) to make this distinction clear and easily parsable (below is an example), but such a format might become more complex than what we want. Tricky... ((:vln ((q g4) (q. c5 e d5 q e5 f5) (h. e5)) :vlc ((q g3) (q c4 b3 a3 g3) (h. c3)) :tempo 90 :time-signature 'whatever)

Ah, it is very useful to have all such changes collected in one place.

I really like seeing the function ps and multi-voice snippet previews -- and ps looks a bit familiar score TANDERS.GITHUB.IO However, perhaps we can do even better. The real power of the monophonic (old) snippets preview is that in a sequence of algorithmic transformations of musical material, quick score previews can be seen/heard of any intermediate stage without any extra code, just with those snipped keyboard shortcuts. For example, in the 2nd line of short code below, using the shortcut cmd-1 we can see/hear the original motif, its transposition and the inversion of that by simply placing the cursor at different positions in the code before executing that shortcut. (setf motif-a '(e. ab3 leg s bb3 leg q c4)) (pitch-invert (pitch-transpose 4 motif-a)) It would be great to have the same expressive power for polyphonic score snippets. My library (linked above) already contains a number of functions for processing polyphonic scores (e.g., for transposing all parts of a score, or only selected parts). For example, see my functions map-parts or map-parts-equally, that allow to concisely transform selected or all parts of polyphonic scores with arbitrary Opusmodus functions for single parts and possibly part-specific arguments. There function generate-parts does something similar, but starts the music generation from scratch without any input polyphonic score snippet. There are also functions for combining polyphonic snippets in various way (e..g, mixing them or appending them, for replacing instruments etc.) score TANDERS.GITHUB.IO score TANDERS.GITHUB.IO The key is having a data structure for polyphonic music that is handed and processed by functions and then somehow processed data in that format is returned -- as Opusmodus does all the time for single parts. However, what I could not do is define is a shortcut for previewing such polyphonic score snippets, which is why I had to instead define a function preview-score that must be called explicitly. Now, the new multi-voice snippet previews do something similar, but it only works on lists of un-named parts. It could be more powerful by also allowing for the format expected by the function ps. When we only have unnamed parts they can only be identified by their position, which can be tricky, e.g., if during some short section of a piece only certain instruments are playing (well, silent parts can still be represented with rests to preserve the position of parts, but it adds an unnecessary overhead). Also, when doing many transformations on polyphonic scores with many parts with part-specific arguments, the code is easier to read if it refers to specific parts by their name instead of their position. Long story short -- why not having a shortcut for basically what the function ps does, i.e. for a score format with named parts and annotations like tempo etc? It makes perfectly sense musically to algorithmically work with polyphonic snippets that contain all such information, mangle them in various ways, append them etc -- and being able to preview intermediate results at any stage with a mere keyboard shortcut PS: Apologies for reacting rather late to this...

Ah, renaming is easy. I seemingly like that function, had to replace it 7 times