[CM] cm2: svg backend, permutation pattern

[adam]

Yes, some of us still use CM2. +1 to keep posting Orm. 

Although it refused to build the last time I tried it. 
I must try again, I'm presently using an older image.  

I see that CM3 or Grace requires a make or cmake process these days. 
It was nice when there was a Ubuntu executable. But that's OK. 

Thank you. 







On Sun, 2018-07-22 at 17:18 +0200, Orm Finnendahl 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