Jump to content

torstenanders

Members
  • Posts

    489
  • Joined

  • Last visited

Everything posted by torstenanders

  1. The Scala scale file format is specified here: http://huygens-fokker.org/scala/scl_format.html It is a flexible tuning format supported by various synthesis hard and software. As Opusmodus only outputs MIDI and leaves the sound synthesis to external software, those external software could be tuned with Scala files in principle. Scala files could be relevant for Opusmodus, if the tuning is controlled, e.g., via MIDI, e.g., pitch bend messages, note expressions of VST 3 etc... Best, Torsten
  2. Yes, I read that, but these functions all create libraries from scratch. Is there a way (planned) to extend a library? Thanks! Torsten
  3. Is there a way a way to extend an existing library? For example, for a specific composition I may want to collect a library of rhythms, melodic fragments etc., to arrange and transform these later with existing library features. Is it possible to by and by extend a library so that instead of, say, defining (setf rhythm1 (length-divide 1 3 '(q))) I instead may write something like (setf (library 'new-piece 'rhythms 'rhythm1) (length-divide 1 3 '(q))) Asked differently: what is the internal data structure of the existing library feature(s)? Is it possible to get access to that data for user-defined functions etc.? Also, is it possible to export an existing library into a file? BTW: Why are all these quotes necessary in calls to functions like library and many others -- why is the function library not a macro instead (only at the top-most level of course as syntactic sugar, I am certainly not suggesting to have macros instead of functions in principle). Thank you very much! Best, Torsten
  4. Dear André, Below is an alternative approach to do the same. The actual user-level code is more concise here, so this might be preferable if you have lots of such variations that should be easy to comprehend later. Best, Torsten ;;; ;;; Definition of map-omn ;;; (defun mat-trans (in-list) "Quasi a matrix transformations: transforms a list of form ((a1 a2 a3) (b1 b2 b3) (c1 c2 c3) ...) into ((a1 b1 c1 ...) (a2 b2 c2 ...) (a3 b3 c3 ...))." (apply #'mapcar #'(lambda (&rest all) all) in-list)) (defun map-omn (fn omn-expr) "Variant of mapcar for omn expressions, intended for creating variations of these. Applies function fn to every note in omn-expr (a flat OMN list). fn must exect four arguments (a length, pitch, velocity and articution) and returns a list of four values (a length, pitch, velocity and articution)." (destructuring-bind (lengths pitches velocities articulations) (mat-trans (funcall #'mapcar fn (omn :length omn-expr) (omn :pitch omn-expr) (omn :velocity omn-expr) (omn :articulation omn-expr))) (make-omn :length lengths :pitch pitches :velocity velocities :articulation articulations))) The user-level code starts here. ;;; ;;; Actual program ;;; (setf my-data '(e. c4 pppp tasto d4 ponte e4)) (map-omn #'(lambda (l p v a) (list l p ;; replace tasto dynamics by fff (if (equal a 'tasto) 'fff v) a)) my-data) ; => (e. c4 fff tasto d4 pppp ponte e4)
  5. Ah, great! I understand that then this setting is static for that score. With the new extensibility of OMN by user-defined text marks we may add all those settings directly to OMN
  6. Are rewrite-lsystem and its friends based on L-Lisp by Knut Arild Erstad (Erstad, 2002; http://www.ii.uib.no/~knute/lsystems/llisp.html) If not, they look and work surprisingly similar. For example, I can just use complex examples as the following from Erstad's documentation, and they work in OM. ;; Mycelis muralis (from ABoP, p. 87--90) (defclass mycelis (l-system) ((axiom :initform '((I 20) Fa (A 0))) (ignore-list :initform '(+ /)) (homomorphism-depth :initform 10) (frame-delay :initform 0.5) (frame-list :initform '((0 100))) (limits :initform '((-2 -1 -1) (2 14 1))))) (defmethod l-productions ((ls mycelis)) (choose-production ls ;; Growing apex ((A x) (with-lc (S) (--> (T 0))) (if (> x 0) (--> (A (1- x))) (--> [ (+ 30) Fb ] Fa (/ 180) (A 2)))) ;; Stem segment: propagates signals (Fa (with-lc (S) (--> Fa S)) (with-rc ((T c)) (--> (T (1+ c)) Fa))) ;; Undeveloped branch segment (Fb (with-lc ((T c) Fa) (--> (I (1- c)) Fa (A 3)))) ;; Delayed signal ((I c) (if (zerop c) (--> S) (--> (I (1- c))))) ;; Signals disappers (S (--> nil)) ((T c) (--> nil)) )) (rewrite-lsystem 'mycelis :depth 7) If this is Erstad's code, then it would be appropriate to acknowledge this in the documentation etc., and helpful for users to point at the much more extensive documentation of the original software. There are very many more features of this generator that users cannot guess from the existing documentation. Thanks! Torsten Erstad, K. A. (2002) L-systems, twining plants, Lisp. Master’s thesis thesis. University of Bergen. [online]. Available from: http://www.vcn.bc.ca/~griffink/lisp_lsystems.pdf (Accessed 21 December 2016).
  7. Thanks a lot for these. Stephane kindly shared his sound set as well, so for now I use that, but I kept a link to your code and explanations in my records and may come back later to that :) Thanks again, Torsten
  8. Wow, thanks a lot, that is a great start for me! I can extended that as needed I got my head meanwhile around the articulations in :group omn, but can you also trigger those in :group articulations from within Opusmodus? How? Best, Torsten
  9. I got a first small sound set defined for the EWQLSO (http://www.soundsonline.com/Symphonic-Orchestra), a subset of the solo flute using the default keyswitches. If anyone wants to use that library as well, let me share that you have to transpose all keyswitches given in the documentation up by one octave Anyway, I ran into a few general questions and minor issues. Request: the stacc and stacs articulations affect the played duration of notes, but the articulations leg and tenuto do not – they all take the full note value/length, while I would expect leg to be slightly longer, and tenuto slightly shorter. Is it perhaps possible to change that somehow? Also, the articulations marc and mart shorten the note duration, while they should better increase the velocity value, should they not? Bug: At end of a score the sound (e.g., reverb tail) is abruptly switched off. A workaround is to add a rest at the end of the score, but ideally this would be solved otherwise. Question: Why are keyswitches in def-sound-set examples defined with two keys? I found out that in that case both keyswitches are sent – why would you do that? I suggest this should be documented in the examples to avoid misunderstanding. Thanks! Torsten
  10. > I've started to develop a converter that converts Sibelius SoundSet files (xml) to Opusmodus SoundSet format. Could you perhaps share that script? I would like to use some EWQLSO sounds... Best, Torsten
  11. Great! No problem to define that myself if I get some docu of the API or at least a code example :) Torsten
  12. Actually, Opusmodus uses very many symbols that are local to a certain package for pitches, note lengths, dynamics and articulations. You may need to make sure that all these symbols are always in the correct package. I just ran a little test, and it seems that certain things also work with the equivalent symbols in other packages such as (:h :c4 :pp), but I am not sure whether this always works. In other words, it is likely best to import your definitions into Opusmodus :) Nevertheless, to keep your own code separate and portable it might still be useful to define it in its own package. Best, Torsten
  13. Thanks for your offer. I better try to keep things simple for you and try to do with the techniques that are already implemented for now :) Torsten
  14. Namespaces (packages) are a useful device to structure larger programs for avoiding clashes of functions names, variables etc. If you want to import the symbols from another package you can use them, as you do in your code, but this only works for symbols explicitly exported by these packages. Judging from the response of opmo (Janusz?), this has not been done with the Opusmodus package. You can do this yourself explicitly for all relevant symbols with export (http://www.lispworks.com/documentation/HyperSpec/Body/f_export.htm), but that would mean a lot of work for 700 or so user-level functions in Opusmodus. Alternatively, you could export all symbols of your package and use them in the Opusmodus package. You can also use internal symbols of a package outside that package with a double-colon notation like om::ambitus-octaves. This notation is supposed to look ugly, but it is a convenient solution for you right now... Best, Torsten
  15. So, are these two bugs? One related to the extend/duration of a rit. etc. and the other to :length? Thanks! Torsten
  16. Thanks for your quick response. However, I am not so such whether it would be best to define an extra symbol ord->tasto, because that would mean that a very large number of new symbols should be added. Instead, it would be better to have (in a later version, perhaps version 2) some kind of operator that can combine attributes, like currently the operator + does already for attributes. Lets assume that operator would be notated >, then a large number of transitions would be possible with one addition including ord>tasto, tasto>ord, ponte>tasto, tasto>ponte, tasto>ponte>tasto etc. -- at that is just a subset related to the position where the bow meets the string..., other articulations and other instruments would need many more. In the meantime, we may simply use the existing operator + instead (e.g., ord+tasto), and then revise the resulting score manually to change that to a true transition. This approach would allow for both transitions on a single note, and over several notes -- in the latter can the combined attribute is added to the required number of consecutive notes (as can be done with leg right now). Best, Torsten
  17. Ah, brilliant! So, I can now assemble multiple score sections to a single score. Thanks a lot for that! More generally, are there ways/plans to process scores with multiple parts with other functions in the composition process? Best, Torsten
  18. I would like to use some instrumental playing techniques that are not yet explicitly supported by Opusmodus, specifically extended flute techniques: whistle tones, jet whistle, low hoots and the like. Should I just wait for version 2, or is there already some trick now to have user-defined playing techniques specified? Thanks! Best, Torsten
  19. It seems there is a problem with the notation and MusicXML export of the "duration" of gradual tempo changes. The end of the tempo changes is shown too early, already at the beginning of the bar specified as its duration. (If a longer duration is specified to correct for that, then all subsequent tempo changes are delayed accordingly.) In the following example, the initial accellerando should last for 4 bars, but the final tempo q=200 is already displayed in the notation output at the beginning of bar 4, i.e., after 3 bars. Note that the tempo changes in the playback are correct, but the notation is not (nor the tempi in the exported Sibelius file). (setf pitches (gen-repeat 20 '((c4 d4 f4 g4)))) (setf tempo '((q :accel 70 200 1/32 4) (110 1) (:rit 100 60 1/32 2) (120 1) (60 1) (120 1) (110 1) )) (def-score test-tempo (:key-signature 'chromatic :time-signature '(4 4) :tempo tempo) (inst :omn (make-omn :pitch pitches :length (span pitches '(1/8))) :channel 1 :sound 'gm :program 'Clarinet)) By the way, the documentation of the tempo argument of def-score seems to suggest that the duration (argument count) of individual tempo statements can be independent of bars by specifying :length. However, I was not able to specify that. Please see below for a non-working attempt. What am I misunderstanding here? (setf tempo '((q 170 :length 3/2) (:rit 150 100 1/16 :length 1/2) (90 1) )) Thanks! Best, Torsten
  20. Is there a way to define transitions of playing techniques over one and multiple notes? For example, how to notate for a string instrument the following? ord. -> sul tasto Thanks! Best, Torsten
  21. Is there a way to append or even otherwise transform scores created with def-score? For example, it would be useful to have different sections created in different files, and then assembled together in one file. Of course, in principle I can currently create the individual parameters and parts in individual files, and then have only a single def-score definition in one place, but that is less convenient (intermediate results are not shown as score). More generally, is there a way to process intermediate results with multiple parts? If we would have access to a polyphonic score, then in principle there could be also score transformations that take the polyphonic context into account (e.g., Music21 allows for that). I understand that the meta information in the score header (title, composer etc.) can be inconsistent across def-score results if they are appended, but that should not prevent having some way to process intermediate results with multiple parts in principle. Perhaps there could be some simpler sibling to def-score that would leave out all information that should be defined globally only once, but allow for the creating of sections multiple parts, e.g., some def-particell (using a German word for a reduced/unfinished score, but still a score, not just a part)? Thanks! Best, Torsten
  22. Finally it is the question whether you want to generate music with the help of blackboxes/tools (whether open source or OM)... or you want to think, to reflect and to program your own ideas, and not to take what tools can easily generate (in this case you are not/less "independent"). Actually, I don't see this necessarily as an either-or. As someone who spend many years developing a composition system from scratch on my own I would say that -- if your main goal is actually composing and not developing -- then you should welcome the tools that are useful for your purposes, and not necessarily trying to stay "pure". For own functions I would try to avoid any dependency on software not freely available, but not for a composition project. Best, Torsten
  23. Would it help to have your transformation functions be related to explicit scales and its scale degrees (instead of measuring intervals in semitones)? That is what I did in my own computational harmony model. That allowed me to use arbitrary scales and the chords that belong to those scales. The tricky bit is that I am using constraint programming, where each variable can be controlled by multiple restrictions (constraints). So, I can restrict both intervals measured in semitones and in scale degrees independently. Would be tricky to translate that into plain functions. Attached is a related (unpublished) paper that outlines the approach in principle, though many details are missing in that paper. Tricky to share the code on that, because there is lots. Some core functionality (the data structure) is defined here (Oz programming language). https://github.com/tanders/strasheela/blob/master/strasheela/contributions/anders/HarmonisedScore/source/Score.oz Constraint programming is also possible within Common Lisp (e.g., with Screamer, https://nikodemus.github.io/screamer/, and other constraint solvers exist as well), and for mere harmony modelling (in contrast to modelling polyphonic music composition in general) this might be rather fast. Best, Torsten TorstenAnders-HarmonyModel-CP2016.pdf
  24. > Package Management Simple answer: use a separate package for a larger code project, and use ASDF, http://www.cliki.net/asdf There are online tutorials available, and for your kind of projects so far you do not need much. > TDD (Test Driven Development) With a REPL-based development this is less of an issue, as you may have noticed already. If you really want to, there are various unit test etc. environments available for Common Lisp. I never consistently used any. http://www.cliki.net/test framework http://www.mozartreina.com/unit-tests-lisp.html > is it wise to "lock in" to the Opusmodus product when writing my own functions Good question. I would tend not to. Just ported a little library to Opusmodus that I once created for a plain Common Lisp project, and later used with PWGL. All I had to do was getting rid of some recent PWGL-specific extensions in the ASDF file... On the other hand, if some system drastically would simplify your work and thus save you development time, then that would be different. I would be pragmatic. > When to use a functional approach and when to use an object oriented approach This is not an either-or decision. With a multi-paradigm language, including Lisp, you can combine such paradigms. For example, you can have higher-order functions processing objects. Anyway, I avoid state-based programming and side effects when possible, and if state is necessary then I try to encapsulate it locally so that towards the outside the program still appears stateless. In such a context, objects are then just some convenient data abstraction with method dispatch and a potentially hierarchic data "type" tree. Nevertheless, do not underestimate the convenience of simple data types like nested lists. With these you can directly see the results of your computations, while with objects you usually need some form of accessor to see certain detail. > p.s. the books I'm using right now are: Here is another recommendation showing more advanced Common Lisp programming in action - Norvig, P. (1992) Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp. Morgen Kaufmann Publishers. This book uses Scheme instead of Common Lisp, but helps to learn fundamental concepts how to organise code. - Abelson, H. et al. (1985) Structure and Interpretation of Computer Programs. Cambridge, MA: MIT Press. For a more advanced understanding of CLOS User-level: - Keene, S. E. (1989) Object-Oriented Programming in Common Lisp: A Programmer’s Guide to CLOS. Addison-Wesley. Looking under the hood: - Kiczales, G. et al. (1991) The Art of the Metaobject Protocol. MIT Press. > How to structure your project There are no hard rule on this, but perhaps a few rules of thumb, like you try to avoid repetitions in code by abstractions, or that you may try to simplify your programs by extending your programming language. The above books make help. Best, Torsten
×
×
  • Create New...

Important Information

Terms of Use Privacy Policy