denemo-devel
[Top][All Lists]
Advanced

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

Midi: was Re: [Denemo-devel] Re: Updated RPM spec file


From: Richard Shann
Subject: Midi: was Re: [Denemo-devel] Re: Updated RPM spec file
Date: Sun, 27 Jul 2008 19:58:36 +0100

On Sun, 2008-07-27 at 09:34 -0500, Jeremiah Benham wrote:

> > You are the only one improving the midi which
> > is far more important. There seems to be a need out there for
> getting
> > music into Denemo via midi; I don't have much idea how much
> information
> > is present in (some? all?) midi files to make this useful. 
> 
> I will focus on the midi import filters. Two months is probably a good
> time to get multi-voiced staffs working. Midi files contain alot of
> information like velocity information for each note, lyrics, track
> names, track midi instrument, title, composer and probably more that I
> am not thinking about. 
Is there anything about key, clef, time signature?
> There is really much that needs to be done on
> importMidi. Things that yet need to be done are Tupplet support,
I am guessing but I suppose that you can only detect tuplets by the
duration of the notes
> multi-voice, lyrics, and quantization. Quantization is very important 
and if so, it is related to quantization support.
I think this sounds like it could be the most important thing to do:
Quantization is one of those things which is difficult to get a good
user interface to. The user needs to understand what effect he is having
by adjusting the parameters you provide, and the choice of parameters
will affect this. The best route might be to separate the quantization
from the midi import: provide functions for working on a Denemo
selection and quantizing it different ways so that the user could adjust
certain passages differently from the whole. (So your first thing would
be to copy the whole set of notes in its raw form, and always perform
the quantization from those to the set of notes appearing in the
display, ie the ones in the si->thescore->measures list, or whatever it
is called).
That way the user would get in the whole file with some default
quantization then applied to it before it is displayed, but could
re-quantize all or part of it on an experimental basis until he does a
save and closes the score. Functions like this would also have a lot in
common with functions that do changes such as augmentationm
re-timesignaturing and note-name shift (re-cleffing), which Nils came up
against recently. They could involve re-barring music, for instance,
seen as "applying a series of note/durations to a time signature
scheme". This is heady stuff, the key to success would be to do a few of
the most useful things in a very general way.

 Lyrics sound like they could be useful (at a minimum extract the text
and put it into the MultipleVerses.denemo format). But I'm puzzled about
multiple voices - I mentioned in an earlier email that you can merge two
staffs to become two voices on one staff. Does this not make it low
priority?
Richard








reply via email to

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