[CM] Midi microtuning in cm2

[Ralf Mattes]

On Thu, Mar 09, 2017 at 07:14:01PM +0100, Orm Finnendahl wrote:
> Hi List,
> 
> I had a similar discussion with Ralf Mattes recently. I wrecklessly
> did the bugfixes for the cl port only. It wouldn't be a big deal to
> fix the scheme part as well, but it seems to me that cm3 includes all
> of cm2 and enhances it in so many ways that I'm not sure that keeping
> the scheme port of cm2 legitimizes too much effort. And Titos
> arguments are the main point why I'm not using the scheme->lisp
> translator (although I don't understand very much about code
> optimization in common lisp it seems clear to me that Tito is a very
> good source of advice in that respect).


Ok, let me chime in here: my initial goal was keeping CM opertional in
current common lisp implementations to be able to use "Notes from the
Metalevel". Some of my design goals where:

 - getting a purely declarative, modern ASDF build system.
 - removing as much as possible the implementation dependend code,
   delegaging all impl. differences to exiating, well-maintained
   libraries (networking, mop, image dumping etc.).
 - make CM extendible (jack integration, incudine integration etc.)
   _without_ introducing new dependencies (this is where Prm's code
   is, erm, suboptimal :-)
 CM should be part of the "official" quicklisp distribution.

After integrating the scheme->CL compiler into ASDF I started to 
realize how problematic that approach is. For me, one of the killer
features of Emacs/Slime integration is Meta-dotting, i.e. running
'slime-edit-definition' which imediately pops up the source code of
a function, variable etc. With the current CM setup this creates some
semantic problem: either we end up in the _generated_ source code (read:
changes to the Lisp code will be lost during the next load/compile of
the ASDF system) or we end up in the scheme code (whic would require
ridiculous amounts of implementation dependent code) which would force
us to switch programming language mid-work ...
And, as Tito already mentioned, the generated code often prevents
compiler optimizations, something I wouldn't want to give up, esp.
after Tito and Orm did some impressive work in the realtime area.

> I'd argue it'd be better to continue like this:
> 
> 1. Concentrate on the cl port of cm2, sometimes maybe even gently
>    diverging from it to adapted ports for e.g. plotter (maybe even
>    with additional functionality).
> 2. Report bugs discovered in the code which might still affect cm3 on
>    the cmdist list.
> 
> 3. Maybe even getting rid of the scheme part of cm2 in the code base
>    (my github repository is from Tito and already doesn't contain the
>    scheme code anymore).
> 
> 4. keeping a branch of the original cm2 and backporting bugfixes
>    affecting that codebase.

That's pretty much the conclusion I came to as well.
I was thinking of applying for a repository on common-lisp.net (tacky name
MusiCL) as a place to maintain an up-to-date version of CM2 and related
code. I'm trying to keep CM2 from spitting into a pile of privatly
maintained, slightly different versions of the code.

Cheers, Ralf Mattes