A New Music » loading

Loading & Saving Structures with Object System

Josh Parnell — Sun, 21 Mar 2010 23:28:52 +0000

Now that I’ve got the engines out of the way, there’s really only one major thing standing in the way of a new GGrewve: data handling between sessions. All these well-organized data structures look great inside a compiler…but one glaring downside to using object-oriented programming over my previous “hack-ish” data system is that loading and saving are no longer as easy as writing the data structure to a file – because such an operation isn’t well-defined for arbitrary structures like it is for a data structures that consists of one large string (GDS and OS structures from the AHK code). Loading and saving the structures from the c++ library requires a custom interface for each structure which is, to put it plainly, no fun at all.

For backwards compatibility, I’ve chosen to write all structures in Object System’s encoding format. It’s not nearly as efficient as binary data, but it takes a lot less work to handle the data in lesser languages like AHK. After writing a c++ version of the OS data system, to which most of my day today was devoted, reading and writing arbitrary data structures now consists of implementing an OS conversion interface for each structure. That is, each data structure must be given a function for converting its data to Object System format as well as a function for loading its data from an Object System structure.

It sounds pretty straightforward, but in complex engines like gMSE in which structures are nested within structures that are, in turn, nested within superstructures, the task gets daunting. Nonetheless, I’ve finished implementing loading/saving for all MSE structures and am in the process of writing the function for the gMSE space.

After loading and saving are out of the way, it should be relatively smooth sailing to the new GGrewve.

Structural Updates & Touch-Ups

Josh Parnell — Tue, 19 May 2009 21:06:31 +0000

Several fixes and minor changes are going on in the mainframe. Loading and saving have each been completely reworked to use the GDS data system instead of INI file storage. The result is a smaller file that is easier to work with. The plugin loading algorithm has also been tweaked to no longer function on absolute paths but rather on relative ones. Now I won’t have problems loading the project files I saved on my laptop into my desktop’s mGen (previously the project files were not transferrable because of the differences in the file path names on my two systems, even though the differences are not at all relevent to mGen).

Saving & Loading

Josh Parnell — Mon, 16 Feb 2009 20:08:55 +0000

Although it might not seem likes a big step, the ability to save and load project data is pivotal in almost every program. Imagine having to always type an essay in a single sitting, and then having to retype it when you want to make corrections. We simple wouldn’t be able to function efficiently without the ability to save and load.

Today I finished a basic saving/loading system that allows my program to save project files and load them again when the user wants. The system saves all instrument and composition data, including all the individual plugin configurations. It wasn’t an easy task, but it works, and it makes testing everything a lot easier, since now I can simply make a save file that contains the configurations for all my testing instruments and use it over and over again.

Progress!