So if I understand what you're saying about option 1: I display the abc code (of a file called tune.abc) as text but if the user clicks on it, instead of hearing proper abc, what they actually hear is tune.mid. Seems a bit like cheating, but I suppose it'd work (and MIDI's not all that bloated, compared with WAV or even MP3 or WMA).
------------------------------ Karl Dallas, HoustonMedia [EMAIL PROTECTED] Tel: +44(0)1274 823949 Mobile: 0771 980 5907 Please note: This is a personal communication, representing my own personal views, and does not necessarily represent the views of any organisation with which I may be connected, locally, nationally, or internationally. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Chambers Sent: Friday, January 31, 2003 3:08 PM To: [EMAIL PROTECTED] Subject: Re: [abcusers] abc in web pages Chris commented: | Karl Dallas wrote: | > Is there any way to use abc in a webpage so it can be played, either on | > loading, or when a link is clicked? | > If so, can anyone point me to where I can find out how to do this? Does | > the reader need to have some kind of a plug-in? If so, where can this be | > obtained? Could it be placed alongside the html file so a click will | > install it on the reader's PC? | | No plug in is required for the abc-tune-finder webpage: | http://trillian.mit.edu/~jc/music/abc/FindTune.html | | This is presumably what you want to do on your webpage. Try it out. I | believe what they do here is connect to other people's collections of | abc tunes on each individual server, then process the abc on their | server (mit.edu) into whatever format the user clicks on, then delivers | it to the user. I've thought of implementing my own version of that, | but I haven't had time to work it out yet. That's pretty accurate. There are really just three approaches to doing what Karl wants: 1. Have several files on your server, for the ABC and its translation to the other formats (PS, GIF, MIDI, whatever). This is fast, but takes a LOT of disk space. ABC is small; all the other formats are hundreds or thousands of times bigger. 2. Have just the ABC on hand, and convert it on the fly via CGI programs. This looks the same to a user, but is slower. It uses CPU time on the server. But the only extra disk space is the programs. 3. Send the ABC to the client and have it converted there. This only works if the client has conversion software installed and has their browser configured correctly, which is only feasible for a small crowd who can coordinate their software. It can't be made to work for a general public site. As the one who foisted the Tune Finder on the world, I chose 2. This was partly because I don't have the disk space. But it was mostly because the main intent of this site was to solve the problem of the long time it was taking me to find tunes on other people's sites and get them into a form that I could use. This struck me as a good job for a computer ... I've worked on a few projects that use approach 3. But there are some major problems with this. One is that no sensible user will permit downloaded code from a web site to run automatically on their machine. This is how you get things like the email viruses that are the plague of the Microsoft portion of the Net. When using a new browser, the very first thing I do is make sure that things like java, javascript, active-X, and other "scripting" tools are disabled. If I can't do that, I simply don't use that browser. (Even on Windows, this is always possible. You can grab the latest Netscape, which will turn off scripting reliably.) So approach 3 will never work with users like me. And even with users who don't understand this issue and leave scripting turned on, it still doesn't work. The recent Sun-vs-Microsoft lawsuit over java illustrateds why. Java is the best language for this, and it's not very good. The reason is that on Windows boxes, there are a zillion different releases out there, and they're all incompatible in too many ways. This is intentional on Microsoft's part, because java is a big threat to them. Providing a broken java (with different bugs in different releases) has been a good way to persuade developers that java isn't useful for its main purpose. Sun may have won the recent court case, but appeals may last for years. This isn't as bad on most other systems, where the java from Sun or the Open Source java are in use, but even there, there are niggling little problems that break your code in subtle ways. So unless you know that you have a small set of communicating users who can be relied on to keep their javas (or phps or whatever) all compatible, don't even consider approach 3. If you do, you will spend all your remaining time trying to answer novice users who can't get it to work right. OTOH, if you have the disk space, approach 1 is ideal. You convert the ABC once, and then it's just downloads. No CGI scripts to fuss with, no CPU usage other than the server's read/write time. And when there are problems, you have the exact file available for testing. But it will use a lot more disk space. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
