Older blog entries for dto (starting at number 55)

I fixed the bug (for now) that was causing incorrect text rendering in engine_view.c. Not setting the GC clip rectangle makes it go away. I wonder why... aren't I supposed to do this?

I made sure the GUI blocks until it recieves a ready message from the core.

I added some ideas to mvcpac.txt. I now have in mind a simple mechanism for propagating core events to multiple viewers, and it will be very simple to replace the working-prototype forwarding mechanism with this one.

Now that I think of it, the bandwidth problem is solved. As long as we keep track of which machines are being observed, we can have the core send param updates thru the pipes only so often. Perhaps on a rotating basis. It's only being done to give an idea of what is going on inside the core thread, it's not supposed to have perfect accuracy.

As for play-position... I may be able to just use a global variable and lock it with a mutex. Or if the user thread never actually updates this integer, I may be able to skip the locking.

I gave the Octal project page at GNU a little bit of a makeover and added a new link or two.

Have no idea what I'm doing about the show coming up... I presume I will be ready in time. :-) I have several weeks, so I am not that stressed. There is some kind of web-ad at c-fom's page. Nice, top billing :-) even if it is alphabetical...

We had our first meeting about the Mobile Robotics senior independent study. Went very well, I'm even considering writing a kind of flow-network editor for doing subsumption architectures on the handyboard. The UI certainly wouldn't be very hard--I just did something MORE complex and it was not difficult. The only tricky part would be converting the flow networks into inputs for some kind of C code. I think this would be hard, because by default this thing runs a weird dialect of C where pointers and arrays aren't interchangeable and I don't think it even has function pointers. In other words, it is basically Pascal77. Sucks.

There is a GCC port to the Motorola 6811 and people do compiled programs for it, so perhaps I will check this out.

I'm listening to an excerpt from the live show in NYC jan 2000. Wow... has it really been a year since then? :-)

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