hello * !
after what looks like a server upgrade (if you can call 2.0.40 an
upgrade), the LAD homepage is broken. (yet again.) i hope root@localhost
will be able to fix it, and maybe he will set the server admin mail
address properly while he's at it...
sorry for any inconvenience.
the archives can be reached directly at http://eca.cx/lad,
http://eca.cx/lau, and http://eca.cx.laa .
the mailman web interface is available at
http://music.columbia.edu/mailman/listinfo .
best,
jörn
--
Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)
David Seymour
Benchmark Media Systems
800-262-4675
www.benchmarkmedia.com
-----Original Message-----
From: David Olofson [mailto:david@olofson.net]
Sent: Monday, February 03, 2003 10:26 AM
To: linux-audio-dev(a)music.columbia.edu
Subject: Re: [linux-audio-dev] Re: linux-audio-dev digest, Vol 1 #312 -
8 msgs
On Monday 03 February 2003 15.36, Ben Loftis wrote:
> >> > * The "save state chunk" call seems cool, but what's
> >> > the point, really?
> >>
> >> This could be useful for state storing in hosts, but how many
> >> would use it? I'd certainly be reluctant to implemnt it.
> >
> >Right... I'm not even sure what state we're talking about here,
> > but I *assume* it's basically all you need to continue playing
> > from where you saved the state. Freezing reverb tails and stuff?
> > Sounds fun but pretty useless... Might help some very special
> > apps - but then, will it be sufficient?
>
> If you want to restart playback at an arbitrary point and be
> sample-accurate, you must have this, right?
Nope. Sample accuracy has nothing to do with it. You'd just start
playing and make sure there are events to set the transport at the
right position before the first sample frame. (Or if you have the
plugins running all the time, you just start the sequencer, period.)
> I think it's a good
> idea (I suggested it myself a while back). The host can cache
> these at regular intervals (and at the user's locate points) so you
> can start playback and the host only has to preroll from the most
> recent state chunk. Implementation is easy if you design for it...
> just stream all your internal variables into a buffer.
So, we're basically talking about a brute-force solution to the
classic "make MIDI behave as recorded audio" problem?
It could work in theory, but what about the bandwidth required for
some plugins to do this correctly? You'll have to drop delay buffers
and the like, and then it's not a complete solution anyway. Could
work pretty well for synths though, and that's probably the
interesting part.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
>
>> > * The "save state chunk" call seems cool, but what's
>> > the point, really?
>>
>> This could be useful for state storing in hosts, but how many would
>> use it? I'd certainly be reluctant to implemnt it.
>
>Right... I'm not even sure what state we're talking about here, but I
>*assume* it's basically all you need to continue playing from where
>you saved the state. Freezing reverb tails and stuff? Sounds fun but
>pretty useless... Might help some very special apps - but then, will
>it be sufficient?
If you want to restart playback at an arbitrary point and be sample-accurate, you must have this, right? I think it's a good idea (I suggested it myself a while back). The host can cache these at regular intervals (and at the user's locate points) so you can start playback and the host only has to preroll from the most recent state chunk. Implementation is easy if you design for it... just stream all your internal variables into a buffer.
-Ben
Hi all,
I'm about to release a new version of jack rack, so rather than let it
go and then release a load of fixed versions over the next week, I
thought I'd try a beta test type thing seeing as the code is now in
cvs. So, if anyone would like to test the new version, you can get the
cvs info from http://sourceforge.net/cvs/?group_id=71639 . Module name
is "jack-rack". Reports can go to myself or, preferably, the mailing
list, jack-rack-devel(a)lists.sourceforge.net.
Cheers,
Bob
--
If you're happy and you know it, bomb iraq
> Subject: RE: [linux-audio-dev] Fwd: Creative's IP concerns
> From: Pieter (pieter.palmers_AT_student.kuleuven.ac.be)
> Date: Thu Jan 24 2002 - 17:43:23 EET
[...]
> Pieter
> PS: I'm not really certain of this, but I think
> The help for developping the SAM9407 driver came from Terratec.
> They seem to be much more open to Linux users than Guillemot.
> But I think the main problem is Dream,
> because everyone I contacted about info started nagging about
> 'having a NDA'... when are HW manufacturers going to learn...
I am the author of the sam9407 device driver for Linux.
I do not agree with your observation:
Terratec never replied to any of my inquiries directly, and only after
one year of efforts they started to offer an NDA, which I did not sign.
Guillemot was compared to that relatively open.
Dream was along the lines of Guillemot, after some initial effort,
I had a contact person I could turn to.
Hoontech ranked best in that regard.
Terratec ignored my efforts until the end.
Other people on the sam9407 development list that went to meet Terratec
people on trade shows were simply pointed to the "Linux Community"
that would in their opinion already work on a driver.
Check out the README file in the package, that has an event log
and some ranting about that http://sam9407.sourceforge.net
Best Regards,
Gerd Rausch
New Yorkers for Fair Use Action Alert:
--------------------------------------
Tell American Megatrends and Transmeta not to make chips
that let others control your computer!
Stop Palladium and TCPA Now!
Okay, you folks understand this issue -- AMI and Transmeta
recently announced their intention to build TCPA technology
into their chips. It's time to tell them that building
chips that let others control your computer, is
unacceptable.
1) Please send your comments using the form provided below.
Tell them not to produce their AMIBIOS8 and TM5800 chips,
and that you will boycott any technology that enables TCPA
and Palladium technology on your computer. Read the alert
below for details.
3) Take up a role helping with this and other efforts
related to information freedom in the future. Two roles you
can take up are to become a Press Outreach Campaigner or a
Commentator. Simply reply to this email to show your
interest.
2) Please forward this alert to any other interested parties
that you know of, who would understand and see the
importance of this issue.
New Yorkers for Fair Use Action Alert:
--------------------------------------
Stop Palladium and TCPA now!
Tell American Megatrends and Transmeta not to make chips
that let others control your computer!
Please use the following form to tell American Megatrends
and Transmeta not to produce their AMIBIOS8 and TM5800
chips, and that you will boycott any technology that enables
TCPA and Palladium technology on your computer:
http://www.nyfairuse.org/cgi-bin/nyfu/palladium
What's Going On:
Last week, Intel, Microsoft, the RIAA and the MPAA announced
their intention to force Palladium and TCPA into every
personal computer on the planet. Palladium and TCPA are a
different kind of DRM, worse than even the most invasive of
previously proposed "content control" systems.
Palladium and TCPA would hardwire your home computer so that
these four entities and their partners would be able to run
processes on your computer, entirely outside your control,
indeed, without your knowledge.
Below we answer some questions about DRM, Palladium, TCPA,
and the boycott.
New Yorkers for Fair Use
What is DRM?
DRM is the political, legal, contractual, economic,
hardware, and software infrastructure designed and intended
by a loose alliance of cartels and monopolies to take away
your right to own and privately use a computer. No full DRM
exists in the world today, though pieces of DRM have been
successfully enacted into law and tiny bits of DRM hardware
and software have been placed in some home movie playing and
recording devices. Every single piece of DRM is meant to
help attain the objective of the anti-ownership alliance: to
get control of every personal computer in the world.
Intel and Microsoft and RIAA and MPAA, by their own
admission, have, to date, spent billions of dollars to force
universal DRM on the entire world. Last week these four
reiterated their intention to force DRM into every personal
computer on the planet:
http://www.nytimes.com/2003/01/15/business/15PIRA.htmlhttp://news.com.com/2100-1023-980671.html
For more on DRM see:
http://newsforge.com/newsforge/02/10/21/1449250.shtml?tid=19http://www.panix.com/~jays/what.is.drm.3
What is Palladium?
"Palladium" is Microsoft's name for its proposed DRM system.
No implementation of Palladium exists today, indeed no
complete specification of Palladium exists today, but
certain hardware which a Palladiated operating system
requires is about to be placed in all personal computers,
unless we stop Microsoft and its hardware and vendor
partners, such as Intel, American Megatrends, Transmeta,
Dell, and CompUSA.
What will Palladium do?
Palladium will enable a few large corporations and
governments to run source secret, indeed, well-encrypted,
code on home users' machines in such a way that the home
user cannot see, modify, or control the running code. A
Palladiated system is under the complete control of
Microsoft at all times. Microsoft might allow some of its
partners to run code on your machine, but no code will run
on a Palladiated system without Microsoft's consent. The
mechanics are as follows: only code that has been signed
with a special Microsoft provided key will run. Microsoft
will retain at all times the power to revoke any other
entity's keys. In particular, no operating system will be
able to boot without a key from Microsoft. So if Palladium
is forced into every home computer, there will be no more
free software.
Microsoft will be able to spy on each and every keystroke,
and mouse movement, and send encrypted messages from your
machine to Microsoft headquarters. Microsoft will also be
able to examine every file on your system. Your encryption
programs will not work against Microsoft, or any other
entities which have full power keys from Microsoft.
But surely wily crackers and freedom-loving hackers around
the world will be able to defeat Palladium by breaking it?
No. Whether or not a few hackers are able to get around some
versions of Palladium, most people will not be able to.
There are two reasons most people will not be able to escape
the All Seeing Eye and Invisible Hand of Palladium. First,
Palladium is not like the absurdly weak systems called "DRM"
today. Palladium is both hardware and software, and the
software is locked to the hardware in a manner completely
different from today's weak DRM systems. The design of
Palladium allows for defense in depth, and even one layer of
Palladium is harder to crack than any DRM ever seen before.
Second, under the Digital Millennium Copyright Act of the
United States of America, it is illegal to try to see what
Palladium is doing. It is also illegal to modify the
hardware of a Palladiated system. And it is a felony to sell
advice on how to disable Palladium or its supporting
hardware. It is hard enough today to get vendors to sell
computers with a free operating system already installed.
Once Microsoft and Intel have forced Palladiated hardware
into every personal computer, it will be impossible to run a
free OS. The very act of booting a free OS will be outlawed
by application of the DMCA to a Palladiated computer.
But there are no Palladium systems available today. So how
can you boycott Palladium?
We are boycotting the hardware that Palladium needs. Before
Palladium is rolled out, Palladium-enabling hardware must be
placed in most of the world's personal computers. Right now
such hardware is being placed in computers meant for home
and business use without the buyer being told. Our boycott
is aimed at stopping Palladium-enabling hardware from being
secretly forced into every personal computer in world. We
intend to stop Palladium before we cease to own the
computers in our own houses and offices.
The main Palladium-enabling hardware is called a "TPM" for
Trusted Platform Module. The TPM hardware will support, in
addition to Palladium, many different systems which take
control of the computer away from the user and give control
to large corporations and government entities. The TCPA, the
Trusted Computing Platform Alliance, is the standards
organization for the TPM. The founding Alliance members are
Compaq, HP, IBM, Intel and Microsoft. Since 1999, the year
TCPA was founded, about one hundred more companies have
joined the TCPA. The Alliance has published a formal
specification of the TPM. The TCPA's FAQ
http://www.trustedcomputing.org/docs/Website_TCPA%20FAQ_0703021.pdf
seeks to allay the natural suspicions of computer buyers
about what the TPM does. Unfortunately the FAQ is inaccurate
on the most important issues. For example, the claim is made
that a computer with a working TPM will remain under the
final, ultimate, and complete control of the user. But, as
explained above, this is simply untrue.
So what exactly are you doing?
We refuse to buy any computer with a TPM inside and we ask
you to refuse to buy any computer with a TPM inside. We use
the term "TPM" to include TPM-like devices, whether in a
separate chip, in the BIOS chip, or even in the cpu. This
means that we ask buyers of personal computers to find out
whether the computer has a TPM or a TPM-like device inside.
We will shortly provide buyers of home computers with
methods for telling whether or not a computer has a TPM
inside.
Is it possible to be more specific today?
Yes. We call for a boycott of the just announced American
Megatrends AMIBIOS8:
http://www.ami.com/ami/showpress.cfm?PrID=118http://www.ami.com/products/product.cfm?ProdID=127&CatID=6&SubID=14http://interviews.slashdot.org/article.pl?sid=03/01/09/166251&tid=99http://interviews.slashdot.org/article.pl?sid=03/01/17/1430214&mode=thread&…
and the just announced Transmeta TM5800 cpu:
http://siliconvalley.internet.com/news/article.php/1569201http://slashdot.org/article.pl?sid=03/01/14/1719220&mode=thread&tid=161
Where can I find out more about Palladium, TCPA, and DMCA?
For Palladium see:
http://www.cl.cam.ac.uk/%7Erja14/tcpa-faq.htmlhttp://wintermute.homelinux.org/miscelanea/TCPA%20Security.txthttp://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0301b&L=wmtalk&T=0&O=…http://www.theregus.com/content/4/25378.htmlhttp://www.counterpane.com/crypto-gram-0208.html#1http://www.ofb.biz/modules.php?name=News&file=article&sid=152
For TCPA and the TPM see:
http://www.trustedcomputing.org
For the DMCA see:
http://www.nyfairuse.org/analysis/dmca.must.be.repealed.xhtmlhttp://anti-dmca.orghttp://www.nyfairuse.org/dmca.xhtml
How do I tell these folks I don't want DRM?
Just click on the URL below:
http://www.nyfairuse.org/cgi-bin/nyfu/palladium
(Well, it got silent again, and I can't check the archive...)
Appears that the LAD site is down, and the list archive gives me the
PHP code as text/plain... What's going on?
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
> The worst situation we can end up in if we go ahead with XAP is two
> plugin APIs on Linux; XAP and a new, totally incompatible API. That's
> still a lot better than the *current* situation on Windows and Mac
> OS.
Given the nature of vested interest, this is probably the best
situation, not the worst. Don't wait. The only reason to delay is if
you actually believe that a unified approach is not just possible, but
probable. Closed developers might agree to a closed, members only,
approach but a true unification would require either presently closed
developers to abandon the idea of trade secrets, or open developers to
abandon the gpl. Neither is likely. If you are into it, just go ahead.
Tom
> I´m not a programmer, but If I were, I´d try to do some
> co-operation with
> fruity-developers and do an linux-support to the fruityloops.
> ´cause it´s
> only the question of time&money.
I don't think that they like to share the code with a developer
and why should anyone port Fruity Loops to Linux without
getting money, when Cakewalk sells his work later on?
It would be better to write an open-source program from scratch.
Regards,
J.Backhaus
