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