I am certainly interested in this! I use Michael Edwards' *slippery chicken *regularly and, coincidentally, have recently been looking into combining CM output with cl-svg.
I shall dive into your code and take a look! Thanks for sharing! Best, Dan *Daniel James Ross* vitruviandan.wordpress.com On 22 July 2018 at 17:18, Orm Finnendahl < [email protected]> wrote: > Hi List, Rick, > > as you might now, I'm using cm2 and try to somewhat maintain the code > base on my github account (partly to keep "Notes on the Metalevel" > alive), made it work in realtime with incudine and sc-collider and > even programmed some extensions I use for my compositional work. > > I don't know if it makes any sense to announce it here, as I guess > hardly anybody is using it. Therefore my question: Is *anybody* using > cm2 and interested in these posts? Otherwise it might make more sense > not to make any noise at all here... > > For those interested: Recently I made a svg backend for cm2: > > https://github.com/ormf/cm-svg > > you'll also need this package doing the heavy lifting: > > https://github.com/ormf/svg-import-export > > With the code loaded it is now possible to write > > (events (...) "/tmp/test.svg") > > and it'll save the data into an svg file in some sort of a > "piano-roll" representation including a piano-roll background pattern, > cent-aligned staff systems and barlines in different layers. The svg > can be opened and edited in inkscape and reimported into cm using > #'import-events. The major advantage to a midi piano-roll editor is > that the y-axis isn't restricted to halfsteps and > scaling/stretching/skewing operations will be imported correctly, > which makes it quite nice for microtonal/spectral work. This is a > preliminary port as I'm intending to extend this into arbitrary data > sets available for non-midi purposes (interfacing with incudine, > etc.). > > In addition I made a recursion pattern class. Although this could also > be modeled with the existing rewrite pattern, the specialized class is > a little more straightforward to use. I attach the file to this mail > as it is fairly small. > > @Rick: I found some bugs in the cm dictionary and am a little unsure > how to go about extending the documentation. I really like the > symbol-lookup from the editor and wrote some javascript to make the > frames version work with modern browsers. I'd love to extend your dict > but there are some issues: > > 1. I would like to annotate the extensions in the documentation to > distinguish it from the "original" common music (although this is > difficult anyway, as the original code already was a moving > target), keeping the code as much backward compatible, as possible. > How would you recommend to do it? > > 2. You probably used some sort of documentation system. Would it be > possible to hook into that and extend it from there and you send me > the sources or is that copyrighted/protected code? > > 3. I would prefer to keep all additional cm code which isn't related > to bugfixes in its own repository and don't know how I should > handle extentions to the documentation of this additional code. It > might be possible to just host the differences to the dict in the > new repository rather than forking the complete dict, but I fear > this is asking for trouble. > > Maybe you can give me some advice although I'm aware cm2 is not very > high on your priority list... > > _______________________________________________ > Cmdist mailing list > [email protected] > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > >
_______________________________________________ Cmdist mailing list [email protected] https://cm-mail.stanford.edu/mailman/listinfo/cmdist
