it doesn't have the bandwidth to scale to
semi-pro let alone pro use.
the latency characteristics are just barely acceptable.
the entire protocol design wasn't properly thought out for high-bandwidth streaming data services. thats what IEEE1394 is for, both in terms of its bandwith capacity but also the design of the protocol.
if you're just streaming stereo 16 bit 44.1kHz streams to and from your box, i'm not suprised you think that USB works. you're at the low end of
the audio scale, and there are many things that will work for you that will break for people with more demanding requirements.
--p
Does nobody here know anything about this stuff?
on
New External Sound "Card"
·
· Score: 5, Insightful
Its quite amazing to read through the high-ranked posts here. Its hard to find any that display more than rudimentary knowledge of computer audio interfaces.
devices like this have existed for more
than 2 years. products from Midiman,
SEK'D, Event Systems and other companies
offered this kind of configuration for
some time. its becoming more common
all the time.
creative's audio products are widely
recognized by anyone with any experience
as being basically "just good enough" crap. they have terrible noise problems, and often come with basic h/w engineering problems (such as a fixed rate sample clock that forces resampling at any rate other than the chosen one).
USB for audio is a bunch of crap. It can be
made to work, but its being used only because
most computers these days come with USB ports,
and far fewer come with IEEE1394 ports. It has no redeeming qualities and many drawbacks. There
are bandwidth problems, reliability problems, connector stability problems, protocol conformance problems - it goes on and on.
IEEE1394 ("firewire") is vastly superior, but suffers from a lack of standardization on the
transport-level protocol used for audio and MIDI
data. There are at least 3 or 4 competing versions of this, with no resolution in sight.
Several people have pointed out the lack of
balanced connectors, as well as the lack of XLR
connectors (these two items are strictly orthogonal from one another). Balanced analog I/O is a serious must-have for anything other than
the typical low-quality audio stuff 95% of you
do with your computers. Of course, that 5% might not be a big enough market to make it worth offering:)
companies like creative are busy trying to make devices that appeal to many consumer's desire for stuff that appears to be "pro" or "semi-pro" gear. creative in particular has failed to make any equipment that even comes close to these descriptions. if audio on your computer matters to you enough that external converters are important, you should not be paying any attention to the extigy, but should instead be paying attention to products from Terratech, Event (even though they refuse to make linux support possible, they are nice devices), Midiman (Delta series) or RME. If you're really serious about audio on your computer, you'd already know that you should be basically buying an audio interface that supports ADAT optical connections and then a totally separate converter box (such as the Tango24 from Frontier Designs, or the ADI series from RME, or if money is tight, perhaps a Fostex unit). this configuration allows you to upgrade your A/D-D/A capabilities and the audio interface independently, which in turn implies the potential for improved channel counts and/or improved converters at a later date.
--p
several people have claimed that NT wasn't a
rewrite and that it was based on OS/2. this is false. MS hired dave cutler from DEC, cutler picked a team of programmers, and they wrote
"NT" (which stands for "New Technology" [sic]) from scratch. it was not derived from OS/2, though it may borrow ideas from it. it borrows as much from VMS as it does from OS/2.
readers may be confusing the NT kernel (which i was referring to) with the NT UI (which i was not referring to.
ahem. what was NT for? sometimes, you just have
to come to terms with the fact that as tested, bug-fixed and studied as a chunk of code may be, it was developed as part of a misconceived model of either visible functionality or internal architecture or both. DOS and its progeny like win32 were clearly cases of this, and MS weathered a complete rewrite c/o cutler and co. quite happily. the fact that there are examples of disastrous complete rewrites doesn't mean that the examples that worked are meaningless.
i've been using these tools for about 2-1/2 years. autoconf and automake have saved me a lot of hassle, i think. but i cannot recommend that anyone in their right minds uses libtool.
libtool starts from a reasonable premise: the creation of shared libraries is done in very different ways on different platforms. it continues on to try to provide some standard method for developers to use when they need to do this.
the problem is that for one reason or another, its gone way too far in a direction that
with a little bit of objectivity is really quite bizarre. libraries end up being built in hidden directores, and are initially replaced by text files of dependencies. you have to run "libtool -gdb" if you want to debug your program without installing the libraries first. there are many wierd and obscure consequences to this design. and don't get me started on "libltdl", the libtool
"portable dlopen() wrapper". in recent versions of this library (which were full of really stupid bugs) there are now hooks to replace malloc/realloc/free, for reasons that nobody on the libtool mailing list understood (probably some windows bullshit to do with calling malloc at some point during runtime linking, but who knows?). libltdl goes as far as "emulating support for run time linking even on platforms that don't support it". they are proud of this bizarre "accomplishment".
libtool's basic problem is that it starts out
trying to solve a goal that very few people face: trying to build a shared library on multiple platforms. because this is a very complicated task, libtool is necessarily complex. if you are writing a shared library for one or two platforms, particular where they are both fairly similar, using libtool to do this rather than doing it with your own understanding of the process can provide hours of frustration, confusion and despair.
i don't see anyway forward for libtool. the sensible way to solve shared library problems is to wrap the actual linker in a new executable that operates in a standard way across platforms. this would hide the complexities and oddities of
the process away from autoconf/automake and you.
the problem with Albini's analysis is that
it doesn't mention that the obscene $710,000 profit the record company made has to be used
to amortize all the losses it made on the new
mariah carey cd.
see, there's this problem: you're a successful
musician, and the record company appears
to be ripping you off. they probably are. but
a large part of the apparent rip off is because
they are also making lossy investments in
new artists which never work out. now, you could choose to excuse yourself from this charade,
like ani defranco and others have done, by
working on your own - you win, then you win big, but if you lose, you lose everything you put in.
however, as long as you choose to allow
somebody else to help you with the initial costs, you need to deal with the fact that their losses on other artists need to be covered by their profits on you. in such a system, the artists
are simultaneously screwed and simultaneously supported.
of course, the record companies are making obscene profits on the backs of underpaid musicians. but don't assume that when you get those numbers down
somehow that the inherent inequality in the
relationship will go away. if someone if going
to make a risky investment in several artists,
the ones that succeed will need to pay for the ones that fail. do you want your success subsidizing your fellow artists failures? do you want your failure subsidized by your fellow artists? or put another way, do you feel lucky, punk ?:))
as much as i dislike every aspect of the RIAA
and its cohorts, i know from personal
experience of starting a CD label that
they are not "as [ir]relevant as buggy whip manufacturers". producing music has become
vastly cheaper than it used to be, and
the net offers some excellent possibilities
for distributing compressed (lossy) audio.
however, the net doesn't come within 10 miles
of offering the marketing and publicity
engines that the RIAA still know how to
work (or maybe we should say control). its
also a complete waste of time for people
who want at least CD quality audio, though that will
change as bandwidth increases over time.
we spent about $5000 to do the production
copy run on our first CD, and didn't have to
pay for studio time since we own the studio.
but this music isn't the kind of stuff that most people
listen to, and the challenge of marketing
it effectively is vastly more difficult
and involved than running a website and having
some MP3's available for preview.
although their tactics and contracts suck,
the truth is that its very, very hard
to effectively market music without the
involvement of major record labels. this
is particularly true if the music you make isn't popular with the demographic that has made,
say, ani defranco such a success.
the article was about IPC (inter process
communication).
win critical sections do not provide
inter-process facilities. in fact, they
don't necessary even work efficiently
on SMP systems either. 'nuff said?
you forget the CS degree, which is largely
useless unless you want to do research.
you work for several years doing systems
programming and admin, switching jobs every year or so to work on new problems, gradually working on more and more complex systems. then you join a startup, make enough money to retire at 30, and switch to writing GPL'ed software at home, on your own time, working in any area that seems like fun to you. no management, no BS, no timetables, just problems you want to work on, on a schedule that you want to work to. i leave dealing with the decline of your net worth following your retirement as an exercise for the reader.
the third machine at amazon.com (if by machine we mean something with a hard drive rather than an X terminal) was a pentium running slackware. its name was "ccmotel", as in "credit cards check in, but they don't check out". it had a serial line running to the solaris/sparc system that had the webserver on it, and a 1-way custom protocol for moving credit card data to its dbm-based database.
the protocol had no provision for retrieving
credit card numbers (it was 1 way, remember), so
sneaker net was required to get them out: you loaded a floppy into the machine (remember those?) and ran a command that filtered the files on the floppy, substituting our credit card identifiers with real numbers. unless you had physical access to that machine, there was no way you could ever get credit card data from a disk drive at amazon.
it was a critical part of the early infrastructure of amazon. how do i know? i built ccmotel...
gtkmm, the C++ wrapper for GTK+, allows you
to choose how your widgets are managed. you can opt for "deleted by parent", "parent does nothing" and others. sometimes i want a dialog to leave
one or more of its children alone. you can't do that in Qt.
furthermore, gtkmm offers full STL
compatibility, which Qt does not, and it also
draws the line between a GUI toolkit (like GTK+) and a desktop/programming environment kit (like GNOME or KDE).
MusE is a more powerful, more appealing,
more actively developed MIDI editor and
sequencer than Jazz or Jazz++ ever was.
And besides, Jazz is not dead. The message
is simply one user expressing their concerns, which although they may be realistic, are
not definitive.
This is an extremely disingenuous comment.
As far as I can tell, it comes from the author of Broadcast 2000, who recently pulled the source
of B2000 from the net because of the fears
expressed in this message.
Several people have asked the author of B2000
to substantiate his fears of liability. There
appears to be no basis in fact for it. All
commercial software would come with the same issues, and the companies that produce it
are often not rich enough to face the kind
of lawsuit he suggests. In additional, all
software, commercial or open source, comes
with explicit disclaimers as part of the
license, and several people have suggested
that these would have no problem standing
in a court of law.
The pulling of B2000 because of un-explained
fears of legal liability was reported on slashdot, and is, IMHO, an irresponsible act. The author
should either justify his concerns, or provide
some other rationale for the decision.
As for:
you won't see open source programmers giving out more than simple
wave editors and utilities.
I don't think so. Otherwise, why would
I be spending hours and hours every day
working on a fully-fledged ProTools equivalent
called Ardour?
and then tell hime to go back to sleep for several months (at least).
very few of the major packages for audio on MacOS have been ported to Mac OS X. all new macs
ship with OS X. porting efforts are underway,
but they are not trivial if they want good
performance.
As the author of the RME Hammerfall
driver, Ardour (a pro/commercial level DAW for linux), SoftWerk and a bunch of other audio s/w for Linux, and founder of Linux Audio Systems, I probably know at least as much about this as anybody else.
the short answer to the question is that at this time, there is no software for Linux suitable for use in a pro-audio setting, if by that you mean a serious multitrack recording studio.
many have pointed to Dave Phillips fabulous web pages that list a plethora of linux audio+MIDI applications. there is some great stuff in there, but absolutely none of it would be in any way
a replacement or stand-in for ProTools, Logic Audio, Samplitude 24/96, Paris or any of the other DAW systems that studios might consider.
the closest to what you're looking for right now is probably MusE, which is a sequence that concentrates on MIDI
but has some limited audio capacity. Its under
active development. Ardour is closer in theory to what you want, but I cannot suggest that you
even try it out at this time, since it can
only be built from CVS (no tarballs) and is under
even more rapid development than MusE (I think:)
Ardour v1.0 is scheduled for some time early this
winter. That version will not support MIDI.
Other audio editors for Linux include some
fine software (snd, in particular), but their
functionality is very different (and often
much more limited) than the multichannel DAW
tools I mentioned above.
As long as most audio app authors continue to think in terms of 16 bit stereo interleaved audio, which the vast majority do at this time, the
supply of Linux pro-audio applications will
be a mere trickle.
If you want to ask more specific questions, do write. When Ardour v1.0 appears, my company,
Linux Audio Systems, will be selling prebuilt
Linux-based hardware DAWs.
--p pbd@op.net
You know, you can't have it both ways. Either
the acts of Sept. 11th were "war", or they
were "terrorism". If they were "war", then
perhaps its right for the US to go to war, but
what is the war against? War itself? It wouldn't be
the first time the country's government has
been so inconsistent. If they were "terrorism", then
why are we going to "war"?
As many others have noted, the people who
caused the tragedy of Sept 11th have real
issues with the policies of the US government.
If what you want is to declare war on
those who have such grievances, go ahead, but
its a huge number of people. If instead you
wish to pursue the perpetrators of these
hideous and cruel acts, I'm with you, but thats
not "war" - thats an international criminal investigation. Trying to redefine such an
activity as "war" to satisfy the most venal
of human emotions, revenge, is a cheap trick.
It won't bring us closer to finding the perpetrators or to a just and peaceful world in which these sorts of activities, on one scale
or another, no longer happen with depressing regularity around the globe.
and i am free to beat you over the head with
a club. its called freedom.
there are somethings that certain societies
deem to be unacceptable. murder is generally
one of them, as is theft. GPL advocates
want to add "taking away a person's ability
to modify, inspect and redistribute software".
obviously, the penalties for doing so would
never be on the same level as murder, but
the point remains: we just think you shouldn't
be able to do this, in the same way we think
you shouldn't be able to beat someone over the head.
the point is not whether the software stays free. nobody cares about the rights of software. a BSD style license allows somebody to release
software that denies its users the
freedom to inspect, modify, learn from,
redistribute and extend that software. this
freedom existed when the software was first
released (under BSD), and it has been taken
away from users when they are unaware that product X is derived from source code that they
can freely obtain.
So, by taking a BSD-licensed program, modifying
it and releasing it under a proprietary license,
somebody is going to take away rights, not from
your users, but from their own.
All true, but most people imagine that
people who break the GPL will be in violation
of the GPL. This other article (I really
wish I could post a link) is making the claim
that you would not be held to be in violation
of the GPL, just of copyright law. That would
still have pretty serious consequences (as
others have pointed out), but not those
often imagined to be the result by people who
adopted the GPL for their code.
The reason I was interested in this other
article is precisely that many people seem
to think that people who violate the GPL
will end up having to release the source
code to their products in some way. This
other author was suggesting that this is
not likely to be true, since none of the
provisions of the GPL will be held to apply,
merely copyright law. Since it may be
hard to invoke monetary damages with most
GPL'ed code, the consequences under this part
of US law may end up being very different
from what the code authors intended.
Thats not what this (other) lawyer says. His
feeling is that under many GPL-violating conditions no court would accept
that you had agreed to the license, and
thus you were simply in violation of
copyright.
The consequences of being in violation
of copyright are really quite different
from having broken a license that you
accepted. Its not that there are no
consequences from violating copyright (far
from it), but the entire contents of the GPL
become completely beside the point under
such circumstances.
Eben claims that users of GPL'ed code need
do "nothing" in order for the license
to apply.
I just read an article in a law review newsletter
on the GPL that disagrees with him, and lists
several conditions the author believes
someone would have to have taken in order to
get a court to agree that he agreed to a license.
The author continues, and I think that Eben would agree, that under such circumstances, the GPL
and its provisions are null and void - the case
becomes a simple matter of copyright infringement.
Thus, the "license breaker" could not be
forced to release their own source code.
The article is not online unfortunately,
else I would have posted it here.
Re:Some corrections to the "article"
on
DeMuDi Linux
·
· Score: 1
RTLinux provides realtime *guarantees*. The low latency patches merely make it overwhelmingly likely that you will make your timing deadlines (if you use POSIX RT scheduling, anyway).
No, 0ms is never possible, but RTLinux can
offer timing guarantees on the same order as
the h/w (tens of microseconds).
Re:This is very nice...
on
DeMuDi Linux
·
· Score: 1
"the groundwork for a sleek kernel" is already done.
Multichannel audio has much more demanding requirements than typical video, and the standard kernel plus Andrew Morton's or Ingo Molnar's low latency kernels can provide applications with
a phenomenal environment for soft-realtime work.
Andrew's patches more or less guarantee that
an application driven by a h/w interrupt (e.g. from an audio interface) will never miss
a deadline by more than 1ms.
I already use and develop such a system
for multichannel audio work, and the kernel
is simply not an issue. I run with h/w
interrupts every 1.3ms, and nothing ever
goes wrong.
--p
Re:Again, Linux's issue is software
on
DeMuDi Linux
·
· Score: 5
As the author of Quasimodo, I beg to differ.
Quasimodo is not a sequencer, and more
importantly, its a dead project at this
point, for many reasons.
You should be looking at MusE which is a
really high quality MIDI sequencer.
As an aside, if the MIDI specs look daunting, I would forget about even considering programming in this field. MIDI is one of the simplest protocols there is, and one of the simpler problems in the area of MIDI/Audio programming.
--p
Slashdot Mirror
it doesn't have the bandwidth to scale to semi-pro let alone pro use. the latency characteristics are just barely acceptable. the entire protocol design wasn't properly thought out for high-bandwidth streaming data services. thats what IEEE1394 is for, both in terms of its bandwith capacity but also the design of the protocol. if you're just streaming stereo 16 bit 44.1kHz streams to and from your box, i'm not suprised you think that USB works. you're at the low end of the audio scale, and there are many things that will work for you that will break for people with more demanding requirements. --p
- devices like this have existed for more
than 2 years. products from Midiman,
SEK'D, Event Systems and other companies
offered this kind of configuration for
some time. its becoming more common
all the time.
- creative's audio products are widely
recognized by anyone with any experience
as being basically "just good enough" crap. they have terrible noise problems, and often come with basic h/w engineering problems (such as a fixed rate sample clock that forces resampling at any rate other than the chosen one).
- USB for audio is a bunch of crap. It can be
made to work, but its being used only because
most computers these days come with USB ports,
and far fewer come with IEEE1394 ports. It has no redeeming qualities and many drawbacks. There
are bandwidth problems, reliability problems, connector stability problems, protocol conformance problems - it goes on and on.
- IEEE1394 ("firewire") is vastly superior, but suffers from a lack of standardization on the
transport-level protocol used for audio and MIDI
data. There are at least 3 or 4 competing versions of this, with no resolution in sight.
- Several people have pointed out the lack of
balanced connectors, as well as the lack of XLR
connectors (these two items are strictly orthogonal from one another). Balanced analog I/O is a serious must-have for anything other than
the typical low-quality audio stuff 95% of you
do with your computers. Of course, that 5% might not be a big enough market to make it worth offering
:)
companies like creative are busy trying to make devices that appeal to many consumer's desire for stuff that appears to be "pro" or "semi-pro" gear. creative in particular has failed to make any equipment that even comes close to these descriptions. if audio on your computer matters to you enough that external converters are important, you should not be paying any attention to the extigy, but should instead be paying attention to products from Terratech, Event (even though they refuse to make linux support possible, they are nice devices), Midiman (Delta series) or RME. If you're really serious about audio on your computer, you'd already know that you should be basically buying an audio interface that supports ADAT optical connections and then a totally separate converter box (such as the Tango24 from Frontier Designs, or the ADI series from RME, or if money is tight, perhaps a Fostex unit). this configuration allows you to upgrade your A/D-D/A capabilities and the audio interface independently, which in turn implies the potential for improved channel counts and/or improved converters at a later date. --pseveral people have claimed that NT wasn't a rewrite and that it was based on OS/2. this is false. MS hired dave cutler from DEC, cutler picked a team of programmers, and they wrote "NT" (which stands for "New Technology" [sic]) from scratch. it was not derived from OS/2, though it may borrow ideas from it. it borrows as much from VMS as it does from OS/2. readers may be confusing the NT kernel (which i was referring to) with the NT UI (which i was not referring to.
ahem. what was NT for? sometimes, you just have to come to terms with the fact that as tested, bug-fixed and studied as a chunk of code may be, it was developed as part of a misconceived model of either visible functionality or internal architecture or both. DOS and its progeny like win32 were clearly cases of this, and MS weathered a complete rewrite c/o cutler and co. quite happily. the fact that there are examples of disastrous complete rewrites doesn't mean that the examples that worked are meaningless.
i've been using these tools for about 2-1/2 years. autoconf and automake have saved me a lot of hassle, i think. but i cannot recommend that anyone in their right minds uses libtool. libtool starts from a reasonable premise: the creation of shared libraries is done in very different ways on different platforms. it continues on to try to provide some standard method for developers to use when they need to do this. the problem is that for one reason or another, its gone way too far in a direction that with a little bit of objectivity is really quite bizarre. libraries end up being built in hidden directores, and are initially replaced by text files of dependencies. you have to run "libtool -gdb" if you want to debug your program without installing the libraries first. there are many wierd and obscure consequences to this design. and don't get me started on "libltdl", the libtool "portable dlopen() wrapper". in recent versions of this library (which were full of really stupid bugs) there are now hooks to replace malloc/realloc/free, for reasons that nobody on the libtool mailing list understood (probably some windows bullshit to do with calling malloc at some point during runtime linking, but who knows?). libltdl goes as far as "emulating support for run time linking even on platforms that don't support it". they are proud of this bizarre "accomplishment". libtool's basic problem is that it starts out trying to solve a goal that very few people face: trying to build a shared library on multiple platforms. because this is a very complicated task, libtool is necessarily complex. if you are writing a shared library for one or two platforms, particular where they are both fairly similar, using libtool to do this rather than doing it with your own understanding of the process can provide hours of frustration, confusion and despair. i don't see anyway forward for libtool. the sensible way to solve shared library problems is to wrap the actual linker in a new executable that operates in a standard way across platforms. this would hide the complexities and oddities of the process away from autoconf/automake and you.
making people aware of your music, hopefully to the point of wanting to pay for it, is expensive.
the problem with Albini's analysis is that it doesn't mention that the obscene $710,000 profit the record company made has to be used to amortize all the losses it made on the new mariah carey cd. see, there's this problem: you're a successful musician, and the record company appears to be ripping you off. they probably are. but a large part of the apparent rip off is because they are also making lossy investments in new artists which never work out. now, you could choose to excuse yourself from this charade, like ani defranco and others have done, by working on your own - you win, then you win big, but if you lose, you lose everything you put in. however, as long as you choose to allow somebody else to help you with the initial costs, you need to deal with the fact that their losses on other artists need to be covered by their profits on you. in such a system, the artists are simultaneously screwed and simultaneously supported. of course, the record companies are making obscene profits on the backs of underpaid musicians. but don't assume that when you get those numbers down somehow that the inherent inequality in the relationship will go away. if someone if going to make a risky investment in several artists, the ones that succeed will need to pay for the ones that fail. do you want your success subsidizing your fellow artists failures? do you want your failure subsidized by your fellow artists? or put another way, do you feel lucky, punk ? :))
as much as i dislike every aspect of the RIAA and its cohorts, i know from personal experience of starting a CD label that they are not "as [ir]relevant as buggy whip manufacturers". producing music has become vastly cheaper than it used to be, and the net offers some excellent possibilities for distributing compressed (lossy) audio. however, the net doesn't come within 10 miles of offering the marketing and publicity engines that the RIAA still know how to work (or maybe we should say control). its also a complete waste of time for people who want at least CD quality audio, though that will change as bandwidth increases over time. we spent about $5000 to do the production copy run on our first CD, and didn't have to pay for studio time since we own the studio. but this music isn't the kind of stuff that most people listen to, and the challenge of marketing it effectively is vastly more difficult and involved than running a website and having some MP3's available for preview. although their tactics and contracts suck, the truth is that its very, very hard to effectively market music without the involvement of major record labels. this is particularly true if the music you make isn't popular with the demographic that has made, say, ani defranco such a success.
the article was about IPC (inter process communication). win critical sections do not provide inter-process facilities. in fact, they don't necessary even work efficiently on SMP systems either. 'nuff said?
you forget the CS degree, which is largely useless unless you want to do research. you work for several years doing systems programming and admin, switching jobs every year or so to work on new problems, gradually working on more and more complex systems. then you join a startup, make enough money to retire at 30, and switch to writing GPL'ed software at home, on your own time, working in any area that seems like fun to you. no management, no BS, no timetables, just problems you want to work on, on a schedule that you want to work to. i leave dealing with the decline of your net worth following your retirement as an exercise for the reader.
the third machine at amazon.com (if by machine we mean something with a hard drive rather than an X terminal) was a pentium running slackware. its name was "ccmotel", as in "credit cards check in, but they don't check out". it had a serial line running to the solaris/sparc system that had the webserver on it, and a 1-way custom protocol for moving credit card data to its dbm-based database. the protocol had no provision for retrieving credit card numbers (it was 1 way, remember), so sneaker net was required to get them out: you loaded a floppy into the machine (remember those?) and ran a command that filtered the files on the floppy, substituting our credit card identifiers with real numbers. unless you had physical access to that machine, there was no way you could ever get credit card data from a disk drive at amazon. it was a critical part of the early infrastructure of amazon. how do i know? i built ccmotel...
gtkmm, the C++ wrapper for GTK+, allows you to choose how your widgets are managed. you can opt for "deleted by parent", "parent does nothing" and others. sometimes i want a dialog to leave one or more of its children alone. you can't do that in Qt. furthermore, gtkmm offers full STL compatibility, which Qt does not, and it also draws the line between a GUI toolkit (like GTK+) and a desktop/programming environment kit (like GNOME or KDE).
MusE is a more powerful, more appealing, more actively developed MIDI editor and sequencer than Jazz or Jazz++ ever was. And besides, Jazz is not dead. The message is simply one user expressing their concerns, which although they may be realistic, are not definitive.
and then tell hime to go back to sleep for several months (at least).
very few of the major packages for audio on MacOS have been ported to Mac OS X. all new macs
ship with OS X. porting efforts are underway,
but they are not trivial if they want good
performance.
As the author of the RME Hammerfall driver, Ardour (a pro/commercial level DAW for linux), SoftWerk and a bunch of other audio s/w for Linux, and founder of Linux Audio Systems, I probably know at least as much about this as anybody else. the short answer to the question is that at this time, there is no software for Linux suitable for use in a pro-audio setting, if by that you mean a serious multitrack recording studio. many have pointed to Dave Phillips fabulous web pages that list a plethora of linux audio+MIDI applications. there is some great stuff in there, but absolutely none of it would be in any way a replacement or stand-in for ProTools, Logic Audio, Samplitude 24/96, Paris or any of the other DAW systems that studios might consider. the closest to what you're looking for right now is probably MusE, which is a sequence that concentrates on MIDI but has some limited audio capacity. Its under active development. Ardour is closer in theory to what you want, but I cannot suggest that you even try it out at this time, since it can only be built from CVS (no tarballs) and is under even more rapid development than MusE (I think:) Ardour v1.0 is scheduled for some time early this winter. That version will not support MIDI. Other audio editors for Linux include some fine software (snd, in particular), but their functionality is very different (and often much more limited) than the multichannel DAW tools I mentioned above. As long as most audio app authors continue to think in terms of 16 bit stereo interleaved audio, which the vast majority do at this time, the supply of Linux pro-audio applications will be a mere trickle. If you want to ask more specific questions, do write. When Ardour v1.0 appears, my company, Linux Audio Systems, will be selling prebuilt Linux-based hardware DAWs. --p pbd@op.net
You know, you can't have it both ways. Either the acts of Sept. 11th were "war", or they were "terrorism". If they were "war", then perhaps its right for the US to go to war, but what is the war against? War itself? It wouldn't be the first time the country's government has been so inconsistent. If they were "terrorism", then why are we going to "war"? As many others have noted, the people who caused the tragedy of Sept 11th have real issues with the policies of the US government. If what you want is to declare war on those who have such grievances, go ahead, but its a huge number of people. If instead you wish to pursue the perpetrators of these hideous and cruel acts, I'm with you, but thats not "war" - thats an international criminal investigation. Trying to redefine such an activity as "war" to satisfy the most venal of human emotions, revenge, is a cheap trick. It won't bring us closer to finding the perpetrators or to a just and peaceful world in which these sorts of activities, on one scale or another, no longer happen with depressing regularity around the globe.
and i am free to beat you over the head with a club. its called freedom. there are somethings that certain societies deem to be unacceptable. murder is generally one of them, as is theft. GPL advocates want to add "taking away a person's ability to modify, inspect and redistribute software". obviously, the penalties for doing so would never be on the same level as murder, but the point remains: we just think you shouldn't be able to do this, in the same way we think you shouldn't be able to beat someone over the head.
the point is not whether the software stays free. nobody cares about the rights of software. a BSD style license allows somebody to release software that denies its users the freedom to inspect, modify, learn from, redistribute and extend that software. this freedom existed when the software was first released (under BSD), and it has been taken away from users when they are unaware that product X is derived from source code that they can freely obtain. So, by taking a BSD-licensed program, modifying it and releasing it under a proprietary license, somebody is going to take away rights, not from your users, but from their own.
All true, but most people imagine that people who break the GPL will be in violation of the GPL. This other article (I really wish I could post a link) is making the claim that you would not be held to be in violation of the GPL, just of copyright law. That would still have pretty serious consequences (as others have pointed out), but not those often imagined to be the result by people who adopted the GPL for their code. The reason I was interested in this other article is precisely that many people seem to think that people who violate the GPL will end up having to release the source code to their products in some way. This other author was suggesting that this is not likely to be true, since none of the provisions of the GPL will be held to apply, merely copyright law. Since it may be hard to invoke monetary damages with most GPL'ed code, the consequences under this part of US law may end up being very different from what the code authors intended.
Thats not what this (other) lawyer says. His feeling is that under many GPL-violating conditions no court would accept that you had agreed to the license, and thus you were simply in violation of copyright. The consequences of being in violation of copyright are really quite different from having broken a license that you accepted. Its not that there are no consequences from violating copyright (far from it), but the entire contents of the GPL become completely beside the point under such circumstances.
Eben claims that users of GPL'ed code need
do "nothing" in order for the license
to apply.
I just read an article in a law review newsletter
on the GPL that disagrees with him, and lists
several conditions the author believes
someone would have to have taken in order to
get a court to agree that he agreed to a license.
The author continues, and I think that Eben would agree, that under such circumstances, the GPL
and its provisions are null and void - the case
becomes a simple matter of copyright infringement.
Thus, the "license breaker" could not be
forced to release their own source code.
The article is not online unfortunately,
else I would have posted it here.
RTLinux provides realtime *guarantees*. The low latency patches merely make it overwhelmingly likely that you will make your timing deadlines (if you use POSIX RT scheduling, anyway). No, 0ms is never possible, but RTLinux can offer timing guarantees on the same order as the h/w (tens of microseconds).
"the groundwork for a sleek kernel" is already done. Multichannel audio has much more demanding requirements than typical video, and the standard kernel plus Andrew Morton's or Ingo Molnar's low latency kernels can provide applications with a phenomenal environment for soft-realtime work. Andrew's patches more or less guarantee that an application driven by a h/w interrupt (e.g. from an audio interface) will never miss a deadline by more than 1ms. I already use and develop such a system for multichannel audio work, and the kernel is simply not an issue. I run with h/w interrupts every 1.3ms, and nothing ever goes wrong. --p
As the author of Quasimodo, I beg to differ. Quasimodo is not a sequencer, and more importantly, its a dead project at this point, for many reasons. You should be looking at MusE which is a really high quality MIDI sequencer. As an aside, if the MIDI specs look daunting, I would forget about even considering programming in this field. MIDI is one of the simplest protocols there is, and one of the simpler problems in the area of MIDI/Audio programming. --p