In the last chapter, we
established the virtues and shortcomings of the current MIVI implementation.
Overall, it appears a success, achieving what we set out to do,
and demonstrating the MIVI concept as a worthy addition to the music
technology and education field.
as it stands, however, far from exhausts the potential for research
and development. Most obvious is the limited set of implemented
instruments (piano and flute) and the demand for human hand simulations,
established in the last section.
Although the prototype
engineered in the project demonstrates that the simulation and concept
are realistically possible, such matters must be addressed before
exposure of the software is practicable in a wider field. As the
final chapter of this report, we briefly discuss such potential
for further study and development of MIVI. Finally, in section 7.2,
the author lends thanks to those people who helped make the project
and this report what it is.
As an exploration of a new and exciting
technology, the MIVI project represents a good foundation and justification
for further research in the field. As well as several areas of improvement,
identified in the last chapter, we have noted impasses in our progress
due to minor deficiencies in the host, throughout the report.
From the report, certain improvements
in the VST architecture would immediately prompt improvements in
the MIVI code. The principal two are:
- More transparency and flexibility in MIDI IO devices.
Currently, a learner is forced to execute counter-intuitive
procedures (described in section 3.1.3 and section 5.2.4) to properly
initialise the system, for playback or tutoring. The ability to
identify MIDI input devices and specific MIDI output devices would
allow for the automation of such procedures.
The author has conducted successful experiments
using direct calls to the OS multimedia hardware-abstraction layer
(HAL) to implement such functionality, but notes that such additions
would be platform dependent and infringe compatibility.
- More control over host playback.
As criticised by Dr. Hunt, in section 6.1.1,
the inability to tailor tempo and playback to learner performance
presents an air of discomfort during tutor lessons. The ability
to start, stop, speed up and slow down, were it available would
be a relatively painless augmentation to the tutor system behavioural
code, but yield a noticeable improvement from the eyes of some
Both of these are promised in forthcoming
releases of the VST technology. A release date, however, for the
next update of either the technology or the Cubase host, has not
On a more idealistic note, it would
be interesting not only to unleash the MIVI application on aspirant
musicians, but also on developers. The ultimate test of a programming
architecture is its ability to be understood and fully exploited
by programmers who are not privy to intrinsic knowledge of its creation
– would another developer be able to start up where we left off?
This question would be tested by opening
the extension of MIVI to General MIVI – a visual mirroring
of the 128 instruments of the GM specification – to third parties.
The author suggests two ways to achieve this.
Firstly, the MIVI architecture could
be adapted to encompass a plugin environment of its own, where each
instrument is a separately coded file – independently loadable into
a MIVI host system.
However, while holding flexibility
in the composition of sound-sets (where users might simply download
the desired instruments from the Internet), this approach requires
considerable modifications to the existing architecture, and thus
a less involved approach is favourable, in the short term.
So; instead, we could follow the modern
trend towards open-source software projects (such as OpenGL) and
simply distribute the system, in its entirety (both compiled libraries
and pre-compiled source files). Again, a practical medium for this
would be the Internet18.
This expansion, in combination with the first VST
improvement (mentioned earlier), presents the potential for an additional
control in the current user interface; where the user might be able
to select an instrument from a list of those available from a particular
piece’s ensemble, encapsulated by the open file.
the human element
An addition to the flute model, which
met with positive feedback from flautists, would be that of human
hand simulations. This would be possible using the principal of
Inverse Kinematics, described in Appendix B – however, time constraints
inhibited its implementation in this project.
The addition of more complexity to
the scene, however, means that steps must be taken to prevent the
hands obstructing parts of the instrument itself. A simple and practical
solution rests with making the hands partially transparent. As we
described earlier in the project, this necessitates the involved
process of introducing alpha-sorting to our 3D objects.
Such efforts, however, would be further rewarded
by the ability to use anti-aliasing techniques. Early experiments,
by the author, show that the application of this technique would
give rise to a sizeable increase in picture quality and realism.
hands are not the only part of the anatomy involved in playing a
musical instrument. The head – most notably, the mouth – is something
we have also established as benefit to the model. Using technologies
incorporated into modern graphics hardware (see figure 7.1 (a)
this type of face modelling is now plausible in a real-time applications,
and could be used to demonstrate lip-shapes upon a flute embouchure,
tongue-action. Combined with more explicit display methods (like
arrows), aspects of performance, such as breath pressure, might
even be displayed.
fig. 7.1 (a) - the Truform™
technology from ATI19
fig. 7.1 (b) – the HeadCasting™
technology from Matrox19
Some people have mentioned that their
interest in MIVI stems from an innate curiosity in the workings
of the instrument, rather than its intended educational nature.
On a superficial level, this might involve the modification of our
flute model to account for axle movement (as opposed to simulation
– section 4.4.2). Such an adaptation might even lend to a more flexible
and intuitive model, while making effective use of the OpenGL stack.
On a wider and more interesting scope, this might include the ability
to lift the piano lid and interactively tour the interior of the
piano. In this instance, a question is soon posed about the explicit
exhibition of sound waves and their journeys, like that of the violin,
described in section 2.2.1. Further study in this area would be
able to draw upon existing research in the area of sound-distribution
A recurring theme of this report has
been the attempt to make our product a good candidate for porting
to OS’s foreign to Microsoft Windows™, and we have explicitly mentioned
methods and obstacles before us, in this respect. Thus, naturally,
an interesting study would be the attempt of such a port. The Macintosh
platform – a system still popular with musicians – represents an
excellent first choice in this situation.
Other additions and improvements
that naturally follow from sections of this report include: the
elaboration of statistical performance feedback (section 5.2.5),
the preservation of lesson state (section 5.4), the update of the
Boehm model to account for common flute extensions (section 6.1.2),
the implementation of piano pedals, the use of the mouse in direct
rotational control, and general improvements in visual quality,
accuracy and detail, such as anti-aliasing (section 3.2.2).
My most sincere thanks
go to Steve King for both his enthusiasm and encouragement during
the lifetime of the project and documenting of this report.
My appreciation also goes to the developer
communities at Steinberg and Yamaha for their guidance at various
stages during the project.
Finally, I am grateful to all involved in providing
feedback at various points along the MIVI implementation – particularly
to the Music Dept. and Society, here at the University of York,
for making it possible.