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

[Patrick E. <pa...@pa...>]

On Friday 26 March 2004 06:16, Dave Fancella wrote:
> 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.

I meant managing the files on my file system.  They could all be 
placed in a single directory, but if you wanted to stick a song on a 
web page or something, you'd need to tar them up.

I'd rather have a little dialog that allows you to copy segments 
between projects.  Could be as easy as dragging them around.  Select 
one song on one side, another song on the other side, drag the 
appropriate segements.  If you don't copy the segment, you might even 
accidentally change a segment that was used in another song.  Having 
to think about all those independent segments doesn't sound like a 
lot of fun to me.

In the dialog approach, it would be helpful to have a "play" button to 
see which segment you're dealing with.  I don't really want to have 
to come up with memorable names for all the little pieces of my 
music.  In fact, I rarely want to come up with names for any of my 
music. :)

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

I like the idea of having segments that can do relative volume 
adjustments, loops, and whatnot.  However, I still don't believe each 
segment deserves its own file.

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

How are history storage, journaling, and block files not orthogonal 
issues?  I don't really see the advantage of many small files unless 
you write a poor history system and it crashes in the middle of 
writing to the large file.

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

I don't think many midi segment files are needed to be interoperable 
with Audacity.  I personally don't even think that Audacity's track 
handling extends well to the midi world.

> 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!).

I'd say a good XML format would be easier to manipulate and more 
extensible than either a dir full of files or an archived set of 
files.  There's nothing tricky about sticking a bunch of <segment> 
things in a midi file.  XML also allows recursion, so nesting isn't a 
problem.  Segments could even be given names, just like in the file 
system.  If somebody wanted to manipulate the file, they wouldn't 
have to find an archiver or read a directory listing of files along 
with another project file.  They could use a tool as simple as a text 
editor or as complex as XSL.

        Patrick