conclusion
chapter seven
 

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.

   Our exploration, 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.

  7.1 future work
    

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.

VST technology
updates

 

   From the report, certain improvements in the VST architecture would immediately prompt improvements in the MIVI code. The principal two are:

 
  1. More transparency and flexibility in MIDI IO devices.
  2. 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.

  3. More control over host playback.
  4. 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 learners.

   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 been confirmed.

General MIVI

 

   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.

   Of course, 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) and (b)), 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

 

General MIVI

 

   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 [26][39].

porting to

other platforms

 

   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 addenda

 

   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).

  7.2 acknowledgements

 

 

   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.

 
 


All content, including code and media, (c) Copyright 2002 Chris Nash.