Fw: [TeX-music] dviconcat
Well,... It's been so long I forgot how to reply to the LIST :-))... This is already old news, thanks to everyone's contributions... but I thought I would send it again anyway, just for the practice. (Yesterday I sent it, but just to Don Simons, thanks to Outlook Express :-) Regards Joel Hunsberger - Original Message ----- From: "Hunsbergers" <[EMAIL PROTECTED]> To: "Don Simons" <[EMAIL PROTECTED]> Sent: Tuesday, October 21, 2003 11:02 PM Subject: Re: [TeX-music] dviconcat > Greetings!! > > I have used dviconcat (the Windows Port) for various experiments in the > past, and seem to recall having to use the full file name plus extension. > This got my curiosity up, and I found that there is 'a version' of the c > code for dviconcat in the CTAN archives: > > http://www.ctan.org/tex-archive/dviware/dvibook/Dviconcat/dviconcat.c > > ...the general directory is: > > http://www.ctan.org/tex-archive/dviware/dvibook/Dviconcat/ > > A Full archive seems to be at: > > ftp://ftp.dante.de/tex-archive/dviware/dvibook/Dviconcat.tar.gz or at > http://theory.uwinnipeg.ca/scripts/CTAN/dviware/dvibook/Dviconcat.tar.gz > > The Man Page is very brief, and no help for your question. However, I did > browse around in the old C code, and (in particular) did not see any place > in the general flow of events where any action is taken to 'tack on' a .dvi > extension if one is not provided. So, I'm thinking that this program > probably needs exact (full-fledged) file names. > > Now, since we have the code in the archives... It is tempting to do some > kind of GUI Front End, maybe in Java, so every system could use it. > Wouldn't that be a great learning exercise!! I'm thinking there is a lot of > knowledge about the DVI file here in this program that might be useful to > learn, or manipulate this process to do something similarly grand. > > Joel Hunsberger > > > - Original Message - > From: "Don Simons" <[EMAIL PROTECTED]> > To: "TeX-Music" <[EMAIL PROTECTED]> > Sent: Tuesday, October 21, 2003 10:15 PM > Subject: RE: [TeX-music] dviconcat > > > > The syntzx you gave is correct; I use it all the time. I always use > > filenames that explicitly end in .dvi although I haven't tested whether > > that's essential. > > > > --Don Simons > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > Behalf Of [EMAIL PROTECTED] > > > Sent: Tuesday, October 21, 2003 8:16 AM > > > To: TeX-Music > > > Subject: [TeX-music] dviconcat > > > > > > > > > Dear friends, > > > > > > some time ago, someone on this list sent me the DOS binary of > > > dviconca.exe along with instructions for use to the following effect: > > > > > > dviconca -o outputfile infile1 infile2 infile3 > > > > > > I've been trying this without useful results; all I get is DVI files > > > of size 0 bytes, or an output file containing nothing but infile1, or > > > ten-megabyte monstrosities (from two 20k input files) which YAP > > > refuses to open. Can anyone tell me what's going wrong here? > > > > > > TIA > > > Eva > > > > > > > > > ___ > > > TeX-music mailing list > > > [EMAIL PROTECTED] > > > http://sunsite.dk/mailman/listinfo/tex-music > > > > > > > ___ > > TeX-music mailing list > > [EMAIL PROTECTED] > > http://sunsite.dk/mailman/listinfo/tex-music > > > ___ TeX-music mailing list [EMAIL PROTECTED] http://sunsite.dk/mailman/listinfo/tex-music
[TeX-music] FLIP, was M-Tx on Windows: starting up problems
"Gert Kessels" <[EMAIL PROTECTED]> wrote... > Hi, > > Thank you all for your help. It was line-endings after all, after EDIT in > DOS, add some spaces and exit and save it worked. So I'm happy now. > > I subscribed only yesterday and I'm very glad that there is so much > expertise available. M-Tx saves really a lot of TeX-typing, so if I can > really use it, I'll be very glad. > Wow... Leave for a day and you miss a lot... I am glad to hear that Gert found the answer needed. I want to add that I frequently use a utility called FLIP to convert whole directories from Unix to MS-DOS line endings. There are many utilities named FLIP, so a search on Google will bring up a lot, but this FLIP is the one I recommend. (This is for Windows PC Systems, where the user knows how to use the MS-DOS Prompt and do basic operations from the 'command line.') Noting (first of all) that FLIP is ... Copyright 1989 Rahul Dhesi, all rights reserved. Permission is granted to copy, use, and distribute for any commercial or noncommercial purpose in accordance with the requirements of version 1.0 of the GNU General Public license. ... you can download and use a copy from: http://www.simtel.net/pub/pd/51483.html or ftp://ftp.simtel.net/pub/simtelnet/msdos/txtutl/flip1exe.zip The source code can be obtained from: http://www.simtel.net/pub/pd/51484.html I believe this is a port of the popular Unix utility of the same name. Just unzip it in a directory in your DOS path (like the MusixTex bin for example.) What is so useful with this particular program is that it can convert an entire directory. You enter (from the DOS command line): flip -m *.* and it will convert only those files that are good candidates to convert, like ASCII Files, and skip the binary files. It will also tell you what was skipped. It will convert the files 'in place' (it replaces the original file), which is more convenient than dangerous, particularly when you have extracted the files from a zip archive. (You can also force it to convert any file if you want.) This version of Flip makes it very easy to extract a massive archive and then process the entire directory just to be sure that any Unix sources are converted to MS-DOS. (It will not convert a file that is already okay either!! :-) I do not know how well it works on Long File Names... but then, MusiXTex isn't quite one of those tools troubling those waters, either. One (of several) good MAN pages on this version of FLIP can be viewed at: http://pinkstuff.publication.org.uk/cgi-bin/man2html?flip+1 And, finally, the standard MusixTex distribution (at least up to T99) contained two utilities UTOD.EXE and DTOU.exe, to do just this very thing on any given file, so there it is (for now)... Enjoy. Using Windows 95, 98 and Windows 2000, MikTex, and what's left of MS-DOS :-) Joel Hunsberger - Original Message - From: "Gert Kessels" <[EMAIL PROTECTED]> To: "'Tomas Lundberg '" <[EMAIL PROTECTED]>; "Gert Kessels" <[EMAIL PROTECTED]> Cc: "'''MusiXTeX ' ' '" <[EMAIL PROTECTED]> Sent: Thursday, March 06, 2003 11:07 AM Subject: RE: [TeX-music] M-Tx on Windows: starting up problems > Hi, > > Thank you all for your help. It was line-endings after all, after EDIT in > DOS, add some spaces and exit and save it worked. So I'm happy now. > > I subscribed only yesterday and I'm very glad that there is so much > expertise available. M-Tx saves really a lot of TeX-typing, so if I can > really use it, I'll be very glad. > > Regards, > Gert. > > > > -Original Message- > From: Tomas Lundberg > To: Gert Kessels > Cc: ''MusiXTeX ' ' > Sent: 6-3-2003 16:32 > Subject: Re: [TeX-music] M-Tx on Windows: starting up problems > > Gert Kessels wrote: > > Sorry Christof, I can't find any news in the HOW TO section. I have a > > running environment for both, MusixTeX and PMX. It should be possible > to use > > the binary executable from the zip-file, but the only way left seems > > donwloading TurboPascal and figuring out why prepmx produces the > errors. > > > > I'm quite sure that the problem is UNIX vs. DOS line endings. The > example scores have UNIX line endings, and if you run those > through prepmx without converting them to DOS line endings you > get the error message you described. So the answer is to convert > the example scores to DOS line endings. This is done automagically > if you use "unzip" with the "-a" option; this is stated in the > "README" file. I'm not sure if WinZip can do this automagically; > if not, you can do as stated in the "README" file under "Text > file formats" or use a separate tool for converting, such as > e.g. "tofrodos" ( http://www.thefreecountry.com/tofrodos/index.shtml ). > > Tomas > > -- > Tomas Lundberg, Ph.D. E-mail: [EMAIL PROTECTED] > EAB/TVP/P Tel:+46 (0)920 - 202361 > Ericsson ABMobile: +46 (0)70 - 2736815 > Luleå, Sweden Fax:+46 (0)920 - 202099 > _
Re: [TeX-music] Free music softawres do not exist!
<[EMAIL PROTECTED]> wrote... > In the event, this person proved unable (or unwilling) even to try to > install TeX, let alone learn MusixTeX. For my part, I've never ceased > to be glad that, when faced with the need to set guitar music, I > refused to throw money (the price of Finale/Sibelius/Whatever) at the > problem and instead invested the necessary time to come to grips with > MusixTeX. With a little, and at times a lot of, help from my friends > on this list -- and let me take this opportunity to thank them once > again for their kindness. Happy New Year to you all! [snip... ] Eva, Christian, Daniel, Don, Dirk, Rainer, and the many, many other contributors and caretakers on this list: (!!) I (first) want to thank all of you, and others, for your continuing support that enables us to do great things in music typesetting!! (I reviewed the names and messages received on this list last year and was truly impressed with the number of contributors and the significance of the contributions. Thank you all very much! I wanted to type many more names, and there are many more who deserve mention and Thanks!) Most recently I upgraded my home computer from a Windows95 machine to little bigger machine running Windows 98, and took the opportunity to also migrate from EmTex to MikTex. It was Eva's (and Christian's) excellent guide, (found at http://icking-music-archive.sunsite.dk/software/musixtex/musixwin.pdf) that provided the guidance to make that transition very easy... After years of 'Texing' I still would have easily run amok by the subtle but significant differences in directory structure between the two packages... You saved me HOURs of confusion! All facilities (including the step up to MusiXTex T1.09 and PostScript fonts) went into place very easily Although I have not posted too much this year, I have continued to use MusiXTex, via M-Tx (primarily) as a means to provide (... not any masterworks but,) the utility parts and pieces that one needs (frequently on the same day it is conceived) to support a small church choir. I am often asked, 'What did you use to produce this score?' I have not yet found anyone who really wanted to know. If I am in a 'good' mood, I outline the progression from M-Tx source through to the final PostScript file, (not to mention GhostScript)... and they quickly find an excuse to change the subject. If I am in a bad mood, I simply say, "You don't want to know." It seems, most often, that what people REALLY want is a quick, effortless way to just have music score appear. Very few have even considered how much information is conveyed by this invention we call 'music score.' When they complain that there is too much complication involved with TeX-based tools, I simply select a small segment of a published score (any score) and ask them to review how much is evidently communicated to a performer in order to realize a performance of that segment. When they take a closer look at it, they are usually able to recongize that there are many issues of pitch, duration, expression and context that must be made clear, ... and as they proceed, they begin to sound somewhat more complicated themselves, just describing the score as they see it :-) A typical problem (today?) is that many are satisfied with something much less than an adequate score in the first place. (That is, many 'amateur' musicians do not even want (or use) the various expression marks that a good score attempts to convey.) When people talk about producing music score 'quickly,' they usually mean that they want 'just the notes' and such scores typically do not have much more in the way of expression markings, etc. When they really need to produce a detailed score, complete with all expression marking, they have to spend quite a bit more time at it, even if they are using Finale, (or whatever tool it may be). The detail necessary for the best music score is not 'easily' achieved with any tool. (Note that 'easily' is the important word.) Personally, I find that I can typeset the details much faster with my fingers than I can with a mouse. Although I have not used any WYSIWYG package too much, I have experienced enough of that type of editor to realize that I am NOT able (actually) to complete a score any faster. Yes, perhaps I can drag a sequence of notes into place more rapidly, but when I have to undertake the 'fine tuning,' I soon become annoyed by the amount of 'click here, click there' activity that I need to do. Even with other tools available, I find myself returning to MusiXTex to get better results, frequently in a shorter period of time. In the place where I work, we have managers who want to know 'everything' that is going on! However, they don't want you to waste any of their time actually communicating that... (They want very short status reports, they don't want to have to read anything more than one page long...) Now, when something goes wrong, then they want to know why it is you did n
Re: [TeX-music] How convert a midi file to PMX or MusiXTeX
Greetings, All!! Christian Mondrup <[EMAIL PROTECTED]>, wrote... [in reply to...] > Jan Nieuwenhuizen wrote: > > "Olivier Vogel" <[EMAIL PROTECTED]> writes: > > > > > >>So is there a simple program, with in-line command (like PMX or M-Tx), > >>for converting easily a midi file to PMX or MusiXTeX? > > > > > > LilyPond comes with a fairly simple python script, that will covert > > MIDI to LilyPond input: midi2ly. > > > > Although that's not what you want, it would not be too much work to > > write a simple pmx backend for it. > > > > IMHO converting MIDI to some sheet music notation format is non trivial > if the source of the MIDI data is anything else than output from a sheet > note editor. For example if MIDI data are sequenced in from real time > playing on a keyboard the MIDI-to-some-editor program will have to deal > with things such as quantization. You can never know how 'loose' the > keyboard playing was. > > -- > Christian Mondrup, Computer Programmer This thread really wakes me up these days. Christian has made a very good and accurate summary of the major issues facing related to MIDI input to PMX. I am mostly a user of M-Tx and would like to target MIDI input to M-Tx, since I am more likely to need quick and easy lyrics input... ) However ;-((... I have sometimes started down this road only to be sidetracked by lack of time, and many side trips into other interesting subjects, but no real progress on this problem. (I dream on...) Now, realizing that I am likely to be a Windows 'Whatever' user for the forseeable future, (oh Linix/Unix people, forsake me NOT :-), most of the things I have considered revolve around improving the efficiency of the basic input, and the most familiar environment is Windows 95. Consequently, it would NOT be real important, nor very realistic, to work toward a comprehensive translation of 'everything in the MIDI file' to something on the printed page. (Well, as Christian points out, a lot of problems can crop up...) The most useful tool to me would be a 'MIDI clip capture' tool; something that would 'listen' to a simple line from a 'real time' MIDI keyboard, and then interpret that into a trial clipping that could be adjusted or corrected, then 'pasted' into the open M-Tx (or PMX) file 'in work.' In short, we would need a lot more versatile IDE (integrated development environment), even more than just a tool for translating a MIDI file into PMX. Another feature that such an IDE might have would be to both 'isolate' and 'merge' part streams into an existing file. For example, it would be really nice to pull (say) 12 bars of the ALTO part into a work buffer, fix it in some way (maybe even do things like search and replace on just that text, etc.) and then paste/replace it back into the open file. It would be nice to be able to create a part independently 'in the work window' and just add it into the midst of the other parts. (You can see that this capability would be the enabling functionality under the MIDI capture function described above.) It would be great if one could (say) highlight 5 bars and request 'preview'... The selected text input would be (internally) buffered with a 'faked' preface and various context setup, then rendered (yah... the whole PMX, Tex x 2, Dvi-View sequence), which (by the way) is hardly a time problem on any decent PC any more. (Did I hear about anyone working on a side-by-side Tex Rendering system, with any MusixTex implications...) Well, I can always dream! These are all development tasks that I would commend to any interested parties! However, some of the simple things would be to translate MIDI clips into M-Tx or PMX... the tough part (it seems) would be to manage the overall context of the 'document in work' so as to really control and benefit from the MIDI input clips. Final thought... I had a few opportunities to try Finale Notepad, and I still think that I can type M-Tx faster and with better results (as long as I remember what I need to type!) than I can deal with the point and drop approach to placing all the score elements in the right place. In the end, I am still more satisfied with the score appearance from MusixTex than any others. However, it would be really great if one could interpret the proprietary Finale file format (since Notepad already reads MIDI) and write PMX or M-Tx script sequences... An interesting thought, but does not appear likely. Once again, I have gone on much to long... My teenagers want to use the computer Right Now :0)) School work and the like always comes first. Joel Hunsberger ___ TeX-music mailing list [EMAIL PROTECTED] http://sunsite.dk/mailman/listinfo/tex-music
Re: [TeX-music] status of M-Tx
>Subject: [TeX-music] status of M-Tx Dirk wrote: > >PS I guiltily read the sentence saying that M-Tx is still in its 1998 > >state. > ... and ever since 1998 (and before!) I have continued to use it successfully, for just what I need to do, without major problems... I wish we could say that much about Micro$soft[ware]... Never mind the guilt! (Bill Gates doesn't experience guilt, I'm sure. :-) Thanks (again!!), Dirk, for your most useful and efficient contribution to my music typsetting needs. Joel Hunsberger ___ TeX-music mailing list [EMAIL PROTECTED] http://sunsite.dk/mailman/listinfo/tex-music
Re: [TeX-music] PMX crash on xtuplets beginning with a rest
Stefan: Just for comparison, your example ran successfully through an earlier version of PMX... I am running on a PC, Win95 (DOS 7.0) I guess it's time for me to update my PMX installation, but then again :-) Joel Hunsberger --- This is pmxab, version 2.3, 19 February 2001 Opening test.pmx Starting first PMX pass Bar 1 Done with first pass Starting second PMX pass Bar 1 Writing ./test.tex Done with second PMX pass. - Original Message - From: Stefan Svensson <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 16, 2002 6:39 AM Subject: [TeX-music] PMX crash on xtuplets beginning with a rest > This example crashes PMX. If I remove the rest at the beginning of > the fourth triplet, it works. > > --- > 1 1 4 4 4 4 0 0 0 4 20 0 > > t > ./ > > c4x3 d e f4x3 r a b4x3 a g r4x3 e d / > --- > > Result: > > pmxab test.pmx > This is PMX, Version 2.357, 13 March 2002 > Opening test.pmx > > Starting first PMX pass > > Bar 1 > Done with first pass > > > Starting second PMX pass > > > Bar 1make: *** [test.tex] Segmentation fault > > > ___ > TeX-music mailing list > [EMAIL PROTECTED] > http://sunsite.dk/mailman/listinfo/tex-music > ___ TeX-music mailing list [EMAIL PROTECTED] http://sunsite.dk/mailman/listinfo/tex-music
[Tex-Music] Donald Knuth's Home Page (Reference)
Greetings! On reading a few posts today about how to set different default TeX fonts (I hope to contribute soon... but my daughter wants this computer to do HOMEWORK :-(( ) I happened to do an idle search at www.google.com for 'tex fonts' and discovered a couple interesting links: We owe so much to so many for MusixTex and it predecessors, not to mention PMX and MTX, but THE ONE PERSON who set the stage for what we are using today is Donald Knuth. For those new to MusixTex, Professor Knuth pioneered the TeX typsetting language, probably in the late 60's and 70's (as far as I can tell). He is still very active in his work, which has branched and bridged into many areas. His home page is located at: http://www-cs-faculty.stanford.edu/~knuth/index.html Also, possibly of interest to many of us, is a link on his page that reveals his interest and proficiency as an organ player... http://www-cs-faculty.stanford.edu/~knuth/organ.html At the bottom of that page is a link to MusixTex page (pointing to the GMD collections.) So, Professor Knuth seems to have also benefited directly from the contributions of his musichological descendents,... A most gratifying cycle of technology, I'd think. Regards, Joel Hunsberger [EMAIL PROTECTED] P.S. - Concerning default fonts, one might look into 'alternate tex bases' created by copying Plain.Tex and MusixTex.Tex to alternate-named files and altering the fonts actually loaded for the various default fonts. CAUTION: This is a bit of unothodoxy here, but it might work. I think that direct substitution in the code on the 'fly' might work, if you are familiar with how fonts are loaded. (See those files)... Anyway, too late tonight to experiment, and my daughter is kicking me off in the name of her Education! Thanks for listening. ___ TeX-music mailing list [EMAIL PROTECTED] http://sunsite.dk/mailman/listinfo/tex-music
