Older blog entries for dto (starting at number 58)

I've been sick this week... I finally got that bug that was going around seemingly everywhere. My family all got it, all the Computer Science faculty got it, and now me :-(.

I'm getting over it though. I have so much to do!

Ari and I watched Silence of the Lambs last night. It's our favorite movie, and we wanted to get up to speed in preparation for the release of the sequel next week. Pretty exciting!

I don't know what it is about printing out code to reread it and make notes with a pencil. I find it clears my head, lets me see the code in a new light. Lots of fun. I also printed out Owen Taylor's GTK drawing tutorial, as it shows how to do backing stores to prevent flicker. I'll probably take these pages all to bed tonight to read.

I've been using Nautilus for about 2 days now. Pretty schweet. This app has a lot of potential. Now that I have kernel 2.4 running, my IDE chipset can run in the much faster DMA mode. My machine is noticeably a bit more peppy.

Getting Better All The Time

I rearranged the control_box API. The previous setup was causing impossible-to-find bugs... the storage was managed by engine_view, and there are just too many combinations of machine deletion / machine creation / slot reuse, too many events to get the engine viewer to deal with it correctly itself.

My solution was to make the control box totally manage its own storage, to the point where, when deleted, it nulls out the pointer that points to that storage. In addition, cb_create does nothing in the event that you try to create two control boxes for the same machine. When the control_box is either closed or when its machine is deleted, the GTK resources and memory are freed and the pointer is zeroed out. So there is never a dangling pointer around, despite the different kinds of events that can cause a box to get destroyed.

I guess the idea is that control_box really knows best when it should be destroyed, so why make another object understand it?

Octal 0.8b release thoughts

I have a few more changes to make to OCTAL's API before releasing it. They are all small, and if I can get the docs done I will release them on Sunday (tomorrow.) I'm thinking of revamping the use of "machine::state", and making it more like GTK+'s use of "user data". I'd rather just pass it as the last parameter to all the instance functions, and have them do a quickie cast like my_struct *s = user_data;.

Here is my master list of things coming in 0.8b:

  • Adopt the GTK-style naming convention for all the enumeration constants.
  • Draft of the machine writer's guidelines---about naming conventions, ensuring archival file formats, ideas on a possible OXAN repository...
  • Hopefully some preview code for multiple widget control types in control_box. I would like to have at least trigger buttons work before releasing. I will try to get some consistent handling of creating different widget types, perhaps with a function accepting the OxWidget number and returning a gtk_widget* with its signals and data already connected. Perhaps the names for this data could always be the same, and a single callback can handle all widget types (much like the current one retrieves some data items from the widget's adjustment, widgets without adjustments could benefit from the same thing.)
  • Version and Is_Beta fields in machine types
  • Rename to Octal SDK or something
  • stubs/docs for the wavetable extension

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? :-)

23 Jan 2001 (updated 23 Jan 2001 at 08:40 UTC) »

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

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
Success.

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!

49 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!