Jump to content

Search the Community

Showing results for tags 'implemented'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Welcome To Opusmodus
    • Announcements
    • Pre Sales Questions
  • Support Forum
    • Support & Troubleshooting
    • OMN Lingo
    • Function Examples
    • Score and Notation
    • Live Coding Instrument
    • Library Setup
    • MIDI Setup
  • Question & Answer
    • Suggestions & Ideas
  • Sharing
    • Made In Opusmodus
    • User Extensions Source Code

Blogs

  • Stephane Boussuge
  • Didier Debril

Categories

  • OMN The Language
  • Tutorial Guide
  • CLM Examples

Categories

  • Getting Started
  • HowTo
  • Live Coding
  • Music Theory and Analysis

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Gender


Location


Interests


About Me

Found 14 results

  1. 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!
  2. Is there perhaps any way to switch off all those trace prints created by very many Opusmodus functions. Here is an example: I want to get rid of printout(s) before the actual result. OM> (pitch-transpose 2 '(q c4)) pitch-transpose, transpose: 2 ambitus: PIANO section: NIL exclude: NIL (Q D4) These constant traces are problematic for me, because in all those prints I very easily miss printouts that are particularly important (e.g., warnings from some functions). I am aware of the Opusmodus function do-verbose. I would very much like to avoid adding do-verbose to my own functions. On the contrary, I am asking for a way to globally switch off what do-verbose does in other functions, e.g., by some global variable. That should be easy to implement (e.g., in the definition of do-verbose, if that global variable is set to NIL, no printing happens). Besides, if I really want some trace of function calls, this is actually already build-in into Common Lisp in a way that can be switched on and off selectively for any function with trace. BTW: The example shown at HyperSpec (http://clhs.lisp.se/Body/m_tracec.htm) does not quite work as expected in CCL, because CCL cleverly inlines all the recursive calls, but that can also be switched off (see https://trac.clozure.com/ccl/wiki/DebugWithOpenmcl). Besides, CCL offers also an extended version of trace (https://ccl.clozure.com/manual/chapter4.2.html). Further, I usually need traces during debugging, and Common Lisp IDEs usually provide even interactive backtraces (e.g., not only the arguments of functions, but also values of local variables within the lexical scope of functions can be seen, changed, and used in arbitrary test evaluations). I guess that such facilities have been purposefully disabled in Opusmodus, because such power can initially confuse new users. EDIT: basically, what I want to do is ensure that the internal function %do-verbose does not do anything if it is switched off, like so. (defparameter *do-verbose?* T "Enable or disable traces printed by do-verbose.") (defun %do-verbose (<args>) (when *do-verbose?* <put-orig-def-here>)) I cannot add this definition myself because I do not have the original code of this definition, and because the definition of this function is protected and cannot easily be overwritten by users. I should perhaps add that I appreciate that the do-verbose traces can be useful for getting the seed of some function call for "freezing" some result one might like. However, for me this usefulness still does not mean this feature should be switched on all the time. Thanks!
  3. 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
  4. The upcoming release will allow you to open display-midi, display-musicxml, graphs and snippets in a separate window. For any of you using second monitor this will be great addition to your work flow. Examples: (display-midi 'score :display :window) (display-musicxml 'score :display :window) Best, Janusz
  5. In Lesson 4, it is statet that "You can see the LENGTH-WEIGHT replaces previously 'sounding' lengths with rest-lengths throughout the stream of pitches. " But actually Length-Weight INSERTS rests. Sounding pitches are not replaced, but shiftet. Is that correct?
  6. Is there built-in functionality to sort a chord-progression using the top note? The following example uses the bottom note: (sort-asc '(a2a3 a2a4 a2e4))
  7. It would ve great to have the :port and :channel in the make-omn function. Sometimes is interesting for hearing snippets with different sounds without having to compile the entire score (sometimes it take a while,depending on the complexity of the score). The port would help to deal with vst adresses and libraries on auditioning. Best !
  8. I am working on a new omn symbol VOICES and wonder which way is more natural to write. I would like to hear your comments and ideas on this. Here are the two examples. With symbol :vx 1) Each voice after each event, next to each other (1 bar 4/4): symbol option :vx (:v1 q cs5 ff :v2 q gs4 ff :v3 q f4 ff :v4 q f3 ff :v1 q eb5 ff :v2 q gs4 ff :v3 q c4 ff :v4 q gs3 ff :v1 q cs5 ff :v2 q gs4 ff :v3 q f4 ff :v4 q cs3 ff :v1 q f5 ff :v2 q cs5 ff :v3 q gs4 ff :v4 q cs3 ff) symbol option :x (:1 q cs5 ff :2 q gs4 ff :3 q f4 ff :4 q f3 ff :1 q eb5 ff :2 q gs4 ff :3 q c4 ff :4 q gs3 ff :1 q cs5 ff :2 q gs4 ff :3 q f4 ff :4 q cs3 ff :1 q f5 ff :2 q cs5 ff :3 q gs4 ff :4 q cs3 ff) 2) Each voice in a separate bar (1 bar 4/4): symbol option :vx (:v1 (q bb4 ff g4 gs4 e g4 f4) :v2 (q cs5 ff b4 gs4 fs4) :v3 (q f4 ff bb3 gs3 e bb3 gs3) :v3 (q d3 ff e eb3 d3 q c3 bb2)) symbol option :x (:1 (q e4 ff h f4 q c5) :2 (e fs4 ff gs4 bb4 gs4 q fs4 f4) :3 (s g3 ff gs3 q bb3 s gs3 g3 q gs3 f4) :4 (q c3 ff h f2 q f3)) The symbol option :1 :2 :3 :4 (:1 (q e4 ff h f4 q c5) :2 (e fs4 ff gs4 bb4 gs4 q fs4 f4) :3 (s g3 ff gs3 q bb3 s gs3 g3 q gs3 f4) :4 (q c3 ff h f2 q f3)) will print in the Listener: (:|1| (q e4 ff h f4 q c5) :|2| (e fs4 ff gs4 bb4 gs4 q fs4 f4) :|3| (s g3 ff gs3 q bb3 s gs3 g3 q gs3 f4) :|4| (q c3 ff h f2 q f3)) I personally think the second option is better to control. Best wishes, JP
  9. Is it possible to have a key signature with a snippet? Thanks
  10. Is there a way to pop out a window? I have a dual monitor setup and would like to take advantage of it. Thanks
  11. Dear All I'm studying some 4-note cells for Coltrane like jazz patterns from a video lesson of saxophonist Chad Lefkowitz-Brown. The idea is to use a limited number of cells (no more than 10, some diatonic and some chromatic) to create longer lines, like the line below. 1) The idea is to connect the same fragments with different transpositions, adjusting the transpositions according to the construction of the line. I need a code where I can experiment the order and the transpositions of the fragments to create a longer line. Sometimes I can have two times the same pattern with different transposition. 2) The possibility to rotate fragments would be interesting also. 3) Lastly: a random assembling that automatically adjust the transpositions, in a way that each new fragment starts exactly a semitone up or down the preceeding fragment, making a cohesive line. Any help is welcome !! Looking forward to PLAY this patterns on the guitar and record some Videos (where I can mention Opusmodus, of course !) Best ! Julio I tried the form below, but I'm not very happy with that. (setf xa (pitch-fragment 1 4 '(g4 gb4 f4 g4) :transpose '(0)) xb (pitch-fragment 2 3 '(c4 cs4 fs4) :transpose '(0 1 2 1)) xc (pitch-fragment 2 3 '(c4 cs4 fs4) :transpose '(0 1 2 1)) xd (pitch-fragment 2 3 '(c4 cs4 fs4) :transpose '(0 1 2 1)) xe (pitch-fragment 1 3 '(g4 g4 g4) :transpose '(0 1 2 1)) xf (pitch-fragment 4 3 '(c4 c4 c4) :transpose '(0 0 7 2))) (setf seq '(f a e)) (assemble-section 'x seq) (setf jazzline (flatten (assemble-section 'x seq))) (setf rhyjazz (gen-repeat 50 '(s))) (make-omn :length rhyjazz :pitch jazzline) These are not the actual fragments, just some ideas do debug the code...
  12. Here is a suggestion for posting the random seed value used by a function. When using Open Music way back in time I remember that you could "lock" a random function if you liked the result, which IMO was a great workflow feature. Perhaps a similar thing could be achived in Opusmodus if the random seed used for a function was posted to the post window in addition to the result of the evaluation. If you like the result of a particular seed you could then manually "lock" the randomization using the :seed keyword for the function: ; first try different randomizations (setf bin-rhythm (gen-binary-rnd 5 5 2 1)) => gen-binary-rnd :seed 752 (setf bin-rhythm (gen-binary-rnd 5 5 2 1)) => gen-binary-rnd :seed 234 ; then lock seed if you like the result (setf bin-rhythm (gen-binary-rnd 5 5 2 1) :seed 234) Perhaps if possible also with the variable name as a label to keep track of things when using several random functions in complex code: (setf bin-rhythm (gen-binary-rnd 5 5 2 1)) => bin-rhytm gen-binary-rnd :seed 37 I think that this or a similar approach would be a really powerful way of trying different results when working with randomization in Opusmodus.
  13. Does Opusmodus perhaps already have some quantisation function that expects a list of floats and that basically rounds these floats into a metric rhythm, including using tuplets? I am aware of vector-to-length – that implements a simple form of what I am looking for, but it does not support tuplets. Other algorithmic composition systems have more sophisticated quantisation facilities. For example, OpenMusic provides the box omquantify (among other functions in the Kant library). http://support.ircam.fr/docs/om/om6-manual/co/Quantification.html I am aware that quantification is a complex process, but perhaps that is already there in Opusmodus. Best, Torsten
  14. Hi, I am looking for some functions that support chord progressions. For example, I would like to get the chords in the popular "I-IV-V" sequence in C Major scale. Is there built-in support for such standard progressions in the keys of common scales? Regards, Rangarajan
×
×
  • Create New...