John Check <j4strngs(a)bitless.net> wrote:
> "what the hell, there couldn't be any more major
> updates". Wrong - one the updates in the batch that
> took 2 days to build got rolled back, and since
> there's no binaries
Tell it to build binary packages, include the relevant
flags to emerge to say "use binaries if you got 'em",
and downgrades are almost as fast as rpm/deb systems.
I love having the source archives to hand when I want
to make changes - sure, not everyone wants this, and
gentoo might not be suitable for them... and getting
the source isn't always that difficult... but if you've
ever been severed from the internet and want to change
or fix or just look at a bit of code on your running
system, chances are that it's in /var/distfiles ready
to be used.
I might carry around a Knoppix CD for luck, but Gentoo
has a permanent home on every one of my computers.
emerge is dead slow on anything less than a P-III
though - especially searching and the last stage of
a sync (index regeneration or whatever it is). Got
a P-II that takes about ten minutes after the
last bit of data has rsync'ed across before the prompt
comes back.
Compilation time is even longer? Sure, but I'd expect
that. I don't expect the package manager to waste
valuable compilation CPU cycles :)
(no, it's not a big problem. yes, one day I'll even
try rewriting portage in C if no one else has)
TM
Good Morning,
Here's the position paper I drafted up. As usual I'll request that responses
be well considered. I'll post this to my webserver after I have a chance to
mark it up and hopefully, I can stop repeating myself and get things
implemented. Apologies in advance for the length. Comments on what I propose
to do are welcome, but it may take a while for me to reply.
--------
Legitimizing Linux As an Audio Platform.
The current state of affairs WRT to Linux as a platform for audio production
is an open question, but in my considered opinion it is technically adequate
to start getting some real traction. At the current pace, there will be some
truly excellent applications in a years time, but it must be understood that
everybody has time limitations and not taking that into account is
counterproductive.
Bottom up penetration (simmer down now) is the most likely to succeed path,
however there are some issues which need to be addressed to improve on the
chances and avenues. These issues are outside of the scope of interest for
most developers. The pattern seems to be the people with the highest level of
technical expertise are the least interested in these issues and that is as it
should be. Coders should code, EE's should handle the physics, etc. In short,
we all need to play to our strengths, especially since most of what goes on is
done voluntarily.
The issues that are playing against the community at large are not
insurmountable obstacles and I intend to do some heavy lifting to try and
change things. There are several phases to getting where we need to go, but
here are the primary stumbling blocks. First I'll layout the issues, which
fall into two categories, then I'll reveal my strategy for tackling them and
why I think these opinions matter.
The Issues:
1) Too Much Information
A) Unclear development status and suitability of offerings.
B) Unreasonable requirements for list monitoring.
C) To much time spent on repetition of information in the wrong places.
D) Disorganized and inadequate documentation.
2) There's Only 24 Hours In A Day
A) Unnecessarily high time requirements for building code to evaluate.
B) A somewhat distorted sense of what musicians and pro audio need/want
C) Nobody cares about Linux except the converted.
D) No compelling business case.
Let's break it down:
Too Much Information
Unclear Development Status And Suitability Of Offerings
http://linux-sound.org
There is in excess of 36 categories of applications listed at the above URL.
The "Sound Editors" category alone has 35 entries just in it's "General"
sub-category. Each of these has their own particular raison d'etre and
diversity is a good thing, but 3 of the first 10 listed projects according to
timestamps on tarballs, haven't had a release in over 12 months. Two of the
ten are Java based and one is a KDE app which means artsd.
This particular sub-category has a relatively good ratio of active projects,
but even so this means 7 pieces of software to evaluate when looking for a wav
editor. We could extrapolate that number, but 7 is a good start and it
includes some of the best candidates.
Unreasonable Requirements For List Monitoring
We've got 7 candidates for evaluation, 2 are unavailable as Debian packages.
This isn't a problem because I use Debian, it's just an example. This is two
out of 7 packages that need to be built from source. Again, it's not a problem
for me, but assuming the user isn't comfortable with that, we're down to 5 on
Debian and probably less on some other general purpose distros.
So we install our 5 binary packages and have a pretty good idea what they can
do, but if the user wants in depth info that's not covered in the
documentation that comes with the package it's time for mailing lists. Most
have at least 2 lists one for developers, one for users. That's potentially 10
lists subscriptions and 5 Wikis. 15 sources of information for 5 programs, not
counting the man page and whatever is in the help menu.
The key to making the lists useful is participation. If there is no traffic on
the users list, it's a safe bet it's not because the programs UI is so
intuitive that nobody has a question. There is a threshold of tolerance for
user questions on the developer lists and that is also as it should be.
Too Much Repetition of Information In Too Many Places
See Unreasonable Requirements For List Monitoring ;)
There is an interesting corollary here with the LA lists. I'm guessing that LA
is supposed to be among other things, a sort of clearinghouse so that
everybody has a place to get an overview of the big picture. I have personally
seen a developer quote one of his own postings to an LA list in order to
answer a specific on-topic question asked on his own project's list.
Searching that project's list archive for this bit of info (which was pretty
crucial) came up dry until the question was asked on the project's list and
the person replying was helpful enough to find his LA post and answer what the
question was. Not only was that aggravating to watch, but it was duplicated
effort on the part of the developer answering the question.
Disorganized And Inadequate Documentation
It is not reasonable to expect coders to spend a lot of time on documentation.
They can either improve the code or improve the documentation and even if we
disregard the moving target factor, the latter isn't playing to their
strength. Theoretically at least, if a user has a question that's not covered
in the documentation and wants to help out, the coders will cooperate. The
tendency is for build related questions to be well documented but stale,
because Linux is a fast moving target with lots of parallel development and of
course, actively maintained code changes.
One common solution is to provide a Wiki so that users can maintain their own
documentation easily. This is a good way to accumulate information, but it has
its drawbacks. Chief among them is the requirement to visit the Wiki in order
to use it, which can be problematic. Additionally, it's not unusual for the
Wiki to not be accessible from the "Documentation" link and vice versa.
Wiki's, like the rest of free software development are participation driven,
which makes a good segue into the next part. If you had to look up "segue" pay
close attention.
There's Only 24 Hours In A Day
I'll start out prefacing this by saying software is built for a purpose. If
I'm looking for a new construction house, I
can buy one or build one. I may be a big Bob Vila fan and choose to build
one, but that doesn't mean I'm a fan of
Roy Underhill and want to make my own lumber too. Or forge my own hammer and
nails. Given enough stress, and
wasted time, I'll more than likely to bail and find a contractor to finish,
or even go buy a built house. Even if it's not custom
and the roof leaks, the builder at least acknowledges the obligation to fix
the leaky roof. I suppose free software is
more like an old fashioned barn raising, but anybody participating in one of
those sticks to what they can do and
knows what a barn is supposed to be. Marble floors and a media center is nice
in a building, but it doesn't keep
the livestock dry.
Unnecessarily High Time Requirements For Building Code To Evaluate.
This is highly variable. Some projects have better build processes than
others, and less bleeding edge requirements. As projects mature
things tend to improve, but not always. It's not unheard of for an early on
decision to leave a legacy of problems that only become more
bothersome as time passes. It's not reasonable to expect this to change due to
inertia, but these types of problems generate questions that fall into
the "it's obvious to me" category. It's also not reasonable to expect users to
either fix it or eat shit and like it. If a user spends enough time with the
doco
and the list archives they can usually hash it out build problems, but there
comes a point when one either has to go "Gentoo" and drink the koolaid
because of the time invested. (I've been there and if you're a Gentoo user who
wants to flame me, tell me you didn't _want_ to love it after the time
invested to install it fully bootstrapped). Or, the user gets fed up and moves
to another piece of software. That's known as "getting burned" and it
doesn't generate goodwill. If it happens enough times it ceases to become a
[G|K|X]foo problem and becomes a LA problem because unhappy
users complain loudly. Happy ones are mostly silent.
What it has to do with LA is, people trying to use these programs for
relaxation or to make a living with audio/music have time constraints too.
One might be a tech in a going facility that got a green light to do some
experimentation with LA when nothing else is going on, but if a paying client
has a problem with the headphone system that the tech didn't get around to
fixing because he was cocking around trying to find an answer to something
that was "obvious to me" or even worse figure out why "it works for me" and
not him, guess which facility isn't going to be testing any LA software?
A Bob Clearmountain or Bruce Swedien certainly isn't likely to spend the time
tweaking out a system.
This kind of thing can fly in a weekend project studio, but if you have a tech
with that much time on his hands, you probably can't afford to pay
for deadwood, unless maybe you use the studio as a cover to launder money, in
which case "free" _really_ has no place there. (If you just started
looking at the floor and shuffling your feet, I do consulting ;)
On the other end of it (the low, low end ;) are schmucks like me who just want
to gig, and while I have the time and the inclination to do this,
it still cuts in to rehearsal and promotion time, which means less work for me
and less exposure for you. We need each other, so let's not be coy.
A Somewhat Distorted Sense Of What Musicians And Pro Audio Need/Want
Again, this is variable. Some applications, like Ardour and Jamin, would drop
right into a professional setting, because they do
what they're supposed to and the interface is what people who use these kinds
of tools expect, even if they're not 1:1 knock-offs of commercial apps.
Other tools like oh, say Ecasound, or Cecilia would flop, especially with the
"prosumer" crowd that buys things like standalone HD recorders and synth
modules. These apps may be technically excellent, but look at how many
musicians can't even read standard notation! If these kinds of folks want to
get
experimental, it's power it up and twist some dials and see where it goes.
Neither one has an interface suitable for spontaneous creative monkeying.
Cecilia would fare better than ecasound in that scenario, but chances are
anybody that could use either of them effectively to create traditional music
is an EE or a CS by day. My intention is not to slam either of these apps.
They've been around for a relatively long time for a reason; They work.
They're just a tad esoteric for general use and fill a niche.
I'm not aware of any commercial software that does any of these things that
doesn't have it's share of problems too. The tendency in professional
settings is to be conservative with revisions and put off updates until
somebody else has tested them, or if they have on staff techs and a lab,
stress
test well before inserting it in the revenue stream. The difference, when it
comes to whether or not time spent getting support is worth the cost is
simple.
The vendor is obligated to come up with answers and the cost is quantifiable
up front. If somethings not going to happen, they tell you. "We don't support
foo". You may hear "Foo will be supported in the next version" from marketing,
but you don't see that on the homepage they way you see "Aims to support
foo, bar and baz" on a lot of sourceforge homepages.
Nobody Cares About Linux Except The Converted.
They really don't. They care about quality and stability, sure, but just
because it runs on Linux doesn't mean it's inherently stable or high quality.
There's a joke among sound men and recording engineers that all the equipment
runs on magic smoke. Once you let the smoke out, it doesn't work
anymore. All that matters is that it works as advertised, and not just to the
bean counters. A Windows power user that can put together his own
ProTools DAW isn't going to be real interested in feeling like a noob and
getting flack because he's not comfortable patching kernels. They may not
even be comfortable getting DeMuDi up and running. It doesn't mean they're an
idiot, it means they know their limitations. Fortunately, this particular nit
is not news. Of course Macs are still solidly entrenched so that
has to tell you something.
No Compelling Business Case.
Yes, I know, it's not about the money. Well, I hate to be the one to tell you,
but as soon as you say "professional", it is. And let's face it, if you're
a core developer and you were offered a royalty or even a salary to do what
you're doing for free you'd take it. There's no reason you shouldn't
benefit even if there's no legal requirement for a vendor to show
appreciation. You wouldn't have a legal obligation to address the vendors
requests
without a contractual obligation now either, would you?
Now that that's out of the way, let's consider the business angle from a
potential user's point of view, relative to the standard arguments for free
software.
Joe Haxor: It runs on Linux!
Mark Pigeon: What? On Lindows? I saw that in K-Mart, I wasn't impressed
JH: You'll get a lifetime of free upgrades.
MP: How often do these upgrades break file format compatibilty?
JH: Almost never... Sometimes it happens, but somebody can write a
filter.
MP: Almost? What about my archived work?
JH: And it will always be supported, because you can fix it yourself!
MP: But I'm not a programmer. I took a course in BASIC when I was in school,
but that was a while ago.
JH: Basic huh? That must have been some school. That's okay though, you can
always hire a programmer!
MP: I'm not a software house, I do radio spots.
JH: Well, it doesn't cost anything, so you can pay the programmer per diem
with what you save on commercial software!
MP: Mmm lemme call my accountant. (ring ring, yack yack) He says custom
software isn't deductible.
JH: It's not custom!
MP: Hang on (yack yack) He says it still not C.O.T.S. even before we modify
it.
JH: Tell him you can take the money you save on software and get twice as
much hardware, that's deductible!
MP: But then what do I pay for bug fixes with? And besides if I bring a
programmer in they still have to wrap their head around the
code.
JH: AHA! You can hire the original programmer :D Now who better to fix the
code than the guy who wrote it! :D
MP: You mean the guy that implemented the bugs in the the first place? What
happens if he gets hit by a bus?
JH: Uh, well, um, there's a half dozen guys on the team and I know the code,
so you can always hire me.
MP: Well.. I guess thats true, but how do I know you'll be available? I'll
tell you what, let's talk about hardware, now what's the
warrantee like?
JH: That'd depend on who you buy the hardware from.
MP: I was thinking I'd buy it from you, since you're trying to sell me. What
do you suggest?
JH: Let's see.. you want a Foomax2k5 SMP board with a Flaprack googleplexer
and
MP: A wha? Lemme ask you this, what's it cost per I/O channel?
JH: Depends on what you want.
MP: I want to go have lunch. Go work up 2 year lease price on 24 channel
system with a years support and 24 hr on-site emergency
response and fax it to me when you have a number.
JH: Why would you lease?
MP: Okay, I have a business lunch to get to, let me walk you to your car.
The moral of the story: There is no such thing as free and people have things
to do.
So What's Your Plan Smartass?
First thing is to improve the documentation factor to help make things easier
for the brave. Right now it's a Gordian knot and here are what the scissors
look like. I expect we all know what a MIDI implementation chart is.
I'm going to whomp up a database driven reporting system that extends the
concept to include protocol and library support and has some
Wiki like features. One will be able to search for specific types of programs
with specific criteria like:
Sequencers with LADSPA, JACK, DSSI, MESS, OSC, PHAT (Yes PHAT is that cool)
Hits will come back in table form with checkmarks in the appropriate columns,
ranked by how much of a match and a "freshness" date.
The app name will link to the project site and there will be additional links
to the primary documentation and the Wiki, if one exists.
There will also be a link to and reporting form for an MI chart.
Forms will be radio buttons/check boxes/combo boxes.
The only text input will be for URLs. This should minimize grammatical and
language issues as well as make internationalization easy.
Links will be validated at a regular interval and 404's will generate an email
to me, or if someone has taken responsibility for a project, that person.
Bounced emails to that address will be returned to me for further
investigation.
This is intended for both developers and end users. It will take no more than
5 minutes to file a complete report.
This may sound like a burden for the developers, but no more than a Wiki is a
burden on users. I'll prime the pump with some reports on what I use myself.
Newly interested users looking to help out on projects should find filing a
report to be a good way to begin.
This by itself isn't quite enough, but it's a start. I'm also planning on
subscribing the system to the LAA list or possibly spidering
the list archive for announcements to get the ball rolling with automating
some of the updating. As far as library support goes, I'm going to keep
a CVS tree of what I consider to be the cream that will be cron'ed to update
daily, then recursed and diffed for new options in configure files. New
options
will initially generate an email to me, and if all goes well will eventually
report directly to the system.
I would appreciate any ideas on what should be included, but I'm not going to
get into extended debates about what should be in.
I'm the ultimate arbiter, at least until it debuts. The basic manual reporting
and search should be live in 7-10 days.
What About The Business Angle Then, Donald Chump?
That's the easy part. I'm laying the legal groundwork for becoming a vendor
and support channel for turnkey systems. There is a lot of
money spent on this kind of stuff and if price is a factor, it only takes a
few dollars difference. Anything more than that is counter productive.
If you don't believe me, have a garage sale and put out a box of "free" stuff,
then after an hour or two put "$1" on it people might haggle you down but
it'll move.
"Linux" will be on the last page of the brochure. If all goes according to
plan the biggest chunk of revenue is going into R&D, which means to guys
who've been doing heavy lifting on the core apps.
Anything they're not interested in gets farmed out, most likely on a bounty.
Despite the apparent lack of popularity of the idea, it will have distributed
processing as an option. This will allow for incremental penetration and
interoperability with
existing systems. Depending on the budget one has there are more ways to skin
that cat than the plugin route. We have MADI support on the platform
for the high end and good old coax for low end applications like live FX
processing.
And there you have it. Why these opinions should matter is self evident.
Hi,
I feel like it's not a usual way to ask for contributions, but, well,
I thought I'd give it a try :
I'm the author of Jackbeat, at http://xung.org/jackbeat, and my day
job's currently eating my time. I've just released the 0.3 development
version which is a rewrite, forked from the (quite) stable 0.2 branch.
Here comes the todo list :
* Saving and loading songs is broken. This has to be rewritten :
- implement a new song file format, based on an xml metadata format,
with all samples stored in a subdirectory, all that packed in a tar
archive, using libtar (http://www.feep.net/libtar). FLAC compression
would be nice as well.
- provide backward compatibility for jackbeat 0.2's .jab binary file
format
* Pattern nesting. This allows using another instance of Jackbeat as a
sample. This is called "buses" in some other software :
- this is half-implemented
* Syscall-free IPC :
- currently posix message queues are used to talk with the JACK thread.
This has to be changed to a lock-free fifo.
Jackbeat do have users, and I'd really like to keep it alive. If any of you
have interest in participating in this project, especially by contributing
some code, please let me know.
About the song file format : it looks to me like this tar+xml+flac
format could be implemented as a library. Chances are that it could
be reusable in many contexts.
Regards
--
og
On Aug 20, 2004, at 6:43 PM, Paul David wrote:
> there may be people who are sight-impaired who manage to make a living
> as an audio engineer, but i would guess that i could count them all on
> the fingers of one hand.
Sound on Sound (or maybe it was Mix ...) did a feature article on two
blind
engineers who built their own studio to work out of ... it was a really
interesting
article, but I can't seem to locate on the web at the moment ... maybe
someone
can find it and post the link (it was a free article, I'm not a
subscriber to either).
---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---
Hi,
Have you ever wondered if it is possible to escape the limits imposed
by your cpu to the number of ladspa plugins you can run simultaneously,
while keeping latency low? Well, yes, there is.
This email is to let you know about DLADSPA (Distributed LADSPA). While
there are a few rough edges on the code, there has been some talk related
to it on this list and so I'm bringing it to the table.
DLADSPA allows you to group several LADSPA plugins on a chain that appears
as a single "meta-plugin". This meta-plugin is loaded by your application
as any other plugin, but in fact it loads the "real" plugins in the chain
on a remote machine and sends the data for remote processing at each
interaction.
There are some limitations:
- the system needs every period to be the same size (unless you are not
running in real-time or the remote load is *very* low, but then what
is the point?).
- The system adds to the latency the equivalent of a single period. That
is, if your period size is 2ms for a total input-to-output latency of
4ms, the system adds another 2ms to the latency, so total latency goes
to 6ms.
- You cannot define the chain of plugins to be loaded remotely from
within your application; that needs to be done separately (using
jack-rack), the chain must be saved and the application restarted.
- right now, there is a simple GUI missing, configuration is complicated
thanks to a corba layer that needs to be eliminated, the code is
tricky to compile (but it *does* compile on debian stable) and error
handling is non-existant (any error calls exit(), which means your app
crashes).
If jack udp transport doesn't work adequately (haven't tested it), I
intend to adapt the code to work on top of jack too (should be reasonably
easy).
It is available at my homepage:
http://gsd.ime.usp.br/~lago/masters
Hope you enjoy it,
Nelson
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Hello, I have been googleing around trying to find information on raw
pcm data. Does anybody know of any tutorials or references on raw pcm
data? I am most curious about different storage types (2s complement,
etc), and how multiple channels are stored. Thanks. -Garett
dssi-vst is a DSSI wrapper plugin for VST plugins. It enables any
compliant DSSI host to use VST instruments and effects. It requires
Wine, liblo-0.9, dssi.h, and the Steinberg VST SDK headers to build.
http://sf.net/projects/dssi/http://www.winehq.org/http://plugin.org.uk/liblo/http://www.steinberg.net/steinberg/ygrabit/index.html
dssi-vst is self-contained code, it doesn't use vstserver or libfst.
There's no very compelling reason for that, and there's nothing
inventive about it, but it works quite well for me with all two of
the existing DSSI hosts.
dssi-vst is licenced under the GPL with an additional exemption to
cover the non-redistributability of the Steinberg SDK headers. This
means it is technically not Free Software in the Debian/FSF sense.
Again, see the README for more details.
Chris
liblo is an implementation of the Open Sound Control[1] protocol for POSIX
systems. It is released under the GPL. It is written in ANSI C.
http://plugin.org.uk/liblo/
This release adds: (over the last stable release, 0.5)
* Nonblocking mesage dispatcher (useful for single GUI-thread
applications, eg Qt, GTK+)
* bugfixes to URL handling (0.6 - 0.8 broke DSSI)
* UNIX domain (FIFO) socket server/client support
* TCP domain socket server/client support
* A method to stop server threads
* Better regression tests (testlo)
* Fixed memory leaks
* More documentation
* Dynamic library building fixes
- Steve
[1] http://www.cnmat.berkeley.edu/OpenSoundControl/
Quoting Paul Davis <paul(a)linuxaudiosystems.com>:
> wrong model. a given jackd has a single driver. a new jack client,
> sure.
I believe the way to do this is to have one remote jackd with a driver
that sends/receives data through UDP and one local jack client that
interacts with this remote server.
There is something like this already, I believe (haven't checked):
http://www.alphalink.com.au/~rd/m/jack.udp.html
As a side note, the system I developed intends to do this over ladspa;
more on this on another message.
> oh, and a small correction. VST System Link has basically nothing to
> do with networked audio. [...] it does *not* distribute audio
> across the network at all.
If I understood it correctly, yes it does, but their concept of a
"network" is somewhat weird: it allows you to send data from one
machine to the other for remote processing, but it uses the
digital audio ports of the soundcards of the machines to pass
the audio data around (together with other data). Therefore, it
only works with audio cards with digital I/O and word clock.
See ya,
Nelson
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
On Aug 18, 2004, at 12:38 PM,
linux-audio-dev-request(a)music.columbia.edu wrote:
>> -- There are tools for synchronization (RTCP mappings of NTP
>> and RTP timestamps), tools for security (SRTP), tools for
>> all sorts of things someone might need to do someday.
>
> this does seem very useful. there's no way to transport time between 2
> jackd instances right now, and it would be wise to reuse existing
> technology whenever this is added. otoh, it has to be bit more
> extensive since we need music and/or smpte time rather than just
> wallclock time.
One way to do this is to have a multi-stream session, with one of
the sessions being RTP MIDI, that uses System Exclusive commands
to do MTC, or MIDI sequencer, or MMC to do your timing. So,
this would recreate the current hardwired world, but using RTP MIDI
to do pseudo-wire emulation of the MIDI cable carrying MTC ... the
RTP RTCP stream would have NTP, as would all the audio RTP streams,
and the receiver uses these common NTP timestamps to derive
cross-sync between the MTC sync information in RTP MIDI and the RTP
timestamps on the audio stream.
Of course, this only works as well as your NTP sync ... in an ideal
world,
a single server generates these streams off of a single NTP clock, or
at least you have a very good NTP daemon keeping things in sync.
Roger Dannenberg gave a good talk on these issues at the OSC-fest
here at Berkeley last month ...
---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---
