Oldskooler Ramblings

It’s very basic, but it functions. Leech.

I’ll be working on MONOTONE very lightly until May, when I’ll dedicate more time to it. Why? Because I’m editing together the Block Party compo/awards footage for online release.

Big BIG thanks to yesso and virt for the sample songs.

This clip thankfully cuts out the first time I tried to demonstrate it, in which I give a nice speech and then the projector wouldn’t display anything at all. I later got the CGA monitor while the compo was moving, hooked it up, and NOW the project synced up to the composite signal and worked. Hm.

For those who hate flash, you can get the raw MPEG-4 file of the performance.

If you have an hour to waste, the presentation I gave is available (warning: mpeg-1/mpeg-4/flash derivatives probably won’t be ready until 6 hours from now).

Here are some pictures from Block Party.  I usually don’t take many pictures because my camera is an 8-year-old 3MP camera with a few dead pixels, but I managed to squeeze out a few that don’t completely suck.

If it isn’t obvious, keep clicking on a picture repeatedly and you’ll eventually get the full-size pic.

…and I just arrived back home, and will promptly crash.  I will write a more detailed report with a few pictures tomorrow or Tuesday.

Just got finished with my talk at Block Party and I think it went well. It ended exactly when I wanted it to end (55 minutes after the hour, giving the next guys a few minutes to get set up (Circuit Bending, currently in progress, demonstrating very wrong yet very funny things with a Speak and Spell).

Already NOTACON/Block Party is turning out to be one of the best and most unique experiences I have ever had. The highlight of the event was having Jeri E. sitting next to The Fat Man, collaborating on their compo entries. YES THAT’S RIGHT I SAID COMPO ENTRIES. We are in for an old-fashioned, old-school beating… an enjoyable one, but still a beating :-)

A personal high was meeting The Fat Man and talking about the industry (thank you MobyGames!) and also meeting Virt and having him fast-track something in MONOTONE. There very few people I idolize more in the computer music industry than those two.  Speaking of which, both of their talks went really well, even though Fat had to deal with some soundsystem drop-outs and Virt had to deal with a young child in the audience who was, ah, very vocal about the presentation and how it should be run.

IC has done a great job, once again, of converting the democoder lounge into a place of scene spirit, with mood lighting and a running videotrack and soundtrack of all things scene.  Speaking of which, there are nearly double the people in the lounge this year (it’s full) which is a great sign.  You can go in and see people working on music in trackers, custom demotools of their own design, Visual Studio, even old stuff like Quickbasic and Turbo Pascal.

Six hours until the compo…

In the last two weeks, I have achieved the following in my quest to finish MONOTONE before arriving at Block Party:

• Gotten the flu (took up three days right there)
• Wrote a completely customizable abstract input routine (complete with keyboard configuration utility — with tipsheet writer!) because some composers will throw a hissy fit if the basic interface isn’t exactly like ${FAVORITE_TRACKER}
• Wrote a keyboard interrupt handler (complete with human-readable labels so that “410Ah” reads like “Ctrl+LShift+Alt+F7″) because you never know when some hissy-fit composer will demand the use of Ctrl+LShift+Alt+F7
• Wrote instantaneous-fast (not an exaggeration) text routines, including multiple virtual screens that use hardware video pages where available

…and I haven’t sounded a single note yet. But you can actually watch the pieces slowly come together now, and it’s pretty damn fun writing from scratch what is essentially turning out to be a miniature operating system.

Next up: The main framework request handler/dispatcher and a finalized abstract Song object (and MONOTONE-specific descendant). Hopefully both tomorrow night, or I’ll have to stop development to work on my presentation :-/

One of the things that contributed significantly to MindCandy 2 being delayed for 18 months was self-inflicted implosion. I got so hung up in the project — worrying about what to do, how to do it, when to do it, who was waiting for it, what was affected by it, etc. — that I self-destructed and sought out anything that would help me avoid working on it.

Oh, I wanted to work on it. I love capturing video, especially from older computers doing their thing. I love processing it without touching the picture detail; I love compressing it to within an inch of its life without affecting picture quality. I love distributing it. And I especially loved the subject material. But left unchecked, my mind tends to enter a recursive death-spiral feedback loop during moments of stress and I just spin my mental wheels.

