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

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

On Saturday 27 March 2004 07:20 am, Patrick Earl wrote:
> 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.

Only if you wanted people to work with the project you created.  You could 
otherwise export it to a single file.

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

This dialog and the blockfile approach aren't mutually exclusive.  We'd just 
have to define the default behavior or just decide that this case counts as a 
write and the segment should be copied even if it hasn't changed.

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

I'd like some way to be able to look at a segment and know what it is, but I 
agree with the naming thing here.  :)  It'd be nice if a segment just said 
"verse" or something, and Jazz knew enough about song structure to either ask 
you what the thing is, or just guess and guess right.

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

As long as it can be managed well, but consider that you could be looking at 
50+ segments each with its own settings separate from the track settings.  I 
can't hold that much information in my head (well, I can, but when I'm 
working on a song I'd rather not have to hold that information in my head at 
all).  I'd prefer an envelope instead, it's much simpler and easier to grok 
visually, and you don't have to hold any information in your head because the 
envelope is clearly visible in the GUI.

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

Well, around here, in high winds, brief losses of electricity are not 
uncommon.  In fact, just a month ago or so we lost power for two hours or so.  
I can't even count how many hours I've wasted rebuilding lost work when the 
power went out.  Whether that's because of poorly-written history or just bad 
design that prevents a well-written history, I don't really know.  (I am, of 
course, talking about several apps spread across a variety of purposes)  So 
naturally I'm worried about loss of data quite a bit.  :)  (RoseGarden 
crashes frequently and its autosave feature isn't adequate to the task)

So basically I don't want to have the whole project stored in memory at all 
times unless it's done solely for optimization.  If the project is an xml 
file, frankly I don't see how it can be dealt with efficiently and still save 
its state to disk with every edit, because for every save we'd have to 
compose a new xml file that doesn't resemble the old one a lot.  With the 
blockfile approach, we can have a history stored in its own file that we can 
open for append, push state, and close (I'm willing to let the OS handle 
flushing the IO buffer at this point).  We create our new blockfile, keeping 
a copy of the old blockfile, and we only have to save the xml project file 
when the user asks to save it.  We can rebuild the project file from the 
history file, and all the actual musical data is preserved as well.

I'm also not sure I answered your question.  :(  I think I did, though.  :)

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

It may not.  Mind you, Audacity is dealing with much larger files than we are, 
and their approach is excellent for it.  WIth other programs that store the 
entire project in one huge interleaved wav file, or each track in its own wav 
file, when you apply an effect to a selection the program has to load the 
whole file and loop through it doing nothing to get to the selection, then 
loop through it applying the effect, and then loop through it again doing 
nothing but saving the old data.  A wav file for one track can easily be 
20MB, and with 8-9 tracks (average for me), you quickly exceed available RAM 
and swap space combined.  We don't have that problem here at all.  :)

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

Yes and no.  The main problems I see with using one single file are history 
and having the whole project in RAM.  Yes, we can carefully work out the 
format to put history in it, but in order to write the history we have to 
write the whole project, so with every edit (to have my file-based history) 
we'd have to write the whole project.  That may not be as annoying as I'm 
thinking it will be, though.  The way I see it, either one or the other needs 
to be on-disk.  All the other benefits I'm touting could probably be achieved 
another way, I'm not doubting that at all.

Now, I'm pretty sleepy right now, so I won't be surprised if I read this 
tomorrow and it doesn't make any sense.  ;)  So I figure we should probably 
cut it off, I don't have anything new to add to the discussion that wouldn't 
end up being arguing just for the sake of being right and proving I'm an ass.  
As Joakim pointed out, we're a ways from doing anything with the project 
format anyway, so we can let it cook for awhile and see what comes up.  :)  I 
promise not to implement anything for the project file without bringing the 
subject back up for discussion.  ;)  Normally I say "Write it however I want, 
it's easier to look at it and say what's wrong and fix it than it is to write 
something that's perfect the first time", but this is an area we need to try 
to get perfect the first time.  Users (me, especially) hate it when you have 
to change the project format for any reason.

Dave

>         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

Suaviter in modo, fortiter in re.
Se non e vero, e ben trovato.