Hi all, Thanks to Dana for bringing up those questions: it is always a bonus for programmers when users and other programmers express their ideas on concrete matters like this. In fact, I have been feeling personally in the past year or two that perhaps I lost contact a little too much with the old crowd. This is not necessarily totally bad, because programmers have to face a number of arcane issues on their own and need to develop and introduce new ideas to keep things interesting for themselves and potential users. And much of that has to be done in relative quietness and isolation. Yet, this could be a fascinating opportunity for everyone - users and programmers - to try and evaluate the current situation, their hopes, goals, and even perhaps frustrations. So much is changing so fast in our world, that pausing a bit from time to time to look at the general direction of events is not really a luxury. So what I want to do below, is talk a bit about my own general philosophy of programming, where I think we stand in the general environment of programming/publishing, and summarize what sort of issues I am currently working on. Even if I summarise, this is bound to be a slightly longer message than average, so if you are not interested, please cut along the dotted line below and trash the rest: it's heavy reading! ----------------------------------------------------------------------------------------------------------------------------------------- Django uses a very simple proportional spacing algorithm that works well only part of the time. In fact, it works best as a combination of automatic and manual intervention - by inserting blanks here and there. What seems to be a fairly simple issue, is complicated by a number of factors: the need to space several voices for several instruments, some in notation some in tablature perhaps. The addition of lyrics also complicates the issue quite a bit. The limitations in paper sizes also play a great role: the standard paper size for computer printers is not suited to music printing in general. But for me, the crux of the problem - as almost always - is to find the right balance of automation versus manual intervention. We all hate it when Bill Gates is trying to finish our sentences for us, but we also do not want to have to spend time reformatting every note. So, in a sense the software has to be sensitive to the user in an almost intelligent way, or at least this should be a goal. This is the question of options. Proportional spacing is only one aspect of the more general problem of "preferences". Whenever you satisfy one person, there will be another person who likes it better the other way. Software writers should not be bitter about this - tempting as it may be - because this is perhaps the only and certainly the main advantage of software over traditional publishing: you don't need a xerox machine with scissors to reformat the Poulton for performance if you have a digital copy of the Poulton available. Only a few key strokes and you can end up with a copy in regular notation in any clef you like, in French, Italian, German or yet to be invented tablature system, etc. Again, the discussion of proportional spacing is a perfect example of this: we have talked about various proportional models, and the ideal software would certainly support all of those and more. But as software writers do offer more and more options, using the software also becomes more complicated for the user. Depending on their system, leisure, etc. programmers may or may not address this problem. One of the most common solutions I think is to offer templates that take care of many parameters at the same time. But to be entirely successful, these have to be developed by the users themselves, and not every user wants to have to deal with even that level of complexity. Rightly so in most cases. it's all a question of balance. In the lute world, the most vexing question in that regard is ornaments. No matter what ornaments you offer, the only one that seems to matter is the one that is missing from the toolbox. Remember that unlike regular notation, there is no standard, established set of lute/early music ornaments that a developer can easily depend on. One of my plans in the near future is to expand the ornaments system in Django, but this will again introduce more complexity.
My main point here is that in enriching the software and building more flexibility, the quality of the dialog with the users is really quite important. It is also important in trying to build a rich, flexible software that does not require going through hundreds of pages of help file or take a three-day course to master. Users' intuition matters. From what I have said above, and if you did not know it already, you can see that there is quite a bit of thought and work involved in developing a piece of music software. Increasingly so. As we develop our systems and make the goodies available, people naturally expect more. This is where it seems to me, in the past couple of years, a tendency has grown to consider that small software developers like me, who do it on the side of their real job, cannot possibly offer the same level of quality as the big companies like Finale or Sibelius can, with their full-time large teams of bright ivy-league graduate programmers. As a result of that trend, I think, people have been investing sometimes hundreds of dollars into those software simply because it seems to them that if it costs 800$ it is bound to suit their all needs, when in fact a much cheaper, amateurish piece of software could have done the job better. The fact is that in the past couple of years, the "professionals" in the music software industry have drained much of the resources that could have benefitted smaller developers, and that most of those resources are going towards paying salaries for middle management, a host of MBAs and advertising costs that are completely marginal to the real business of software writing. The fact is also that in spite of all the professional qualities of those softwares, the tablature interface of both Finale and Sibelius until recently was simply appalling. In some respects still, the MIDI import features in Django are still superior to those in Sibelius, and some of the new features I have developed recently - document indexing, management of large collections of documents, integration of digital facsimiles, and a couple of other things, won't be in the planning for Sibelius or Finale for a few years to come. Those softwares have undeniable qualities and strong points of course, but my point is that there has been a drainage of resources that have affected the small guys with the net effect that while the quality and of the work involved in writing software has increased, the basic revenue source has shrunk. I found this the hard way, when after starting work with the French guitar player Pierre Bensusan, he suddenly bailed out to fly to London to take a three-day course on how to use Sibelius instead. Clearly an expensive mistake, because the programmers need to go to the musician's school and not vice versa. Mac users in particular need to understand this phenomenon very well: writing software takes an enormous amount of time and energy, and in the very small niche of lute music you simply cannot expect any substantial return. In other words, you have to be nuts to do it. Personally, I have no idea how to turn my code into a native Mac interface, even though in theory, C++ code can be compiled on any platform. This would not be a minor investment. Make no mistake, even when you are paying for a registration for either Django or Fronimo, you are still paying a highly qualified person for well under a nickel an hour. So, the question is: why even bother to charge? In my case, when someone takes the pains to send in the registration, this gives me a sense of the importance of what I do and I try to take it very seriously. This is less a commercial aspect than a psychological one, and it is very needed each time I sit at the computer instead of spending time with my family, or picking the lute out of the case, for instance. We have a saying in French: Tout travail merite salaire. If work is not worth paying for, it is useless. This does not go against the efforts of freeware people, I think, because in my mind the freeware, code sharing model was developed by programmers for other programmers, who in exchange for the free code donated their expertise for debugging, expanding the code, etc. So I don't think of freeware as totally free. This brings me to my final points: what keeps me going and where do I think Django is going? When you think about it, a lot of what keeps us going is a mixture of unfinished business and accomplishments: there is plenty of unfinished business left to be done in Django: I have mentioned ornaments already, but there are many other aspects - better regular notation, better look, easier handling of instruments, documents, etc. A lot of my work in the past year in fact is in both categories: accomplishments and unfinished, so quasi-acomplished... I want to single out two aspects that I think are particularly important: -Indexing of documents. This allows people to better search through large collections of files, so you don't have to spend hours navigating your pc files to find the one piece that you need. So far, the indexing is relatively basic and I use a combination of programs to accomplish it, some of which are definitely not easy for non-programmers to handle and set-up for themselves. However, the door is open for searching not only by author or title, but for more sophisticated modes of searching: by key, instrument or even chord sequence. -Document clusters: the idea behind this is that a piece of music is really nothing in itself except a cluster of representations in a variety of format. At a simple level, a piece in Italian tablature is also the same thing in French tablature. But you can add to that the idea that it is also a wav format file containing POD's interpretation of it, or a PDF file ready to print, or a facsimile image. And you might want to have all those representations conveniently at hand. So now, Django offers the possibility of linking a particular piece to an HTML link towards a digital image for instance. This allows users to provide not only a transcription and interpretation but also the source she used for the the transcription. it also solves part of the problem I mentioned earlier with respect to preferences: you can distribute a piece of music both for people to reformat if they feel like it, or in its final form for printing as you have it in mind. Being able to integrate a digital image in the program also makes it a lot easier, more reliable and less physically painful to key because you don't have to turn your head every other second. I think these are aspects that are important to lutenists and that as a group, and in spite of our commercially insignificant marginal niche in the market, we still have a lot of vitality, ideas, and energy to offer. In the end, the direction of events is in your hands - much more than you think. Well, there is another thing that keeps my going: playing with the software to create some really bad music... You can check my latest example of this at http://cbsr26.ucr.edu/wlkfiles/Publications/Prelude/Prelude_orch.html - A prelude for archlute, bandoneon, cello, bass and tinkle bells... Cheers, and apologies for being so verbose, Alain Roman Turovsky wrote: >>I also prefer to have spacing. It would be nice to have the possibility of >>changing the grade of it. >>Unfortunately that isn't possible in django and a little bit uncomfortable in >>fronimo at the moment. >> >> >In Django you can have either uniform proportional spacing automatically, or >entirely manually for each bar (my preference). >Fronimo's spacing is easy to achieve, if you know the parameters you are >entereing (1.5 for most durations). >RT > > > >To get on or off this list see list information at >http://www.cs.dartmouth.edu/~wbc/lute-admin/index.html > > >
