[CM] cm2: svg backend, permutation pattern

[Daniel James Ross]

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 <
orm.finnendahl at selma.hfmdk-frankfurt.de> 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
> Cmdist at ccrma.stanford.edu
> https://cm-mail.stanford.edu/mailman/listinfo/cmdist
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/mailman/private/cmdist/attachments/20180722/179adede/attachment.html>