12 Jul
2004
12 Jul
'04
8:26 p.m.
Hi,
I'm writing a pattern-based audio sequencer, and wonder about the file
format to choose when saving the whole song. My application handles the
usual stuff : metadata (bpm, settings), patterns, and samples.
Do you believe I should use (yet another) binary file format, embedding
patterns, samples, and possibly roasted chicken into a big standalone
(that's the good point) package ?
Or may I produce an XML file (doesn't <pattern> looks nicer than
[pattern] ? ;), with an option to mimic the save "Web-page, Complete"
mozilla behaviour ?
That is, when saving song.xml, sticking a song.xml.files/ folder in the
same directory, to store samples.
--
og
13 Jul
13 Jul
7:59 a.m.
On Tue, Jul 13, 2004 at 12:16:49 +0200, Olivier Guilyardi wrote:
Or may I produce an XML file (doesn't
<pattern> looks nicer than
[pattern] ? ;), with an option to mimic the save "Web-page, Complete"
mozilla behaviour ?
That is, when saving song.xml, sticking a song.xml.files/ folder in the
same directory, to store samples.
This is what audacity and ardour do, it works pretty well.
- Steve
2:30 p.m.
Steve Harris wrote:
On Tue, Jul 13, 2004 at 12:16:49 +0200, Olivier
Guilyardi wrote:
Thing is, the .mod-like standalone way of storing things still seem
pretty reliable to me. You'll never end up losing a part of your song.
Maybe that instead of yet-another-binary-format, I could use an existing
such binary format. But there are a few essential requirements:
1 - no limit on pattern length
2 - pattern nesting : a pattern's track can use another pattern as
instrument instead of a sample
Do you know of a binary format that would meet both of those ?
--
og
That is, when saving song.xml, sticking a
song.xml.files/ folder in the
same directory, to store samples.
This is what audacity and ardour do, it works pretty well. 
3:15 p.m.
On Tue Jul 13 18:20:14 2004 Olivier Guilyardi wrote:
Steve Harris wrote:
What about the OOo variant?
Put everything in a directory and make a tarball on the fly.
That way you could always unpack the whole archive using standard tools
and edit your text files.
You could even use somethinkg like FLAC for the audio part...
--
Jan Weil
http://linuxaudioblog.jawebada.de
On Tue, Jul 13, 2004 at 12:16:49 +0200, Olivier
Guilyardi wrote:
Thing is, the .mod-like standalone way of storing things still seem
pretty reliable to me. You'll never end up losing a part of your song. That is, when saving song.xml, sticking a
song.xml.files/ folder in the
same directory, to store samples.
This is what audacity and ardour do, it works pretty well.
4:36 p.m.
Jan Weil wrote:
What about the OOo variant?
Put everything in a directory and make a tarball on the fly.
That way you could always unpack the whole archive using standard tools
and edit your text files.
You could even use somethinkg like FLAC for the audio part...
Yeah I thought about this, and I will definitely give users the FLAC
option at some point or another. The problem with the tarball is time
and space :
Imagine you're using some 15 megs samples (a 3 minute live track for ex.)...
1 - you create a tmp directory, and copy you samples in there : you
already use twice space, and had the time to smoke a cigarette
(dangerous, you could start smoking ;)
2 - you create a tar archive from that ; second cigarette, and about 2
and half times disk space (assuming gz'ed) ; then, of course you delete
the tmp directory , but it's been a hard time
Thing is, text processing with OOo usually does not require big files,
and yet it does save slowly.
I looked around for some solution to create a tar/zip archive on-the-fly
from the memory (yeah, I load the 15 megs in ram), but couldn't find
anything... Is there a lib, or something ?
--
og
9:09 a.m.
Jorge García wrote:
I think zlib does that,
I can't see anything about archiving files in zlib.h, it's only about
compressing data. But I just found this one :
http://www.feep.net/libtar
It looks very nice and simple. And it seems I could do on-the-fly FLAC
compression, while on-the-fly-writing the tarball itself.
--
og
11:22 a.m.
Olivier Guilyardi wrote:
Jorge García wrote:
See also zziplib. From the README:
PROJECT
The zziplib provides read access to zipped files in a zip-archive,
using compression based solely on free algorithms provided by zlib.
It also provides a functionality to overlay the archive filesystem
with the filesystem of the operating system environment.
...
HOMEPAGE
The zziplib project is hosted at SourceForge, the complete
documentation can be found at http://zziplib.sf.net - the
SourceForge servers are also used to distribute the sources
of the zziplib project. Releases are announced via the
freshmeat services on http://freshmeat.net/projects/zziplib
I think zlib does that,
I can't see anything about archiving files in zlib.h, it's only about
compressing data. But I just found this one :
http://www.feep.net/libtar
It looks very nice and simple. And it seems I could do on-the-fly FLAC
compression, while on-the-fly-writing the tarball itself.
13 Jul
13 Jul
11:05 p.m.
On Tue, 2004-07-13 at 12:20, Olivier Guilyardi wrote:
Steve Harris wrote:
Why not do what Open Office (and a bunch of others do) and do the xml +
directory of files thing and just throw it all in a .tgz?
All the benefits of the plaintext way, with everything in a nice little
package.
-DR-
On Tue, Jul 13, 2004 at 12:16:49 +0200, Olivier
Guilyardi wrote:
Thing is, the .mod-like standalone way of storing things still seem
pretty reliable to me. You'll never end up losing a part of your song.
Maybe that instead of yet-another-binary-format, I could use an existing
such binary format. But there are a few essential requirements:
1 - no limit on pattern length
2 - pattern nesting : a pattern's track can use another pattern as
instrument instead of a sample
Do you know of a binary format that would meet both of those ?
--
og That is, when saving song.xml, sticking a
song.xml.files/ folder in the
same directory, to store samples.
This is what audacity and ardour do, it works pretty well.
7532
days inactive
7534
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
6 participants
participants (6)
-
Dave Robillard -
Greg Lee -
Jan Weil -
Jorge García -
Olivier Guilyardi -
Steve Harris