Older blog entries for dto (starting at number 53)

School's going well so far. Earlier today I worked on Octal's pattern system, doing a partial rewrite of pattern.c. Now it has the ability to add mixing tracks to the machines. I am only weeks away from a beta test.

In other news, I heard that the source code to Buzz and Buzz2 were lost sometime last year. No backups??? A similar blunder destroyed the code to Ultima VII.

A lot of small things to do now...

• Finish mixer opcodes
• Adapt analyze_digraph() for AUX connections
• add long machine names / info in cboxes
• implement file format
• block GUI until registry is installed
• multiple-reciever event propagation
• amp/pan matrices
• standard mechanism for status... trace()?
• prototype tracker widget
• install kernel 2.4 and GNU-DDD :-)

Insane amounts of work on Octal --- see the new screenshots at

• this location and
• this other location

Lots of good stuff working. The Engine View, in which you can create, delete, connect, rename, and destroy machines, is nearly complete. Going along with it are multitrack-capable Control Boxes. You can pop one open for each machine, and interactively move the sliders. (Eventually there will be more widget types, including a 2-d one I'm planning.) These work with OX_API, and communicate with machine libraries to create the right display and give feedback as the slider is manipulated.

On the GUI to-do list:

• amp and pan controls, both in engine_view and control_box
• timing controls (tempo etc)
• pattern editor
• wavetable
• main sequencer

So far several of the operations are working in the engine_viewer. Perhaps I can get it finished for this weekend. I can tell that now that I've finished the IPC framework, everything else is just going to fall into place.

I put a screenshot at my home page. Damn, I am so pleased that this is working!!

First day back at school today--just one class, with Aparna. It's a Java/OOP/OOD class. Not really looking forward to Java given what I read about it, but...

Got lots more work on Octal done last night, part of the PAC bit is now working. Working on simplifying some bits. I hope to have more working tonight, as soon as I figure out some more GTK+ stuff. The old engine_viewer code is being adapted as its own little object.... all I need is to be able to somehow get the instance pointer from the gtkwidget parameter that's in the parameter list of gtk callbacks.

Code reorganized. Octal now compiles and sends stuff thru the pipes. Now all I have to do is connect the engine_model stuff to the view/engine_view. The GTK code I wrote looked great but now will need to be revised a little bit, since it must retain a model_cache and deal with updates thru pipes (handled by message tools.)

The code uses names like Model and View, but in truth the design went from MVC to Doc/View and then to Presentation-Abstraction-Control (where Control has nothing to do with MVC's "controller." See Buschmann's A System of Patterns for more info on the PAC alternative.)

At the moment I've refrained from renaming things to conform to PAC, because engine_abstraction_responder is too long and a little too opaque compared to engine_model_responder. I may be splitting hairs, but I feel very sensitive about how things are named :-).

Other News. My sleep schedule is pretty messed up. However my room is basically fully rearranged, and now I have space for the box, normal monitor and keyboard, and on another desk a VT510 console that is "free of distractions" and quite good for coding even if the only color is orange---plus, a full-size open desk space for doing homework on. Not bad. The VT even controls my CD player!

Here's my current plan for reorganizing the code. Header files are left out of the list, usually in same spot as C file.

octal/
	commands.c
	machine.c
	core.c
	output.c
	package.c   (was util)
	pattern/
		pattern.c
		pattern_model.c
	engine/
		engine.c
		engine_model.c
		mixer.c
	user/
		user.c   (was main)
		engine_view.c
		pattern_trackerview.c
		pattern_pianoview.c
		wavetable_view.c
	machines/
		squaregen.c
		delay.c
	wavetable/
		wavetable.c
		wavetable_model.c

 		

Note the model and view bits, alluding to the MVC-inspired architecture.

I am typing this in ithought, a neat program from voltron.

I finally decided how to name/split up/diddle the functions that are currently spread in engine_commands.c, engine.c and so on. I decided to let myself think a little more "object-wise", and picked up my worn copy of Design Patterns and sat for awhile. In accordance with the Doc/View model,

• Engine intrinsics go in engine.c
• Engine message interface definitions (enum, etc) go in commands.h along with other types of messages
• code for engine DOC responses go in something like engine_doc_imp.c
• code for engine VIEW responses go in engine_view_imp.c
• Audio mixing functions go in mixer.c

Later on there will be multiple VIEW's for patterns; most likely, one for tracker-style and one for piano-roll-style. I could place those in pattern-view-tracker-imp.c (um, maybe I want to shorten that??)

:-) wish me luck

don't bother looking for support if you have a big problem, all that's left is people who think they're the first to tell you to install debian

Got some Octal hacking done... made some nice simplifications. I realized that the engine_commands thing was getting too complex. I had a group of functions all with the same calling convention, and an array of pointers to them whose order matched an enumeration, and a dispatch function to call the appropriate handler for a message that basically packed the arguments and one of the enum values into a struct. Then I realized how complex this was going to get when both the core thread, AND multiple objects (different views) in the UI were going to react differently to the same messages.

So now the whole chebang is replaced with each "class" having one function to respond to all the messages (they all had the same prototype anyway.) A switch statement makes the right behavior happen according to which message is being recieved. It's not a traditionally accepted OO technique, that's for sure---switch statements are seen as a sign of improper OO design by some people. But I can't express how much simpler this is when written as a switch statement. All the message behaviors for a "class" are contained within a single function. The code that can be executed by user requests is clearly separated from internal helper functions that shouldn't be accessible to outsiders. And the function prototype is not repeated 13 times anymore, just once for the whole interface function.

I have never found inheritance interesting or useful other than to implement interfaces. This is especially convenient now that I'm back to plain C, since C is good at interfaces and little function packages (but not so good at inheritance.) Decoupling inheritance and polymorphism seems like a win. I guess this is what people mean when they say "inheritance breaks encapsulation." But that doesn't mean it's all bunk.

Last night at 4 AM I installed RH7, wiping out my root partition in the process. I kept all my /home files, as they were on their own section. Now I have a three-partition setup, for /, /usr/local, and /home.

What a mess, though. Here's what I have to do to get back to normal:

• install kernel 2.4
• install XF86 4.0.2
• install USB Graphire tablet drivers
• Install Gimp 1.2
• possibly install Eazel even though it requires 2^73 other packages
• install Blackbox
• install Helix-Gnome but then undo most of the things it does (auto X startup etc) and NOT run sawfish
• set up soundcard
• set up GPM for Graphire
• set up my usb joystick
• set up Kerberos for use with my GNU account
• see if I can get some 3-d support going

This time I need to do things right.... making proper backups of config files, and making notes on installation processes so that I can remember how I did things. I know I'll need to re-learn how to install the Graphire device, and tweak the settings.

At the end of the century we've watched the "Big Three" long-running sci-fi and fantasy institutions collapse and run out of steam:

• Ultima
• Star Wars (yes it is dead)
• Star Trek (this one too)

Star Trek has the distinction of just gradually fading out, whereas the other two had spectacular failures... worthy of ridicule for generations to come. (I realize Star Wars isn't officially over yet, but only Spielberg and a real screenwriter could possibly save this sinking ship.)

It's pretty disappointing; I don't get the feeling that Farscape and LEXX are going to provide the same kind of sustenance. Oh well. Maybe real tile-based games will be in vogue again, or perhaps interactive fiction will come back in a big way.

Yeah, sure.

Oh, and yakk, I kept this short just for you :-).