Funny you should mention MML. Ever have one of those moments where you smack the side of your fist against your forehead and cry, "they stole my idea! AGAIN!" When you mentioned MML, I had one of those aw-hell moments! Back in 1981 when I first got my hands on an IBM PC--the original real-deal one with 256K main memory and two 5.25" floppy drives--I looked through the GWBasic manual and discovered that, if I used the "PLAY" statement, which took some interesting parameters for not just pitch but duration, I could get the thing to play monophonic (as opposed to polyphonic) music from its internal speaker. OK, so why write play statements all day? Why not write a parser which would read a file of lines and lines of funny-looking code, parse it into PLAY-statement notes and note lengths, and play them? SO I built this program. You had to know music to code the music files, but once I got it working right, I was turning stuff out for the amusement and amazement of my office colleagues on a daily basis. I never knew that this technique was ever even thought of by anyone else, no less turned into a real-deal thing calling itself the Music Macro Language.
Now, to drag myself back on topic, your ideas are good and sound, but may be outside the scope of QWS as James foresaw it. However, being able to define a string of controller codes and give it a name in an INI file that QWS could just read and insert on demand, now that shouldn't be beyond QWS's scope, in my unhumble. While that's not a real editor, at least it gives the opportunity to insert these things. They could be called something like controller blocks. The only problem there is that they would have to be dealt with as such, unless they could be edited individually once inserted, rather than dealt with as a block. Or maybe it would just be easier to have an option in QWS not to sort the manually entered controller data so it could be inserted in the order needed without having to mess with tick times. On Mon, 23 Feb 2015 07:51:06 +0800, you wrote: >Hi, all. I thought I'd write down here my thoughts and ideas for those >of us who like to do some pretty advanced midi tricks, such as dealing >with sets of controllers, particularly NRPN messages, working with sysex >messages, and a possible alternative way of viewing and working with >midi events. This will be semi-long, just as a heads up. > >1. sets of controllers. > >While I love working with the qws event list editor, it can get a little >tedious when inputting sets of often, 3, sometimes even 4 controllers to >use NRPN (non-registered parameter number) messages. For example, to set >the pitch of a snare drum, three controllers need to be sent, in a >particular order, such that data entry controller number 6 is always >sent last. It would be nice if all the controllers could just be >inserted, all at the same time, and most midi players/sequencers seem to >handle this fine. qws, however, resorts the controllers so that all the >data entry messages come first, then all controller 98 messages, and >finally controller 99. To work around this, I place the data entry >controller a tick after the rest, which works, but can get annoying when >dealing with a hole string of these. See number 3, below for a possible >suggestion here. > >2. working with sysex. > >While qws has full support for sysex messages, working with them can be >quite brain taxing! You have to not only remember the strings to insert, >but some manufacturers (ahem, roland?) require individual parameter >changes have a checksum calculated for each of them! >Even something as simple as a checksum calculator would be nice here, >but my idea, and this may be going beyond the scope of James' vision for >qws, would be to have some sort of patch editing/librarian as part of >the program. You could have mini scripts, or settings in ini files that >set up the parameter names, and the messages for each one. I offer this >suggestion because, unfortunately, most editors/librarians I've seen are >inaccessible. > >3. An alternative view of events. > >Again, this may be a bit trickier, or outside the scope of James' idea >for qws, but it would be nice to have a way to view events of a track, >in some form of text notation. Something where a-g represent notes, a# >for sharp, bb, bf, or something similar for flat. Perhaps it could look >similar to the gwbasic/basic play statement, known as mml (music macro >language) in japan. I have sources available for one such system, >mml2mid, however the comments are all in Japanese. However, this system >can notate just about any midi event, including control changes, sysex, >meta events, and even some text events like markers and queue points, >that qws doesn't support. >This might make it much easier to do things like, connecting a series of >notes using pitchbend messages, which can be done now, but requires some >event list editor gymnastics. It would also just make another way of >viewing events in the midi possible. > >Again, if you made it this far, take a prize! or something. Thoughts on >these ideas welcome! > >Arthur > >To unsubscribe or change list options, see http://lists.andrelouis.com > >for archived list posts, see http://www.mail-archive.com/[email protected] To unsubscribe or change list options, see http://lists.andrelouis.com for archived list posts, see http://www.mail-archive.com/[email protected]
