summaryrefslogtreecommitdiff
path: root/muse2
diff options
context:
space:
mode:
authorFlorian Jung <flo@windfisch.org>2012-05-28 16:51:51 +0000
committerFlorian Jung <flo@windfisch.org>2012-05-28 16:51:51 +0000
commite87fedf1be804f7ec774071d844b1f163be30b96 (patch)
treeebdf6185f24cb5fc1b453799a38b64a9c646d68a /muse2
parentd2a88cfaad5ac385fc3c6212c09ad7fbc38e9454 (diff)
some documentation merging
Diffstat (limited to 'muse2')
-rw-r--r--muse2/doc/documentation.tex56
1 files changed, 54 insertions, 2 deletions
diff --git a/muse2/doc/documentation.tex b/muse2/doc/documentation.tex
index 49d26964..a36fd07c 100644
--- a/muse2/doc/documentation.tex
+++ b/muse2/doc/documentation.tex
@@ -173,7 +173,11 @@ the drum list, you'll get unexpected results), you can't set a program
for the used channel and more.
\subsubsection{New style drum tracks}
-That's why there will be new-style drum tracks in the next development version. % TODO: in trunk, change this
+Because of these limitations, we introduced the new-style drum tracks.
+They're not fully compatible with the old drum tracks, so the old are
+still retained. Under "Global Settings", "GUI settings", you can set
+up whether you prefer the old or new.
+
They are handled exactly like plain MIDI tracks (staying compatible with
them), and offer all of the functionality, though in a different way.
They allow you to re-order the drum map efficiently, you can open parts
@@ -471,7 +475,7 @@ MusE will play back the stuff, record it again and re-enable the
pre-rendered information.
-\section{Extensions}
+\subsection{Extensions}
\paragraph{Automatic discovery of physical audio connections}
The user plugs all (or only some) synthes' audio outs into the available
audio inputs, then runs automatic discovery. This will send MIDI events
@@ -499,4 +503,52 @@ changes, and end re-recording as soon as the recorded stuff doesn't
differ to much from the stuff coming from the synth. Then properly
blend the old recording with the updated part.
+
+
+\section{Slotted editors}
+Currently, MusE has the pianoroll editor, drum editor, score editor,
+then the controller editor which is inside the pianoroll/drum editor.
+All these editors have a very similar concept: the "time axis" is
+vertical and (almost) linear, they handle parts, and events are
+manipulated similarly.
+
+A unified editor shall be created which allows you to combine different
+kinds of editors in one window, properly aligned against each other.
+These "different kinds of editors" shall be handled as "slots"; one
+unified editor window consists of:
+\begin{itemize}
+\item A menu bar, containing stuff suitable for the complete window,
+ which might include window name, MDI-ness etc.
+\item A toolbar which contains controls suitable for every single slot.
+\item A container with one or more slots; the slots can be scrolled in
+ y-direction if there are multipe slots.
+\item A time-scrollbar with zoom
+\end{itemize}
+
+Each slot contains the following:
+\begin{itemize}
+\item A menu button, button box or control panel for setting up this
+ particular slot. This could contain "note head colors", "show
+ a transposing instrument" etc for score edit slots, "event
+ rectangle color", "grid size" and "snap to grid" for pianoroll/
+ drum editors.
+\item The actual canvas
+\item A y-direction scroll bar, possibly with zoom control (for
+ pianoroll editor)
+\end{itemize}
+
+The main window does not show its scroll bar if there is only one slot,
+because the slot's scrollbar is sufficient then.
+
+Slots can be added, destroyed, moved around, maybe even merged (if the
+slot types allow it); basically, you can compare them with the staves
+in the score editor.
+
+The slots shall align against each other, that is, if a score editor
+slot displays a key change with lots of accidentials, then all other
+slots shall either also display the key change (if they're score slots)
+or display a gap. Events which happen at the same time shall be at the
+same x-coordinate, regardless which slot they are.
+
+
\end{document}