Ron Kruper said:
>The MMA is a trade association, akin to a standards body like the AES.
>Do you also object to the fact that AES, IEEE, etc, charge membership
>dues, and that they too hold evolving standards discussions for
members >only? How does the fact that this happens to be _software_
standard >mandate that dues be waived?
I wasn't suggesting that dues be waved but that they may not be
neccessary. Paul makes a point in terms of anittrust legal fees but
surely the lgpl solves that problem.
>This isn't about being for or against open source, or a lack of
>understanding. This is about recognizing that developing and
supporting >a standard requires legal work, marketing, publications,
etc, and that >these cost money. Call it "old economy" if you must, but
if you want to
>interoperate with the major companies in the industry, the MMA is forum
>where they gather, and the MMA has a cost structure associated with it.
Where's the legal work involved in applying for example the lgpl to this
standard? Sure there is investment in the marketing and publications
side of things. We all know that the mass market needs it's eye candy.
But there should be very little legal fees associated with a truely open
standard.
If companies need to purchase the documents and specs to feel that it is
worth something then they should be the ones paying for the goods.
However I don't won't to appear negative towards the workings of the
MMA. I want to suggest that the open source community has been working
in the direction you are heading for a while and that maybe the MMA
should be looking into why it is working so well. Which is possibly the
same reason you are here now.
Linux has proven to be the perfect medium for hardware manufacturers to
get an equal footing. The truely large corporations are investing big
bucks into GNU/Linux because of this. It makes sense that any
professional who makes their business around computer technology would
want to be here too.
>IMO the *worst* possible scenario is that the commercial companies
>(many of whom are a one man show) decide that they want to join the
>MMA, while a sizeable group of others decide to persue a parallel
>effort. That gives us 2 standards, and nobody wins.
I'm sure everyone agress this is definitely something we don't want.
The developers who created the current music software industry must have
felt the crush when PC's first arrived, well it's happening again but
this time it's not forcing you into a proprietry business model. This
time you actually have a choice.
Anyways, it's good to see you and others like yourself arriving here.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.comHttp://www.djcj.org - The Linux Audio Users guide
========================================
Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.
Goldie, 8 Nov, 2002
The Scotsman
>>>
Can you explain to us exactely what the MMA is offering in exchange of this
money?
...
What protection does the MMA provides?
<<<
MMA provides anti-trust protection. If the major commercial vendors go off
in private and work in collusion to influence consumer choice, that is an
illegal trust. The trade association gives us a forum to talk among each
other, and *everyone* in the industry, with legal protection.
>>>
I can understand why steinberg and emagic
(for example) would prefer to hide a standard war behind closed doors
instead of on a public mailling list.
<<<
Mainly because companies act differently and say different things when they
know customers might be watching. Reality of business.
-Ron
>>>
In this context it's seems a little ridiculous that the MMA is requiring
members of the mailing list to sign on with $450.
<<<
The MMA is a trade association, akin to a standards body like the AES. Do
you also object to the fact that AES, IEEE, etc, charge membership dues, and
that they too hold evolving standards discussions for members only? How
does the fact that this happens to be _software_ standard mandate that dues
be waived?
>>>
Applying closed methods of communication, or at least requiring a sum of
money to be paid to have discussion rights is the equivalent of telling
us Open Source developers that either you don't understand what we are
doing and why or you totally disagree with the paradigm we work in.
<<<
This isn't about being for or against open source, or a lack of
understanding. This is about recognizing that developing and supporting a
standard requires legal work, marketing, publications, etc, and that these
cost money. Call it "old economy" if you must, but if you want to
interoperate with the major companies in the industry, the MMA is forum
where they gather, and the MMA has a cost structure associated with it.
Also, the plan is for this process to not be completely closed. We're
working on a process whose openness is new to the MMA, but similar in nature
to other standards organizations. The current plan is to have 4 phases:
[1] Requirements gathering. This will be open to any developer who wants to
register on an email reflector. This phase will start as early as next
week, and will last several months, I suspect.
[2] Design. This will be open to MMA members only. If you want the legal
protection that the MMA provides, and you want somebody else to pay for
"stewardship" of the spec, then it's worth joining. Even some open-source
developers sell products, and those who do will recoup their cost after
selling a very small number of units.
[3] Review. This will be public like phase 1. We'll probably have several
iterations of 2 and 3.
[4] Adoption. Once again, private to MMA members only.
IMO the *worst* possible scenario is that the commercial companies (many of
whom are a one man show) decide that they want to join the MMA, while a
sizeable group of others decide to persue a parallel effort. That gives us
2 standards, and nobody wins.
-Ron
>>>
person making a living writing audio plugins might feel a little nervous
about something like the development going on with LADSPA or XAP. Not to
mention how companies like Steinberg and Cakewalk are going to feel when
Ardour 1.0 hits the net.
<<<
I can't wait to see it. Seriously! Competition is good, it keeps everyone
sharp, on their toes and innovating. If the economics of open source and
Linux mean we need to adapt our economics, then of couse we'll need to adapt
or die.
The thing is, our average customer is not incredibly PC savvy, so have them
be their sysadmin won't really fly. Like or it not, Windows and Mac O/S are
still much easier to set up and support for the "average joe", which means
they are easier for us to set up and support.
Likewise, new customers want sexy features. Is Ardour 1.0 going to be as
sexy, full-featured and stable as existing commercial products which are on
version 5 or beyond? Again, it's all about competition. Prospective
customers will get to choose between "free" and "fuller featured." Of
course over the time you guys will gain ground on the second point... <g>
-Ron
> digidesign, we had the whole group in that room. i used to have
> friends who could have bought most of the companies represented there
> out of their own personal accounts :)) people planning on getting rich
> in this field are out of their minds.
In this context it's seems a little ridiculous that the MMA is requiring
members of the mailing list to sign on with $450.
Wouldn't it be better for them to either start up an open mailing list
or just do it here?
I get the impression that the forces involved in making this happen (Ron
Kruper and other lurkers may want to speak up here) are missing the
point of open source development. Sure it was ok to do what you seem to
be doing with this new standard 20-30 years ago when the MIDI standard
was created. Times have changed and now the world has open source
development.
Applying closed methods of communication, or at least requiring a sum of
money to be paid to have discussion rights is the equivalent of telling
us Open Source developers that either you don't understand what we are
doing and why or you totally disagree with the paradigm we work in.
Look at the development of the Kernel these days. In a total of 1000
(approx) highly active developers roughly 500 of them are employed by
major corporations like IBM, HP, Intel, AMD... The list is obviously
very large.
It is high time that the professional audio community got involved in
the open source process. Your absence has become extreemely noticable.
By attempting to make a protocol/specification that aims at providing
cross platform functionality you cannot justify using closed, old
economy methods of communication.
Not when there is a large number of developers who are already
communicating on mass in the Open source community.
If you want an example of this paradigm working in an audio context you
only need to look at the port-audio project. If you want to see the
power of the Linux Audio Developers then the best example is JACK. We
have created a protocol that neither M$ or Mac developers can provide a
better option.
If it is the name of the mailing list that is putting you off from being
involved around here, just ignore it. All we are doing is making
machines work. The Linux part plays a very small role in the wider scheme.
Instead of spending the money on hiring someone to do the book keeping
and running the mailing list etc... You could be channeling that into
Open source. If those other companies can justify it then why can't you?
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.comHttp://www.djcj.org - The Linux Audio Users guide
========================================
Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.
Goldie, 8 Nov, 2002
The Scotsman
Dave Griffiths wrote:
>>>It shouldn't be a problem, iwht only a few apps running the overhead is
>>>very small. If by "isn't perfectly tuned" you mean not running SCHED_FIFO
>>>or a patched kernel that its not that supprising, the context switch will
>>>be causing big problems. But, at worst it should just make xruns a bit more
>>>frequent, not go from none to some.
>>>
>>>
>>What I have noticed is subtle, I have xruns in both situations but
>>the rate increases noticeably. I've been running patched kernels but
>>there are all kinds of parameters
>>(as I'm sure you know) to tweak before it is sufficiently solid. I
>>would consider my findings pretty much expected behaviour with a
>>less then perfectly tuned system.
>>
>>
>
>I thought I'd pipe up here, as I use jack on a totally unpatched, untuned
>system (with SCHED_FIFO) and get rock solid performance.
>
Hmmm, that's annoying, I've never had that happen to me >:-|
;-) no, seriously, that's really great! Sadly this is not the case for
all of us...
Would you care to describe your setup, hardware/kernel versions etc...?
Regards,
Robert
Steve Harris wrote:
>On Wed, Jan 22, 2003 at 03:57:40 +0100, Robert Jonsson wrote:
>
>
>>What I have noticed is subtle, I have xruns in both situations but the
>>rate increases noticeably.
>>I've been running patched kernels but there are all kinds of parameters
>>(as I'm sure you know) to tweak before it is sufficiently solid.
>>I would consider my findings pretty much expected behaviour with a less
>>then perfectly tuned system.
>>
>>The real problem is that it's so very very hard to tune a system
>>sufficiently without hours and hours of work. It would be very nice if
>>there was some way to automate, atleast parts of, the process.
>>
>>
>
>I didn't have to put any real effort in on my PC (RH8, ide, athlon),
>I just installed a patched kernel from Planet CCRMA and rebooted.
>
>I get xruns at 64 samples/period (and 128 with heavy disk load), but I
>think that's a problem with the ext3 filesystem - others have reported this
>too. I'm happy at 256 so I haven't bothered remounting the partition to
>find out.
>
>JACK/no JACK makes no noticable difference to the xruns.
>
Well, as I asked David, care to describe your setup that provides such
wonderful performance?
/Robert
On Wed, Jan 22, 2003 at 03:22:42 +0100, Robert Jonsson wrote:
> Atleast I have noticed that performance is worse running with jack than
> running without it. My evidence is basically running MusE with alsa vs
> jack output. Running with jack it is much more prone to produce xruns.
>
> I have not talked so much about this because:
>
> a) jack is in development
Well, technically, but I regard it as stable in its behaviour. Paul, Kai?
> b) I thought it was common knowledge
It seems not :)
> c) I thought that because the extra weight(scheduling etc) that jack
> adds this was perfectly justified.
> My system isn't perfectly tuned and that might be the reason I notice
> the difference...
It shouldn't be a problem, iwht only a few apps running the overhead is
very small. If by "isn't perfectly tuned" you mean not running SCHED_FIFO
or a patched kernel that its not that supprising, the context switch will
be causing big problems. But, at worst it should just make xruns a bit more
frequent, not go from none to some.
IMHO any runtime xruns at all makes audio software unusable.
- Steve
>>To my own surprise I have to object to the suggestion: /*
>>AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled
>>by a high time res. slider or control data, but shouldn't be connected to
>>the next audio signal by default. I can't think of any simple examples off
>>hand, but combined with MOMENTARY it could be used for sample accurate
>>tempo tapping. */
>>
>>As is see it, this declares that an audio port should be used for control
>>data.
>Yes. At present, ladspa allows two types of port: LADSPA_PORT_CONTROL (one
>value per block) LADSPA_PORT_AUDIO (array of values per block) However,
>some plugin authors (myself included) wanted finer control over the
>parameters, so we 'overloaded' the AUDIO port to allow per-sample control
>data. This has been used in many libraries: cmt, swh-plugins, blop, and it
>works fine in hosts that allow direct wiring: SpiralSynthModular,
>AlsaModularSynth, gAlan.
>However, other hosts such as Ardour and Ecasound do not have the same
>direct wiring functions, and instead treat any AUDIO ports as exactly that
>(making them available as Effect Sends or similar). The purpose of the new
>hint is to accommodate these hosts:
>LADSPA_PORT_CONTROL (one value per block for control data)
>LADSPA_PORT_AUDIO (array of values per block for audio
data)
>LADSPA_PORT_CONTINUOUS_CONTROL (array of values per block for control
data)
This is what I'm getting at: the original suggestion was to introduce a
LADSPA_HINT for continuous control which would be applied to ports of type
LADSPA_PORT_AUDIO. I think that this is misleading because I interpret port
type = audio to mean that the port is for audio content as opposed to
control content. I agree with the proposal as you present it here, adding a
new port type (not a new hint).
However, it seems that plugin writers are more comfortable interpreting port
type=audio to mean that the rate of the port is audio rate. Steve suggests
that it is splitting hairs to try to absolutely determine whether an
audio-rate port is for audio or control content. If this is the case then we
should just leave 2 port types and add a hint for audio-rate ports that they
should be used for control data.
I feel I must warn that this will make the ladspa_port_types audio vs
control a little misleading to people when they first read the header. If
the port type is chosen to be audio and not data then the port should be for
audio and not data, right? In short I think adding a third port type would
keep the header self-consistent, whereas adding a hint that overrides and
reverses the port type is twisting the standard to match current useage.
--jacob robbins.....
_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
Hi all,
Just to share the good news that Linux got some exposure in the latest
edition of the Organised Sound journal (pub. by UK's Cambridge
Journals).
Stuff covered is RTMix, as well as JACK/Linux audio. Big thanks go to
Paul Davis for the help with the benchmark info, as well as everyone
else in the Linux community who have made Linux a formidable multimedia
platform.
For more info on the journal see (it's just an abstract page about the
actual journal -- I am still trying to find out how to locate the darn
article online :-)
http://titles.cambridge.org/journals/journal_catalogue.asp?mnemonic=oso
Cheers!
Ivica Ico Bukvic, composer, multimedia sculptor,
programmer, webmaster & computer consultant
http://meowing.ccm.uc.edu/~ico
============================
"To be or not to be" - Shakespeare
"To be is to do" - Socrates
"To do is to be" - Sartre
"Do be do be do" - Sinatra
"2b || ! 2b" - ?
"I am" - God