6 Jun
2007
6 Jun
'07
1:16 p.m.
Wonderfully, the linux audio opensource field has become nicely populated.
Opensource means freedom of choice. One is not tied to that $400 proprietary
bloated DAW program. Comes jack and one can dissect the functionality and
network smaller pieces (if one's system can handle the multiple processes).
Trememdous freedom of choice.
Problem is: No DAW program, opensource or otherwize, interoperates with any
other. Cakewalk works with Cakewalk, Cubase with Cubase, Ardour with Ardour,
etc. Each has its strengths and each has its adherents. Never the 'twain do
meet. (Lash is fine but the restriction remains.)
Proposal: OpenDAWS.
Just as Sun's Openoffice is not using what they call an open document format,
we need a open digital audio work-stations format. Such would enable us to
work in Ardour when this suits us, Rosegarden or Muse or LMMS or Traversa or
Qtractor or whatever works best for the song. It slso opens doors [SIC] for
collaboration with those using another program with no regrets.
Base it on XML, easy to parse with any number or os parsers around. Something
like:
<requires>
<file ....../>
<file ....../>
</requires>
<track id=1 name=piano type=midi ....>
<clip id=1 type=hexmidi>.......
</clip>
....
</track>
<track id=2 name="lead vocal" type=audio ....>
<plugin name=ladspa-compressor knee=## ratio=#.# ......./>
....
<clip id=1 type=audio-link file=vocal.wav from=##### to=####/>
<clip id=2 type=....../>
....
</track>
Step 1: Specify the XML DTD.
Step 2: Subclass a C++ XML Parsor (and Java--would look more or less the
same).
Step 3: A bare open room -- program to read and play such an animal using
jack. No GUI, no editing, just read and play to demonstrate concept. Do
plugins get set up here or manually using some jack patchbay? Both (if in the
xml, do them, but I can easily enough plug in others)?
Step 4: Get opensource (and proprietary) authors to support this format and
even go over to it.
What say you?
6 Jun
6 Jun
1:31 p.m.
On Wed, 2007-06-06 at 18:16 +0300, David Baron wrote:
Wonderfully, the linux audio opensource field has
become nicely populated.
Opensource means freedom of choice. One is not tied to that $400 proprietary
bloated DAW program. Comes jack and one can dissect the functionality and
network smaller pieces (if one's system can handle the multiple processes).
Trememdous freedom of choice.
Problem is: No DAW program, opensource or otherwize, interoperates with any
other. Cakewalk works with Cakewalk, Cubase with Cubase, Ardour with Ardour,
etc. Each has its strengths and each has its adherents. Never the 'twain do
meet. (Lash is fine but the restriction remains.)
Proposal: OpenDAWS.
its actual name is AAF-XML. please google it.
--p
2:15 p.m.
On Wednesday 06 June 2007, Paul Davis wrote:
On Wed, 2007-06-06 at 18:16 +0300, David Baron wrote:
Just did. Anyone interested outside of Macintosh stuff?
I would like to see either a DTD or an easier to read outline of this thingie.
It has been around a few years now without much activity outside of a small
circle of friends it seems.
Wonderfully, the linux audio opensource field has
become nicely
populated. Opensource means freedom of choice. One is not tied to that
$400 proprietary bloated DAW program. Comes jack and one can dissect the
functionality and network smaller pieces (if one's system can handle the
multiple processes). Trememdous freedom of choice.
Problem is: No DAW program, opensource or otherwize, interoperates with
any other. Cakewalk works with Cakewalk, Cubase with Cubase, Ardour with
Ardour, etc. Each has its strengths and each has its adherents. Never the
'twain do meet. (Lash is fine but the restriction remains.)
Proposal: OpenDAWS.
its actual name is AAF-XML. please google it.
2:20 p.m.
On Wed, 2007-06-06 at 19:15 +0300, David Baron wrote:
On Wednesday 06 June 2007, Paul Davis wrote:
you found the wrong AAF, alas. i don't believe that this is a
coincidence, btw - i suspect Apple knew precisely what they were doing.
AAF is not the apple spec, its the "Advanced Authoring Format", an
industry standard. the new XML version is very new (not released yet)
but will be massively better than the existing one.
--p
On Wed, 2007-06-06 at 18:16 +0300, David Baron
wrote:
Just did. Anyone interested outside of Macintosh stuff?
I would like to see either a DTD or an easier to read outline of this thingie.
It has been around a few years now without much activity outside of a small
circle of friends it seems. Wonderfully, the linux audio opensource field has
become nicely
populated. Opensource means freedom of choice. One is not tied to that
$400 proprietary bloated DAW program. Comes jack and one can dissect the
functionality and network smaller pieces (if one's system can handle the
multiple processes). Trememdous freedom of choice.
Problem is: No DAW program, opensource or otherwize, interoperates with
any other. Cakewalk works with Cakewalk, Cubase with Cubase, Ardour with
Ardour, etc. Each has its strengths and each has its adherents. Never the
'twain do meet. (Lash is fine but the restriction remains.)
Proposal: OpenDAWS.
its actual name is AAF-XML. please google it.
2:22 p.m.
It seems a bit sad that any Linux advocate should be backing this operation,
it would cost about $1500 per year to get access to any kind of support for
the SDK or advice on best practices and cosiderably more if you really want
to participate. You could stump up $175 per year yourself to propose changes
as long as you can find somebody paying the full price or more to back you.
It is a commercial directive not an open movement. From a perspective of
Linux audio it is already a pain that the Midi Manufacturers Association
want cash for their specifications.
So is the argument for this specification will be 'the professional
applications will be using it' hence it becomes the standard?
The whole specification is delivered outside of a GPL, products using its
specifications are expected to pay royalty licensing and as such should not
be advocated as a part of any open source movement.
The proposal here was for an open format, not a closed consortium format,
the difference may be subtle and is apparantly lost on some people.
N.
From: Paul Davis <paul(a)linuxaudiosystems.com>
Reply-To: paul(a)linuxaudiosystems.com,A list for linux audio users
<linux-audio-user(a)lists.linuxaudio.org>
To: A list for linux audio users <linux-audio-user(a)lists.linuxaudio.org>
Subject: Re: [LAU] Proposal: OpenDAWS (long)
Date: Wed, 06 Jun 2007 11:31:48 -0400
On Wed, 2007-06-06 at 18:16 +0300, David Baron wrote:
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Wonderfully, the linux audio opensource field has
become nicely
populated.
Opensource means freedom of choice. One is not
tied to that $400
proprietary
bloated DAW program. Comes jack and one can
dissect the functionality
and
network smaller pieces (if one's system can
handle the multiple
processes).
Trememdous freedom of choice.
Problem is: No DAW program, opensource or otherwize, interoperates with
any
other. Cakewalk works with Cakewalk, Cubase with
Cubase, Ardour with
Ardour,
etc. Each has its strengths and each has its
adherents. Never the 'twain
do
meet. (Lash is fine but the restriction
remains.)
Proposal: OpenDAWS.
its actual name is AAF-XML. please google it.
--p
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
2:48 p.m.
Yes, an open, simple to do and understand format for DAWS. Video might come in
some time in the future.
What I am interested in could be made by simplest application in an editor.
Byte-boundaries in audio files (that's how Cakewalk does it) would require
software, at least to show the boundaries for entry. MIDI files could be
accessed by track and times rather than raw or hex data. Also there are MIDI
assembly languages around.
What I have in mind is not overly ambitious, not an attempt to solve the
world's advanced authoring needs in a huge expensive and propietary manner.
I would still like to see the spec, DTD or some outline of the schema. But I
am interested in opensource!
It seems a bit sad that any Linux advocate should be
backing this
operation, it would cost about $1500 per year to get access to any kind of
support for the SDK or advice on best practices and cosiderably more if you
really want to participate. You could stump up $175 per year yourself to
propose changes as long as you can find somebody paying the full price or
more to back you. It is a commercial directive not an open movement. From a
perspective of Linux audio it is already a pain that the Midi Manufacturers
Association want cash for their specifications.
So is the argument for this specification will be 'the professional
applications will be using it' hence it becomes the standard?
The whole specification is delivered outside of a GPL, products using its
specifications are expected to pay royalty licensing and as such should not
be advocated as a part of any open source movement.
The proposal here was for an open format, not a closed consortium format,
the difference may be subtle and is apparantly lost on some people.
N.
From: Paul Davis
<paul(a)linuxaudiosystems.com>
Reply-To: paul(a)linuxaudiosystems.com,A list for linux audio users
<linux-audio-user(a)lists.linuxaudio.org>
To: A list for linux audio users <linux-audio-user(a)lists.linuxaudio.org>
Subject: Re: [LAU] Proposal: OpenDAWS (long)
Date: Wed, 06 Jun 2007 11:31:48 -0400
On Wed, 2007-06-06 at 18:16 +0300, David Baron wrote:
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user Wonderfully, the linux audio opensource field has
become nicely
populated.
Opensource means freedom of choice. One is not
tied to that $400
proprietary
bloated DAW program. Comes jack and one can
dissect the functionality
and
network smaller pieces (if one's system can
handle the multiple
processes).
Trememdous freedom of choice.
Problem is: No DAW program, opensource or otherwize, interoperates with
any
other. Cakewalk works with Cakewalk, Cubase with
Cubase, Ardour with
Ardour,
etc. Each has its strengths and each has its
adherents. Never the
'twain
do
meet. (Lash is fine but the restriction
remains.)
Proposal: OpenDAWS.
its actual name is AAF-XML. please google it.
--p
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
3:06 p.m.
On Wed, 2007-06-06 at 18:21 +0200, Nick Copeland wrote:
It seems a bit sad that any Linux advocate should be
backing this operation,
it would cost about $1500 per year to get access to any kind of support for
the SDK or advice on best practices and cosiderably more if you really want
to participate. You could stump up $175 per year yourself to propose changes
as long as you can find somebody paying the full price or more to back you.
It is a commercial directive not an open movement. From a perspective of
Linux audio it is already a pain that the Midi Manufacturers Association
want cash for their specifications.
So is the argument for this specification will be 'the professional
applications will be using it' hence it becomes the standard?
The whole specification is delivered outside of a GPL, products using its
specifications are expected to pay royalty licensing and as such should not
be advocated as a part of any open source movement.
The proposal here was for an open format, not a closed consortium format,
the difference may be subtle and is apparantly lost on some people.
I'm not entirely sure what your objections are. I have the whole AAF
spec in front of me, downloaded for free. The BBC has been pushing AAF
towards more and more open sub-standards over the years, including its
soon-to-be-released adoption of XML rather than a totally ugly AAF-only
format for the file itself. There is no licensing fee, no license, no
patents. I am almost wondering if you are looking at the same thing I
am. I've gotten excellent support from the main members of the steering
committee, who happen to work for the BBC and are quite involved in its
open source work (Dirac and more).
I am not going to spend time on supporting a "new" (i.e. LA-specific)
interchange format when the vast majority of ardour users need
interchange with proprietary applications, several of which already
support AAF (not AAF-XML, yet). It has the industry more than a decade
to get the rather pitiful state of affairs that AAF represents already,
and I don't hold out hope of any magic bullets. There is a lot of
collective wisdom that went into its design, even though it does smack
of design-by-committee.
IMO, the real problems with AAF as it currently stands is its horrendous
complexity and its inability to be filesystem neutral.
--p
4:47 p.m.
By your own remarks there are already issues with the specification that may
require modifications and optimisations for an open system, such as Linux
for example, so you recognise the possiblity that changes would be required.
Those changes would have to be raised through the consortium via a paying
member as the consortium does not accept requests from outside of their cosy
liittle circle. Should the community to accept that requirement?
You state that you do not understand my objections? They are simple, I stand
on the side of open source, open standards, and general implementation
without fees, demands, legal recourses or other futher liabilities, and as
yet this organisation posts documents refering to the liabilities of those
who implement their specification.
If you do decide to accept this standard then I hope that minimally you can
get your friends at the BBC and related organisations to accept removing
their demands for royalties of the applications implementing their XML
specification. I would prefer that were linux to adopt such a standard that
it were released under GPL for those who wish to adopt rather than for those
who might be able to simply via some form of dispensation from a commercial
organisation.
If Linux cannot accept their so called standard due to the nature of its
licensing then perhaps work is still needed on an open standard since the
body of work represents a requirement. The proposal of the original posting
was such an open document.
On the other hand, if you only want your application to accept those demands
then by all means implement it, but then also refrain from even suggesting
to the open source community that such an open standard already exists when
evidently that is not the case, as you did in your rather terse submit.
Strangely enough, your promotion of this consortium amost seemed targetted
at preventing the implementation of an open and hence competitive
alternative, and that seems strangely close to business practices of several
frowned upon companies.
n.
From: Paul Davis <paul(a)linuxaudiosystems.com>
Reply-To: paul(a)linuxaudiosystems.com,A list for linux audio users
<linux-audio-user(a)lists.linuxaudio.org>
To: A list for linux audio users <linux-audio-user(a)lists.linuxaudio.org>
Subject: Re: [LAU] Proposal: OpenDAWS (long)
Date: Wed, 06 Jun 2007 13:05:58 -0400
On Wed, 2007-06-06 at 18:21 +0200, Nick Copeland wrote:
_________________________________________________________________
Like puzzles? Play free games & earn great prizes. Play Clink now.
http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2
It seems a bit sad that any Linux advocate should
be backing this
operation,
it would cost about $1500 per year to get access
to any kind of support
for
the SDK or advice on best practices and
cosiderably more if you really
want
to participate. You could stump up $175 per year
yourself to propose
changes
as long as you can find somebody paying the full
price or more to back
you.
It is a commercial directive not an open
movement. From a perspective of
Linux audio it is already a pain that the Midi Manufacturers Association
want cash for their specifications.
So is the argument for this specification will be 'the professional
applications will be using it' hence it becomes the standard?
The whole specification is delivered outside of a GPL, products using
its
specifications are expected to pay royalty
licensing and as such should
not
be advocated as a part of any open source
movement.
The proposal here was for an open format, not a closed consortium
format,
the difference may be subtle and is apparantly
lost on some people.
I'm not entirely sure what your objections are. I have the whole AAF
spec in front of me, downloaded for free. The BBC has been pushing AAF
towards more and more open sub-standards over the years, including its
soon-to-be-released adoption of XML rather than a totally ugly AAF-only
format for the file itself. There is no licensing fee, no license, no
patents. I am almost wondering if you are looking at the same thing I
am. I've gotten excellent support from the main members of the steering
committee, who happen to work for the BBC and are quite involved in its
open source work (Dirac and more).
I am not going to spend time on supporting a "new" (i.e. LA-specific)
interchange format when the vast majority of ardour users need
interchange with proprietary applications, several of which already
support AAF (not AAF-XML, yet). It has the industry more than a decade
to get the rather pitiful state of affairs that AAF represents already,
and I don't hold out hope of any magic bullets. There is a lot of
collective wisdom that went into its design, even though it does smack
of design-by-committee.
IMO, the real problems with AAF as it currently stands is its horrendous
complexity and its inability to be filesystem neutral.
--p
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
5:49 p.m.
On Wed, 2007-06-06 at 20:47 +0200, Nick Copeland wrote:
By your own remarks there are already issues with the
specification that may
require modifications and optimisations for an open system, such as Linux
for example, so you recognise the possiblity that changes would be required.
Those changes would have to be raised through the consortium via a paying
member as the consortium does not accept requests from outside of their cosy
liittle circle. Should the community to accept that requirement?
You state that you do not understand my objections? They are simple, I stand
on the side of open source, open standards, and general implementation
without fees, demands, legal recourses or other futher liabilities, and as
yet this organisation posts documents refering to the liabilities of those
who implement their specification.
please send me a link to the documentation that leads you to believe
there is a requirement to pay a licensing fee or more in order to use
AAF, or liability issues, etc.
the entire SDK for AAF is downloadable from SourceForge. the AAF FAQ
states:
--------------------------------------------------------------------
4.4. What are the licensing terms for the AAF SDK?
The AAF SDK is licensed under a perpetual, royalty-free license. Users
are allowed to download source code, make derivative works, include
these works in their products and charge for these works.
----------------------------------------------------------------------
the FAQ continues:
-----------------------------------------------------------------------
4.9. If I can get the AAF SDK free, why do I need to join the AAF
Association?
You should join the AAF Association to get support for the SDK and to
participate in the development of future capabilities of AAF. AAF is
fundamentally a shared industry initiative, built out of the
contributions of its members. No one is required to join; the
association is open to everyone. Members share benefits such as access
to the support network and participation in developer conferences and
the technical committee.
--------------------------------------------------------------------------
the SDK license is somewhat similar to the initial Mozilla public
license, in that if you distribute a modified version of the SDK you
have to send your changes back in to the AAF Association. otherwise,
there is no obligation to interact with the AAF Association at all.
at one time, the SDK included libs from MS for "structured
storage" (think filesystem-inside-a-file) but the SDK now has the option
to build using GNU equivalents (GSF or something like that).
in 2000, the AAF presented a entire roadmap for their planned adoption
of an open source strategy. the PDF of the slides is easily available:
http://www.aafassociation.org/passed_events/2000-11-DevCon_SanteFe/opensour…
so i am totally lost and confused by your suggestions.
Strangely enough, your promotion of this consortium
amost seemed targetted
at preventing the implementation of an open and hence competitive
alternative, and that seems strangely close to business practices of several
frowned upon companies.
sigh. i've spent 5 years struggling with inter-operability issues with
DAWs, to no particular avail. the issues are large, and complex, and to
date nobody appears to have done a particularly outstanding job of it. i
don't believe that the right answer is to start another "standards"
definition. if i was convinced that using AAF required licensing fees,
or that the people who define the standard would pay no attention to
organizations or individuals outside the AAF, then i would probably
avoid using it, and would certainly not "promote" it here.
--p
7 Jun
7 Jun
10:47 a.m.
On Wednesday 06 June 2007, Paul Davis wrote:
On Wed, 2007-06-06 at 20:47 +0200, Nick Copeland
wrote:
AAF may be the way to go once the XML version is available. XML must be text
oriented (my proposal points to binary files but does not include them inside
the XML itself). Once one can create such stuff, even without any SDK, the
issue becomes moot.
Question is whether AAF is overkill or whether it is suited for ... linux
audio? What I have in mind mirrors the way a program like Sonar stores its
data (in its proprietary binary format) in a textual, open manner
Does Ardour already support (the binary) AAF? Does anything else we might be
playing with? What type of XML stardard would opensource developers readily
support in some form or another?
By your own remarks there are already issues with
the specification that
may require modifications and optimisations for an open system, such as
Linux for example, so you recognise the possiblity that changes would be
required. Those changes would have to be raised through the consortium
via a paying member as the consortium does not accept requests from
outside of their cosy liittle circle. Should the community to accept that
requirement?
You state that you do not understand my objections? They are simple, I
stand on the side of open source, open standards, and general
implementation without fees, demands, legal recourses or other futher
liabilities, and as yet this organisation posts documents refering to the
liabilities of those who implement their specification.
please send me a link to the documentation that leads you to believe
there is a requirement to pay a licensing fee or more in order to use
AAF, or liability issues, etc.
the entire SDK for AAF is downloadable from SourceForge. the AAF FAQ
states:
--------------------------------------------------------------------
4.4. What are the licensing terms for the AAF SDK?
The AAF SDK is licensed under a perpetual, royalty-free license. Users
are allowed to download source code, make derivative works, include
these works in their products and charge for these works.
----------------------------------------------------------------------
the FAQ continues:
-----------------------------------------------------------------------
4.9. If I can get the AAF SDK free, why do I need to join the AAF
Association?
You should join the AAF Association to get support for the SDK and to
participate in the development of future capabilities of AAF. AAF is
fundamentally a shared industry initiative, built out of the
contributions of its members. No one is required to join; the
association is open to everyone. Members share benefits such as access
to the support network and participation in developer conferences and
the technical committee.
--------------------------------------------------------------------------
the SDK license is somewhat similar to the initial Mozilla public
license, in that if you distribute a modified version of the SDK you
have to send your changes back in to the AAF Association. otherwise,
there is no obligation to interact with the AAF Association at all.
at one time, the SDK included libs from MS for "structured
storage" (think filesystem-inside-a-file) but the SDK now has the option
to build using GNU equivalents (GSF or something like that).
in 2000, the AAF presented a entire roadmap for their planned adoption
of an open source strategy. the PDF of the slides is easily available:
http://www.aafassociation.org/passed_events/2000-11-DevCon_SanteFe/opensour
ce.ppt
so i am totally lost and confused by your suggestions.
Strangely enough, your promotion of this
consortium amost seemed
targetted at preventing the implementation of an open and hence
competitive alternative, and that seems strangely close to business
practices of several frowned upon companies.
sigh. i've spent 5 years struggling with inter-operability issues with
DAWs, to no particular avail. the issues are large, and complex, and to
date nobody appears to have done a particularly outstanding job of it. i
don't believe that the right answer is to start another "standards"
definition. if i was convinced that using AAF required licensing fees,
or that the people who define the standard would pay no attention to
organizations or individuals outside the AAF, then i would probably
avoid using it, and would certainly not "promote" it here.
6 Jun
6 Jun
5:25 p.m.
On Wednesday 06 June 2007, Paul Davis wrote:
I'm not entirely sure what your objections are. I
have the whole
AAF spec in front of me, downloaded for free. The BBC has been
It's true that developers who want input into the spec have to pony
up, but IIRC the same is true with the ODF spec. Employees of Sun
and IBM and other OASIS members listen to community input, but it's
still their ball game.
It looks like the AAF guys are at least paying lip service to open
source software. They claim to have an "open-source API", and I know
someone's already written an input plugin for Ardour so it can't be
too GPL-incompatible.
Google failed me on this, but the Linux Sound Apps page pointed me in
the right direction.
http://www.aafassociation.org
Rob
7 Jun
7 Jun
10:53 a.m.
On Wednesday 06 June 2007, Rob wrote:
On Wednesday 06 June 2007, Paul Davis wrote:
Went there.
Easily downloaded a bunch of pdf documentation.
Links to sourceforege and got stuff from there.
An input plugin for Ardour, if not really GPL, can be distributed as source.
Just like to use Ardour with VST, one must compile it with one's own copy of
Steinberg's SDK. Cannot distribute binaries.
I'm not entirely sure what your objections
are. I have the whole
AAF spec in front of me, downloaded for free. The BBC has been
It's true that developers who want input into the spec have to pony
up, but IIRC the same is true with the ODF spec. Employees of Sun
and IBM and other OASIS members listen to community input, but it's
still their ball game.
It looks like the AAF guys are at least paying lip service to open
source software. They claim to have an "open-source API", and I know
someone's already written an input plugin for Ardour so it can't be
too GPL-incompatible.
Google failed me on this, but the Linux Sound Apps page pointed me in
the right direction.
http://www.aafassociation.org
11:51 a.m.
On Thu, 2007-06-07 at 15:53 +0300, David Baron wrote:
An input plugin for Ardour, if not really GPL, can be distributed as source.
Just like to use Ardour with VST, one must compile it with one's own copy of
Steinberg's SDK. Cannot distribute binaries.
nope. there's a critical difference. the AAF license allows
redistribution of an unmodified OR modified SDK. it can thus be included
in any source distribution, even if it were necessary to modify it in
some way, and thus binaries using it can be distributed too.
--p
12:56 p.m.
Doesn't this remain a license? The implementors agreement stipulates that a
licensee may freely distribute but not sublicense, hence any interface
defined by a DAW could not be used by another party who had not signed their
own license - anybody downloading the DAW only has an end user license even
though any party who signs up can distribute what they like. It looks lilke
the agreement can also be revoked at any point by the AAF Org just by
nullifiying their license.
Additionally, does the current format demand a Microsoft storage license be
singed as well? Their presentation was nice and fuzzy about using the
community but that does seem a little bit like lipservice if they expect
that a Microsoft agreement be signed as well.
Are there any other licenses than those on their site that are a bit more
open? Based on the apparant hype surrounding the XML format then perhaps the
MS license is not longer a requirement, since the microsoft document on
states that the SSL license code is a requirement of any AAF implementation
to that date, potentially not in subsequent releases?
Regards,
Nick.
From: Paul Davis <paul(a)linuxaudiosystems.com>
Reply-To: paul(a)linuxaudiosystems.com,A list for linux audio users
<linux-audio-user(a)lists.linuxaudio.org>
To: A list for linux audio users <linux-audio-user(a)lists.linuxaudio.org>
Subject: Re: [LAU] Proposal: OpenDAWS (long)
Date: Thu, 07 Jun 2007 09:51:29 -0400
On Thu, 2007-06-07 at 15:53 +0300, David Baron wrote:
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
An input plugin for Ardour, if not really GPL, can be distributed as
source.
Just like to use Ardour with VST, one must
compile it with one's own
copy of
Steinberg's SDK. Cannot distribute binaries.
nope. there's a critical difference. the AAF license allows
redistribution of an unmodified OR modified SDK. it can thus be included
in any source distribution, even if it were necessary to modify it in
some way, and thus binaries using it can be distributed too.
--p
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
4:06 p.m.
On Thu, 2007-06-07 at 16:55 +0200, Nick Copeland wrote:
Doesn't this remain a license?
All software that is not public domain requires a license. The GPL is a
license. Without a license, simple copyright law kicks in and nobody can
do anything at all.
The implementors agreement stipulates that a
licensee may freely distribute but not sublicense, hence any interface
defined by a DAW could not be used by another party who had not signed their
own license -
this is a red-herring. DAW or other application authors are not
implementators of an AAF specification, they are users of an AAF SDK.
if you want to implement your own AAF SDK from scratch, i can see their
concern about making sure that your implementation was fully compliant
with the spec before being allowed to associate it with the term "AAF",
since the term is used to sell products as a useful capability.
anybody downloading the DAW only has an end user
license even
though any party who signs up can distribute what they like.
No, *anybody* can redistribute. You do not need to join the AAF to do
this.
It looks lilke
the agreement can also be revoked at any point by the AAF Org just by
nullifiying their license.
I can see no clause that would enable this. And I note that the FAQ
stated: "The AAF SDK is licensed under a perpetual, royalty-free
license." Note the word perpetual.
Additionally, does the current format demand a
Microsoft storage license be
singed as well? Their presentation was nice and fuzzy about using the
community but that does seem a little bit like lipservice if they expect
that a Microsoft agreement be signed as well.
The MS storage format thing is still lingering in lots of docs, buts its
been gone at the source level for 2-3 years. There was a GNU replacement
for it created some time ago that is included in the SDK.
Are there any other licenses than those on their site
that are a bit more
open?
They want (and may already have) OSI certification for the license. Its
not the GPL, but there are clear reasons for that. I really can't figure
out your motives here. My most optimistic guess is that you read some
outdated text on a website and got all pissed at the whole idea.
Based on the apparant hype surrounding the XML format
then perhaps the
MS license is not longer a requirement, since the microsoft document on
states that the SSL license code is a requirement of any AAF implementation
to that date, potentially not in subsequent releases?
As stated above, there is no reason to use any MS code or agree to any
MS license in order to use the AAF SDK at this time.
--p
6:58 p.m.
I really can't figure out your motives here.
I can neither figure out yours. Two days ago you put down a request to put
together an open specification stating that it already existed, and refered
them to a consortium standard that depends on a MicroSoft license. Why would
you want to stifle open development?
My most optimistic guess is that you read some outdated
text on a website
and got all pissed at the whole idea.
I read the license agreements on the AAF site, this is not 'a' website, it
is that of the body authorising the specification you suggest the open
source community adopt. If these are outdated text then perhaps the very
authority should be pressurised, however I have a feeling their information
might just be up to date. That license states that distribution requires
that their license be signed, and another license from MicroSoft stating:
"Microsoft's Structure Storage file format as REQUIRED in the AAF
specfication."
Why can't you perhaps accept that you cannot foist this as a open source
standard. If you wish to implement then you are free to do so, but if you
want to suggest it be that used as an open source alternative then can you
expect to do that and not have some degree of contestation?
Until there is something on that site to suggest that the licensing be a
little more open then perhaps the community might not be expected to accept
this. This may be the case with the pending XML format although the is no
such indication.
Regards.
n.
Based on the apparant hype surrounding the XML
format then perhaps the
MS license is not longer a requirement, since the microsoft document on
states that the SSL license code is a requirement of any AAF
implementation
to that date, potentially not in subsequent
releases?
As stated above, there is no reason to use any MS code or agree to any
MS license in order to use the AAF SDK at this time.
--p
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user 
7:36 p.m.
Hi Nick!
I must agree with Paul. From all I've read, it looks very much, that is
opensource, or close enough, so we can use it.
Why stifle opensource developmen? I don't think it is stifling opensource
development, but maybe advertising it. Because: This AAF seems to be used by a
few people, maybe even by some comercial DAW, if not it might be and the
probability of a comercial DAW using AAF than a re-invented wheel by us, that
will in addition take a lot of time to get a "production/stable" state, is
much higher. So if we could agree to use it, as ardour apparently already
does, it will be sooner rather than later, that people are able to load their
cubase or cakewalk projects into ardour and audacity and back again. Don't you
see? Besides, it makes porting easier, becasue this AAF already exists on
quite a few platforms. So it will be much better and faster to get an ardour
under windows. the poeple, that aren't quite convinced of the linux opensource
idea will first try to get some tool on their native system, which in a lot of
"sad" cases is windows. but if they see it works there, then their decision to
trade their windows for a linux or freebsd will be easier and they can also
spread it.
Besides, I believe that there are/or at least were, a few apps and libs,
which were developed by other big companies. We still used it or use it. Last
but not least, if their code is on sf.net, it would be sufficient for me. For
I believe, when I registered my own project there, they stated, that only
projects with an osi license were allowed to register.
Well if you're still pissed, I can't help it either. And there wasn't a real
attempt to stifle "opensource development", there was just a lot of good
reasoning, why we could skip this development. In my book it just said; There
already is the software you need, in the way you can use it. So you can still
go ahead, but if this suffices, you can safe yourself and others the time do
it.
Kindest regards
Julienj
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
8:08 p.m.
On Thu, 2007-06-07 at 22:58 +0200, Nick Copeland wrote:
How many times do I have to explain that there is no need to use MS
licenses or software anymore, that this requirement vanished several
years ago, that a simple download of the SDK would reveal this, that you
are reading outdated docs that the AAF Association should have removed
from their online presence ? I have stated at least twice that there is
a *GNU* replacement for the component that was once represented only by
MS's structured storage. What more do I need to do?
I really
can't figure out your motives here.
I can neither figure out yours. Two days ago you put down a request to put
together an open specification stating that it already existed, and refered
them to a consortium standard that depends on a MicroSoft license. Why would
you want to stifle open development? My most optimistic guess is that you read some
outdated text on a website
and got all pissed at the whole idea.
I read the license agreements on the AAF site, this is not 'a' website, it
is that of the body authorising the specification you suggest the open
source community adopt. If these are outdated text then perhaps the very
authority should be pressurised, however I have a feeling their information
might just be up to date. That license states that distribution requires
that their license be signed, and another license from MicroSoft stating: "Microsoft's Structure Storage file format as
REQUIRED in the AAF
specfication."
the file format is NOT subject to a license and there is a GNU
replacement for the implementation! how much clearer can i be?
Why can't you perhaps accept that you cannot foist
this as a open source
standard.
sf.net, which only accepts projects with OSI-certified licenses, doesn't
appear to agree with your assessment of the "open source-ness" of the
AAF SDK.
Until there is something on that site to suggest that
the licensing be a
little more open then perhaps the community might not be expected to accept
this. This may be the case with the pending XML format although the is no
such indication.
i think you imagine that the AAF Association is somehow way more than
the band of hackers assembled here. its not. its a tiny group of people
trying to get something accomplished. their online presence has been out
of date since pretty much the day they went online. they have no
webmaster, and everyone associated with it, AFAIK, has a day job that
takes up the vast majority of their time. their progress has also been
stunted by the fact that Avid/Digidesign have not adopted AAF in
anything like the fashion that they once indicated that they would
(their implementation is actually somewhat broken), which has reduced
the pressure on other application developers to adopt AAF as well.
like you, i noted and did not like an apparent need for an MS license,
or even just using an MS library. unlike you, i *wrote* the AAFA to ask
what the situation was. you can see the dialog in the forums at sf.net
(which, btw, see hardly any traffic). there is no such dependency. end
of story.
can we please get on with talking about how to get the AAFA to speed up
release of AAF-XML, etc etc?
--p
9 Jun
9 Jun
5:40 p.m.
Using AAF binary formats and such is not what I had in mind.
Using their as yet unspecified XML could be.
7 Jun
7 Jun
11:26 a.m.
David Baron <d_baron(a)012.net.il> writes:
Just as Sun's Openoffice is not using what they
call an open
document format, we need a open digital audio work-stations format.
Another reason for wanting something like this is that it'd
occasionally be useful to generate a multitrack project from something
else. One of the things I keep meaning to do is to write something
that'd take a Ninjam archive and generate an Ardour project from it
(with panning, fades in and out, and so on); having a standard import
format would mean that could be done portably. I'll go and have a peer
at AAF-XML...
--
Adam Sampson <ats(a)offog.org> <http://offog.org/>
6411
days inactive
6414
days old
linux-audio-user@lists.linuxaudio.org
20 comments
7 participants
participants (7)
-
Adam Sampson -
David Baron -
Julien Claassen -
Marc-Olivier Barre -
Nick Copeland -
Paul Davis -
Rob