I started to get that hung up over my Block Party plans and obligations. Should I attend? If so, what should I bring? Should I give a talk? If so, on what? Should I bother with a compo entry? If so, what compo? Is it worth going if none of my very close friends will be there? If so, who will I talk to? What talks should I attend? Ahh! Aaaaaaahh!!

Five weeks ago, I was in #blockparty telling s_tec how much I enjoyed the invtro, and after a brief conversation, he innocently stated something that reminded me, after so many years, why I love the scene and all its related offshoots:

[14:49] <__Trixter> Almost makes me want to write a demo again :) but I’m not sure I will. I can’t compete with the big boys and this hunk of junk is much slower than my imagination is
[14:50] <s_tec> So? Making demos isn’t about winning, it’s about making.

It is indeed. Thank you for the reminder; it was cathartic.

With my head cleared, I was able to sort out all of my thoughts, organize them, and get them down on paper (well, into a text file). I have a very clear direction on what I want to accomplish and how to accomplish it. Whether I get it done in time for Block Party ‘08 or not, I make daily progress. This is a good thing. The experience, like all fun programming, is not unlike relaxing in a trance-like state punctuated by occasional moments of pure exhilaration.

I am working on creating a nearly useless piece of software. Only a handful of people will ever use it. It serves no practical purpose. But it is mine, created with my bare hands, where nothing like it existed before in the hardware space it commands.

For the curious, here is the some insight into my madness: MONOTONE development notes

One of the side effects of designing a tracker completely from scratch, using the best software design I can muster, is that everything is virtualized. A song is an object; the player engine is an object; the output device is an object. I’m probably going to make the editor an object itself, if just to keep the source consistent.  The nice thing about objects is that they can be abstracted and used as “parents” for descendant objects. So I have done just that for the internal speaker output. So that leads to some good news and bad news:

The good news is that the tracker will probably come with basic support for the Tandy/PCjr sound chip, and Adlib, and heck probably the CMS as well, out of the box, all in addition to the internal speaker.  This is because once the parent object is done, it’s easy to create a descendant for each output device.  And it will make it easier to add more complex internal speaker support in the future, such as mixing 3 or 4 voices realtime for “true” multichannel output from the speaker.  Just don’t expect the Adlib to sound better than the rest — I have a common denominator to target, and it ain’t 9-channel FM instruments.

The bad news about all this is that the tracker is still mostly in my head and not on paper. Which means I may only have a tracker to enter into the wild compo at Block Party instead of a demo. Or neither, considering that the presentation I’m giving takes precedence over compos :)

If I were never releasing the code, I could’ve hacked something together by this time already.  But I am, and I want people to be impressed by the code as much as music (democoder background, remember?  Both form and function are equally important :-)

I taught myself Pascal in high school. I was not admitted to the AP course my high school was offering due to my overall GPA, so I taught myself to 1. spite the arrogant jerk of a teacher who denied me, and 2. follow along with the course so I could spend time with my friends. I had been taught other languages (LOGO when I was 12, and BASIC when I was 13) so I wasn’t a stranger to programming. What I was a stranger to, however, was discipline.

My early code, which includes my early demo coding, is sloppy. Oh, the code is nice to look at and doesn’t contain spelling errors, but it is incredibly sloppy. Instead of using REP MOVSW to copy memory around, or even Turbo Pascal’s move() procedure, I would copy one array to another byte by byte. Instead of sorting an array by inserting an array set into a sorted binary tree and then copying it back to the array (heapsort), I would loop through the array and swap crap as necessary (bubblesort). Instead of learning how to use pointers, I would try to trick the compiler into giving me multiple data segments (which had the side effect of bloating the executable). Essentially, I lacked experience, insight, and wisdom — and my programs were buggy and slow as a result.

Today, nearly 20 years later, that is not the case. I still program in Turbo Pascal, but I use pointers/heap, objects, inheritance, and especially in-line assembler in places that need it. I understand proper data structures a lot better now (still struggling with tries, but I’ll get it eventually).  I write my code as if I am delivering it to someone else to maintain.  I can’t say that I am ashamed of anything I’ve written past 1997.

