Re: [jazzplusplus-devel] It's a night. Reduced trackwin's global variable dependence

[Dave F. <dav...@co...>]

On Friday 26 March 2004 04:19 pm, Patrick Earl wrote:
> On Thursday 25 March 2004 19:26, Dave Fancella wrote:
> > So, what I want to do with Jazz is store blocks of midi data in
> > midi files, one track to a file, and organized in blocks of data.
> > We don't need this for the RAM, but it would be useful for pattern
> > support and unlimited undo.  I want to use their exact project file
> > format, extended to support midi blockfiles, and derive from their
> > BlockFile class to create midi support.
>
> Does that mean there would be a file for each track in a song?  That
> doesn't impress me much at all.  I know I'll have many songs, and
> having to manage each track sounds like a real annoyance.

Yes, there'd be a file for each track in the song, and you won't have to 
manage each track, jazz would manage it for you.  The xml file describes how 
to assemble the blocks into a song, and jazz does the assembling.  It 
simplifies the backend (with some upfront implementation overhead) by 
allowing us to modify certain sections of a track, create a new blockfile for 
it, update the project in memory, and then when we write it to xml it's done.  
And we'd need some method of pushing the project state after each edit to 
maintain history.  History in this setup is entire project history and there 
isn't any way to deal with individual track history, but we could certainly 
work something out to do it, if we really wanted to.

> I would rather that for midi data at least, the "song" files contain
> all of the track data.  Moving individual tracks between song files
> would be a useful operation, and you could always copy the history
> data along with the track itself.  Tracks could still be
> self-contained, but they needn't use multiple filesystem entries.
>
> Blocking midi data also doesn't make a lot of sense to me.  In an
> audio file, what you have is a sequence of random bytes, so dividing
> it up into smaller pieces can help with management.  However, with
> midi, everthing is well defined, so it makes some sense to define
> history events in terms of the midi data itself.  For example, you
> can say something like:
>
> Note On C4 added at location 2035.
> Note Off C4 added at location 2055.
>
> Section 1034 to 1500 deleted (previous data: XX XX XX XX XX)

Blocking midi data itself isn't that useful, admittedly.  What I'm thinking is 
that when we have segment support (or patterns), we'd store one segment of 
music in one file.  The project file will define which midi channel and 
instrument to play it with.  The project file will also define when to play 
that segment.  Presumably the user will use a segment multiple times in the 
song, and will even use the same segment on multiple tracks (I do that a 
lot).  Then we have the option when the user edits that segment to either 
copy-on-write, or edit the base segment.  Copy-on-write means only the 
segment in the specific location in the song gets edited, leaving all other 
instances of the segment unaltered.  Editing the base segment means every 
instance of that segment in the song gets edited.

If a track isn't split into segments, then the track can exist within one 
single blockfile.  Blocking midi data doesn't make sense in this case and 
having the whole track in one file makes perfect sense.  (Mind you, it's 
common for an audacity project to become greater than 1GB in size.  That 
should *never* happen with midi data.  I'll be impressed to see a project > 1 
MB of midi data)

We still have to deal with mixing, but this setup allows us cascading-style 
volume and pan controls, volume and pan envelopes (since the blockfiles 
wouldn't necessarily contain that information), and other things I haven't 
even thought of.  Surround-sound?  In each of these cases, it's just a matter 
of making entries in the xml file that describes the project and the 
underlying midi data doesn't get affected in any way.  One place where 
RoseGarden specifically is very weak is in handling track-level pan and 
volume, and then dealing with segment-level pan and volume (mostly it looks 
like UI issues, but there's so many bugs in that program it's hard to 
distinguish what they intended to happen from what is happening).  In this 
fashion we'd define track-level pan and volume as applicable for the whole 
track, and changes would be notated by position in the song and independent 
of song layout.

We also get some added stability, or at least recovery from error.  Currently, 
it seems that midi sequencers just load all the midi data into memory, which 
is fine because it's so small that it's reasonable to do so.  Then, if the 
program crashes, or the power goes out, or something, you lose *everything* 
since your last save.  Autosave deals with this to some extent, but autosave 
is built-in to the blockfile approach.  Since we push onto the history queue 
after every change, recovery from error is just a matter of checking the 
timestamp on the project file and reading the history queue after that 
timestamp to rebuild the project in-memory.  We've now spread our dependence 
out over several files.

And, of course, in the long-term we get interoperability with Audacity, and 
there is a fair amount of complaining going on that there's no free as in 
speech midi sequencer/audio editor while all the proprietary offerings are 
combining midi sequencing and audio editing.

We do pay the price of having our own special project format that no other 
application knows.  We can easily port the code to audacity, though.  One of 
Jazz's strengths right now is that it works with midi files rather than using 
it's own special file format, so no import/export step is needed.  We also 
pay a price in the directory hierarchy by having many filesystem entries when 
before we'd've had only one.  Filesystems are generally fast enough that this 
shouldn't be an issue, though, but we can certainly have some sort of attic 
like cvs to stick old files in.

But I think the system is inherently more extensible and more powerful than 
any single-file format we could design, and I'd prefer to build knowing that 
what I'm building will allow many additions in features to the program with 
very little change in the backend storage facility.  Hell, the code I write 
in the next few weeks might go untouched for years (ha!).

Dave

> > It has the disadvantage of having the project spread out into a
> > bunch of small files.  We can optimize for that, since midi files
> > are so small we can still load the whole project into memory, and
> > just clear out memory when something gets pushed to the history
> > queue.  There might be other ways to approach the problem of having
> > all these files strewn about a directory hierarchy, but I think the
> > advantages far outweigh the disadvantages and am fully prepared to
> > defend this idea.  :)
>
> Okay, let's hash it out. :)  My opinion is that it's good if midi
> tracks are self contained entities and there are multiple tracks
> within a single song file.
>
>          Patrick
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> jazzplusplus-devel mailing list
> jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel

-- 
Visit my website!
http://www.davefancella.com/?event=em

Robert Tappen Morris, Jr., got six months in jail for crashing 10% of the
computers that Bill Gates made $100 million crashing last weekend.