On Sat, Mar 28, 2009 at 06:57:22AM +0100, Martin Tarenskeen wrote:
Which brings me to another question: why a version of midi2ly is
packaged with lilypond and still I have to use convert-ly ? Shouldn't
always midi2ly (and the other xxx2ly converters) be made compatible with
the lilypond
Graham == Graham Percival gra...@percival-music.ca writes:
Graham Frankly, I think we should just remove every *2ly convert
Graham apart from musicXML2ly. Nobody wants to work on them, so
Graham they just get gradually more and more broken over time.
I might support that if we were
On 28 Mar 2009, at 10:45, Graham Percival wrote:
Frankly, I think we should just remove every *2ly convert apart
from musicXML2ly. Nobody wants to work on them, so they just get
gradually more and more broken over time.
I think they should be there for the hope of somebody coming by in the
On 28 Mar 2009, at 13:08, Laura Conrad wrote:
I might support that if we were setting the example by having an
ly2musicXML, but we aren't.
Normally one only provide converters to ones own source code format,
so people get stuck with it: a form of competition limiting.
Hans
In message 191e48a7-f2c8-41cf-8b6e-b6ebec40d...@math.su.se, Hans Aberg
hab...@math.su.se writes
On 28 Mar 2009, at 13:08, Laura Conrad wrote:
I might support that if we were setting the example by having an
ly2musicXML, but we aren't.
Normally one only provide converters to ones own source
The typeset output looks weird when applying midi2ly (and convert-ly)
of LilyPond 2.12.2 to:
http://users.telenet.be/scottischkilt2/Midi/midi/72ndhighfare.mid
Is it fixable?
Hans Aberg
___
lilypond-user mailing list
lilypond-user@gnu.org
On Fri, Mar 27, 2009 at 11:09:01PM +0100, Hans Aberg wrote:
The typeset output looks weird when applying midi2ly (and convert-ly) of
LilyPond 2.12.2 to:
http://users.telenet.be/scottischkilt2/Midi/midi/72ndhighfare.mid
Which brings me to another question: why a version of midi2ly is
I'm afraid that the best available documentation is the source code. :-(
The impression I've got from the mailing list is that most people who have
tried to use midi2ly for any serious purpose have soon realized that it's
just as quick to enter the .ly file directly. Especially considering the
Hi,
I'm managing converting a *.midi to a *-midi.ly
*-midi is stored in C:\...\Lilypond\usr\bin. It contains a lot of
triplets (f8 g a)
Purpose is: avoid manualy modifying the *-midi.ly code to get all of the
triplets!
No answer found in the forums about the use of convert-ly
Environment:
Don't have too high expectations on what midi2ly can do with the
rhythm. As far as I know, it will only work reasonably well with
MIDI files generated from other notation programs.
/Mats
Ledocq-Boccart wrote:
Hi,
I'm managing converting a *.midi to a *-midi.ly
*-midi is stored in
Thanks Mats!
I have made some trials with various options settings: and I got
something I could start with making manual corrections.
I do not understand the effect of options like:
--explicit-duration
--start-quant=DURI did not see much effect
--duration-quant=DUR
With DUR=16 I get
Hi,
Where can I find explanations about the effect of the options of midi2ly.py?
What is quantize?
What is the effect of explicit durations?
etc...
I mean I would like to understand the link between the options and its
action on the structure of a midi file.
As yet I feel to cut and try
Greetings:
Some suggestions for the docs on midi2ly:
1) The utility will work as advertised *if* you use Type 1 MIDI
files. Type 0 files put all data into a single track, so unless you're
rendering monophonic music you probably want to be using Type 1 files.
2) Multiple tracks in a
13 matches
Mail list logo