I mention all this because the PC Speaker tracker, something that most people bang out in a day, has taken over two weeks and I haven’t written more than 50 lines of code.   What I have done, however, is:

• Spent 3 hours writing up various design and structure ideas in a notes file
• Spent 2 hours last night laying in bed trying to visualize object-oriented tracker design while preventing playback performance from turning to shit (answer: a Song object that controls entering and retrieving note/effect data into the song, and a Player object that retrieves song data one row at a time… still thinking about this one, since a single object makes more sense, but would be harder to virtualize playback methods for other output devices)
• Spent an hour researching the frequency and amplitude characteristics of Vibrato (not just the human voice, but woodwinds and stringed instruments) so I could be sure to make the best use of the effect bits I have available (answer: most pleasing vibrato has a frequency within 4 to 7Hz and amplitude of about 10 cents)
• Spent an hour revisiting various tracker formats, looking for ideas on how to pack notes+volume+effects into two bytes (answer: 7 bits for note, 3 bits for effect, 3 for effect 1st parm, 3 for effect 2nd parm)

…but no code.  Yet.

I believe it was the demogroup Silents who proclaimed, “If you can’t do it better, why do it at all?”  That is simultaneously democoding’s greatest motto, motivator, and curse.

I couldn’t save my old XT keyboard (enter key died, and that’s pretty much the #1 most important key on the damn thing) so it has been tossed into the spare parts bin. My remaining keyboard, however, survived my pokings and I have a functional XT keyboard again. My last, but beggars can’t be choosers.

Thanks to a functional keyboard, I started working on MONOTONE again, starting with the interface (the design docs are done — yes, design docs — hey, stop laughing!) except that I was immediately sidelined by my custom keyboard handler.

A keyboard handler, for the uninitiated, is a little routine that “replaces” the “hold-key-down-and-watch-it-repeat-after-a-short-delay” behavior with “hold-key-down-and-it-stays-down-without-beeping-incessantly” behavior. This is good behavior, if you want to make your keyboard act like a piano. But my trusted old handler code locked up the machine after the first keypress.

Here is the code in question, which I had been using since 1994:

Procedure New9handler; Interrupt;
Var
  b: Byte;
Begin
  port [$20] := $20; {send end-of-interrupt to PIC}
  b := port [$60];   {read scancode from keyboard}
  If b < 128
    Then kbd [b] := True
    Else kbd [b And 127] := False;
End;

On keyboard interrupt, grab a friggin’ character and stuff it in a bitmask array. Easy as pie. Yet the XT locked up, so I am clearly doing something that the XT is allergic to (or, more likely, forgetting to do something). So now I get to research early XT keyboards/signals and try to figure out what I’m doing wrong. Luckily, I have a lot of programming books to consult; here are the ones I’m going to take to bed:

• Compute’s Mapping the IBM PC and PCjr by Russ Davies
• The Undocumented PC by Frank Van Gilluwe (founder of V Communications — thanks for Sourcer, Frank!)
• Sam’s IBM PCjr Assembler Language by David C. Willen (why a PCjr-only book? Because eventually monotone will support PCjr — ssh, keep it a secret!)
• Compute’s Beginner’s Guide to Machine Language on the IBM PC and PCjr by Christopher D. Metcalf and Marc. B. Sugiyama
• Assembly Language Primer for the IBM PC & XT by Robert Lafore

Overkill, but I want to check them all so that I can get all the info on handling a keyboard interrupt and then pick out what I need.

I know all this seems stupid and unnecessary, and makes me seem like a freak, but honestly it is the reason over the years I have gravitated towards older and slower platforms to code for fun on. It’s the same reason people still code demos on the Commodore 64 and other legacy platforms: They are fixed in nature, which means you can truly discover the absolute fastest way to accomplish a particular task on them. It’s impossible to do this on a modern winbox, because winboxen are moving targets. It also explains perfectly why modern demos have evolved in the last decade the way they have, but that’s a topic for another day.

PS: The last book by Robert Lafore is the best book you can read to learn assembler on an IBM PC. It teaches you the basics by making you assemble, by hand, in DEBUG. It sounds incredibly scary and hardcore, but it’s actually very fun!