From: Dave F. <dav...@co...> - 2004-03-26 10:26:40
|
On Friday 26 March 2004 09:47 am, Joakim Verona wrote: > >Ultimately I'd like to have Jazz using its own project file format and > > reading midi files will be done by importing the file. There are bad > > reasons to do this, and good ones. Mainly I want to be able to embed wav > > data in a project file, and have a good open project file format that > > will allow easily adding patterns, templates, and stuff, and easily > > support multiple midi devices in the studio (similar to RoseGarden, in > > fact as a proof-of-concept when we get there, someone (me?) should write > > an importer for RoseGarden projects). > > Yes, Jazz would need its own format at some point. > > Something I did with Jazz was to add the facility to play tracks from > other tracks, > a playtrack event. This was a feature in a sorely-missed amiga sequencer > I used, Music-X. Heh, never used Music-X. MeD was a lot of fun, though. ;) (DMCS also had an unbeated staff editor, the likes of which I haven't seen again but has probably been bested) > This doesnt entirely fit with the normal midi-file standard(although > there are sequence play midi events), > so i kind of kludged it in in Jazz midi format :-P > > Anyway, these kind of features would be easier with a new format. > > I would advocate looking at existing formats before inventing something, > like > music-xml or something(music-xml has taken some flak, but it can't be > all bad can it?) Actually, the specific format I was interested in is adapting Audacity's project format. Audacity, being a sound editor, has serious problems dealing with memory and the raw amount of data it processes. But they've solved a number of problems relevant here, like having unlimited undo across saves. Anyway, we don't have the same memory problems with midi, since a midi file is small enough that we can probably put a hundred in memory at one time. Anyway, I want to adapt their blockfile approach. So, Audacity has a data directory for the project, and a project file. The project file is xml and it tells what order the files in the data directory go in, what tracks they belong to, and so forth. I think the project file also stores the history queue. 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. 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. :) Dave > An xml based aproach would open up for many cool concepts, like using > XSLT transforms > for midi event processing, which could be re-used in other projects. > > One of my ideas for Jazz is to open up for plugins and so on that > manipulates event data, > like GIMP:s python, scheme, and perl interfaces. > > > Cheers, > Joakim > > >Dave > > ------------------------------------------------------- > 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 You now have Asian Flu. |