Jump to content

torstenanders

Members
  • Posts

    489
  • Joined

  • Last visited

2 Followers

Contact Methods

Profile Information

  • Gender
    Male
  • Location
    Luxembourg

Recent Profile Visitors

5,270 profile views
  1. Update: I meanwhile managed to fix one of the issues, which prevented loading cluster-engine (some Swedish word in a comment caused some character encoding and end-of-line style mismatch, that was tricky to pin down, in particular also due to a somewhat cryptic error message ). Unfortunately, there is still some other problem when loading the tot library, which I will hunt down eventually, and then share my fixes at Github. In the meantime, I decided to simply use Opusmodus 2 on my old MacBook for a little longer, as there also the Emacs/Slime interface just works.
  2. Oh, thanks for clarifying that for loading modules is still possible to use asdf:load-system as a workaround. Nice. I can confirm that this is working! I still get errors, e.g., when loading cluster-engine, but it is now up to me trying to get that fixed.
  3. Any progress on using Emacs (Slime) with Opusmodus 3? It appears the file Emacs-Slime Setup.lisp is still part of the Extensions folder, but as reported (start-swank) results in an error. Thanks!
  4. I just tried using Opusmodus 3, but unfortunately there is a principle problem for me: it prevents me from loading any of me pre-existing libraries, which provide a lot of functionality already, but which I created for Opusmodus 2 (libraries like tot, cluster-engine, cluster-rules, cm-patterns etc.). It appears this is caused by the switch of Lisp compilers, and that the new version -- now based on LispWorks -- has been "delivered" without ADSF support. However, it appears this can be changed easily for Opusmodus by adjusting the parameters for creating the delivery to :KEEP-MODULES T (see docs). This is also what the error message I get is saying. > (require :tot) Error: REQUIRE was called after delivery time with module :tot. To fix this, either require the module before delivery or use :KEEP-MODULES T. 1 (abort) Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. Context for those interested in tech details: ADSF is the de facto standard for loading Common Lisp applications that consist of multiple source files etc. It is also part of LispWorks (though seemingly in the outdated version 2, because LispWorks has its on system for such purposes, but that is another matter). LispWorks is a commercial Lisp compiler, and when you deliver your Lisp application to your client, you usually create a delivery of your software, which disables some of the LispWorks features. After all, LispWorks still wants to sell further copies of its development environment (in fact, it is amazing how much development functionality can be preserved in a delivery as demonstrated by Opusmodus itself). Nevertheless, when creating the delivery it is possible to opt out of disabling some of the features, e.g., with the above-mentioned parameter KEEP-MODULES, as documented by LispWorks (I also remember from PWGL times, which was also a LispWorks delivery, that it was possible to load modules with ADSF). Sorry, but it has been a few years since I have had time using Opusmodus for the last time, and at the time I have still been using version 2 (on my previous MacBook). Thanks a lot! BTW: There are a bunch of hopefully helpful links in the above post, but for some reason they are not highlighted as such.
  5. I once implemented a version of this in PWGL with constraint programming (rule based programming) and the help of pwgl-cluster-engine and pwgl-cluster-rules. Unfortunately, I PWGL is meanwhile broken for me, and I cannot open this patch anymore, but just in case you have used PWGL and these libraries before, I attach a patch demonstrating it. If not, then this likely will not really help you. Sorry that I cannot help more. Its about 10 years ago since I did this... Best, Torsten 04-tintinnabuli.pwgl
  6. Thanks a lot for this info! > You can't use 2.2 and 3.0 on the same cpu Fair enough. I currently have 2.2 working on an my old Mac. I just keep that and wait for the Windows version, then I can use version 3 with my PC. Thanks for all your work on this update!
  7. >> what exactly are the new features in Opusmodus 3 (vs 2.2)? > 30 days trial should do the trick, hopefully less elusive and vague. Is it possible to run both Opusmodus 2 and 3 in parallel to test the new version without loosing the old one? I am afraid that the new version might have broken some of my Opusmodus libraries (porting them to a new compiler can be tricky). Also, I am very surprised that several people need to ask about a list of the changes of the new version, and there is still no response. (I also sent a private message with the very same question a few weeks ago.) I don't want to be impolite, but this makes the impression of a software company that does not really care about users finding its product useful. I actually know that this is not the case, but this is a very strange communication strategy. > Is it possible to run both Opusmodus 2 and 3 in parallel to test the new version without loosing the old one? I meanwhile found a response in another thread (link). I think I will then have to wait with the update and trial until I know more about the new version and perhaps have another computer to test it on. Thanks!
  8. > There are no restriction of any kind. Indeed, arbitrary Lisp libraries can be loaded into Opusmodus, which is great. I was ported over a number of libraries from other systems this way (some from OpenMusic as well, though not shared yet, as their development status is even more messy). > Opusmodus makes it difficult to use independent Lisp packages Just for completeness, I was talking here not about external Lisp libraries, but Lisp packages. Perhaps I was incorrect above, or at least not up to date. Sorry: this now gets a bit geeky. Are meanwhile *all* user-facing Opusmodus functions and also *all* symbols of its score format external symbols in that package? If so, then my comment above is indeed incorrect, and one could combine the external symbols of Opusmodus with the symbols of other packages in a clean separate package that would then represent Opusmodus extended with some other library in a clean way (and symbol shadowing could be controlled if necessary). At the time I (started to) define the tot library, the above was not the case, and I felt forced to define all my extensions directly within the Opusmodus package. Such package bloating is something I would usually try to avoid.
  9. > Possible workaround for now: remove the source file tuning.lisp and thus all microtonal stuff I should perhaps add that you remove a source file from the tot package by removing or commenting out the relevant line (line 25) in its defsystem statement. Hope this helps...
  10. > the problem is here that Opusmodus makes it difficult to use independent Lisp packages In Opusmodus' defence, this software tries to simplify using Lisp for non-programmers. This design goal somewhat conflicts with the design philosophy of Common Lisp itself to be a programming environment geared particularly towards large-scale and complex programming projects (in contrast to, say, Scheme or Python). Opusmodus therefore simplified a number aspects of Lisp including the discouragement of Lisp packages for Opusmodus programs.
  11. Copied direct response to Jon: Dear Jon, Thanks for your interest. You likely need to use another branch of the cluster-engine repository (optimisations): https://github.com/tanders/cluster-engine/tree/optimisations Background: cluster-engine was initially developed for another Lisp compiler, and I had to do a number of revisions to get it working inside Opusmodus and other compilers. I would ideally clean up the git repository, but don't really have the time to do that in the foreseeable future. > I can load tot, but some things are broken, most likely because Opusmodus has changed in the interim. Indeed, that happens. Opusmodus functions change (even their interface), and there is not really an easy way to see in a single document all the breaking changes, and I currently do not have the time to follow this up anyway. Sorry. Luckily, both Opusmodus and tot are rather modular, so ideally only some things are broken and others still work. Sigh... > The function ratio-to-cent is predefined by Opusmodus. Yes, I vaguely remember that this one cropped up at some stage when Opusmodus introduced that function. In a nutshell, the problem is here that Opusmodus makes it difficult to use independent Lisp packages, and Opusmodus itself defines very many symbols so these clashes happen. ? Possible workaround for now: remove the source file tuning.lisp and thus all microtonal stuff that tot defines for now (because a lot depends on the function ratio-to-cent there) ? Messy... I currently do not have the time to use Opusmodus, and unfortunately it shows in such breaks. Hope this helps. Sorry for all this mess.
  12. I assume you want to use the Lumatone for entering microtonal pitches into Opusmodus, right? The Opusmodus pitch representation currently supports microtonal pitches, but only subdivisions of 12 EDO into quarter and eighth notes. I don't know whether MIDI input for quarter and eighth notes is supported. If it is, then you might be able to hack some mapping of the Lumatone MIDI output to whatever MIDI input Opusmodus would require for the subset of microtonal pitches it supports. I understand that one can freely program whatever MIDI the Lumatone should output for a given key, so if Opusmodus has whatever MIDI input support for its microtonal pitches, you might be able to hack your instrument to output that, but you are most likely on your own there. However, Opusmodus cannot even represent microtonal pitches beyond the above. It cannot represent arbitrary equal divisions of the octave, and certainly no other tunings (e.g., no JI or arbitrary regular temperaments). At some stage I was extending its representation in a private project to support arbitrary regular temperaments, so that I could express, e.g., just intonation intervals in my extended OMN (incomplete state of this work at https://github.com/tanders/tot/blob/master/sources/tuning.lisp). However, I did not add any MIDI input mapping for that at all. If however you want to use the Lumatone simply for playing 12-EDO music with an isomorphic keyboard, then I guess it can output the standard MIDI output for that and I assume that Opusmodus could then handle that like the MIDI input from any other keyboard. BTW: I have another isomorphic keyboard here myself, but instead of using that I meanwhile moved to using MTS-ESP (https://oddsound.com) to always have some subset of my desired microtonal pitches available at any time, and to change this subset by MIDI events if I want to. Not as flexible as an isomorphic keyboard, but not too bad as an option either, and I stay compatible with all the software limited to mere 12-EDO (that software does not need to "know" I "misuse" it for microtonal purposes ).
  13. How much of the current code depends on CCL beyond all functionality of the Graphical User Interface incl. the editor, and the workspace? For example, does the MusicXML support depend on CCL, or the MIDI export, or... ?
  14. Thats a release from Apr 20, 2020. Am I missing anything? Release Clozure CL 1.12 · Clozure/ccl GITHUB.COM This is Clozure CL 1.12. There are two steps to obtain this release. First, obtain the source code for CCL by cloning the repository (with git clone https://github.com/Clozure/ccl.git), or by down...
×
×
  • Create New...

Important Information

Terms of Use Privacy Policy