lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bar length


From: David Kastrup
Subject: Re: bar length
Date: Sat, 14 Jan 2012 20:07:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Marc Hohl <address@hidden> writes:

> Am 14.01.2012 19:16, schrieb David Kastrup:
>> Angles "D\'Auriac"<address@hidden>  writes:

>>> PS: when "I" am playing, measures can have very different length !
>> I have been thinking about an Emacs Midi input mode where you set the
>> bar checks manually after playing and Emacs then calculates the most
>> likely intended timing.
> Not joking? This would be awesome - I think, such a feature would
> make me give emacs another try ;-)

The lif so short, the craft so long to lerne...

I have corroborated that Emacs can open a raw Midi device with
make-serial-process and get appropriate input via process sentinels (as
long as it is not busy with other tasks).  You can get timestamps via
(current-time) in microsecond resolution.  Maybe one can also do the
time stamping via Midi clock.  Don't have much of a clue.

So you don't need to program Emacs in C: it has what it takes available
in Elisp.

But that's it.  I checked the existing lyqi input mode, and that is
written in its own, totally CommonLisp style.  Can't wrap my head around
that.  A smart LilyPond mode of its own should be likely written using
CEDET, but that _still_ does not have its parser generators in Emacs,
and juggling with additional repositories would just take too much time
for me.

So that's where I am.  "Thinking about", checked a few prerequisites, no
working code, no proof of concept (except for having checked
make-serial-process for being workable on a Midi port), no time.

Want to commission something?  2000€, and I expect to be able to sustain
myself until a first version is working.

Can't afford it?  Same here, same here.  Try finding enough other people
with the same desire.  The algorithms (basically Viterbi&Co) might
transfer to midi2ly, so if some Python programmer picks up from the code
and/or comments (and I am confident to do better than midi2ly, having
good signal processing background, and I need to or this will not really
fly), there might also be a side benefit.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]