From alsa-devel-owner@alsa.jcu.cz  Mon Mar  1 22:06:19 1999
Received: from druid.inprise.com (druid.inprise.com [143.186.11.70])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id WAA20825
	for <alsa-devel@alsa.jcu.cz>; Mon, 1 Mar 1999 22:06:11 +0100
Received: from godzilla.inprise.com (mail.inprise.com [10.186.1.4])
	by druid.inprise.com (8.8.8+Sun/8.8.7) with ESMTP id NAA06967
	for <alsa-devel@alsa.jcu.cz>; Mon, 1 Mar 1999 13:02:57 -0800 (PST)
Received: from kduffey ([10.143.1.75]) by godzilla.inprise.com
          (Netscape Messaging Server 3.6)  with SMTP id AAA2D6B
          for <alsa-devel@alsa.jcu.cz>; Mon, 1 Mar 1999 13:02:56 -0800
Message-Id: <3.0.32.19990301130329.00969bb0@mail.inprise.com>
Date: Mon, 01 Mar 1999 13:03:29 -0800
To: alsa-devel@alsa.jcu.cz
From: "Kevin Duffey" <kduffey@inprise.com>
Subject: Re: (SB Live) Free drivers or not? (fwd)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Hi.

snip.

but it's a
>hell of a lot less of a headache than NT 3.51 vs. 4.0, from what I've
>heard.  Linux (as a sort of UNIX OS) really has the stability that most
>other platforms want.

Hmm..NT 3.51 to 4.0 I think was mostly the GUI interface. It was like going
from win3.1 to 95. As for the internals, I have no idea..I never used 3.51. 


snip.

>greatest, but if you are worried that much about compatability, you
>probably aren't worried about the latest and greatest.  Btw, are you
>familiar with the library versioning scheme and how that relates to ld?

Ahh..interesting. Ok..so from what you said, if I write a program using
glibc (I guess thats libc6 right?), then as newer glibc modules come out,
my program will still work under them? What about libc5 apps..do they work
under glibc? Or did they have to be recompiled? 

Familiar..nope. Not at all. I am "still" trying to set up Linux the way I
want it, which is the basic kernel stuff, XFree86, Enlightenment and GNome.
I haven't a clue yet as to how to do all this. My idea of learning Linux..I
decided I was going to install the minimum on my Redhat so as to get it up
and running. Then, I would download the latest RELEASE version of each item
I needed. I found out there are a LOT of dependencies using RPM and I am a
little pissed on trying to use it. So..I decided I would download the
.tar.gz source files of each product, figure out how to compile them and
what dirs they go in, and work from there. Any pointers on this would be
appreciated. :) If you want to take the topic of library versioning offline
and send me a private email, I am more than grateful. kduffey@inprise.com
if you do that.

>	OSS is a standard right now.  If you write for OSS, you are
>basically guaranteed to work on almost all platforms, unless you do it
>wrong.  Of course, if you do it wrong, you'll always be screwed, so that's
>not saying much.

True. OSS means giving out the source right? GPL is part of OSS, or vice
versa? As long as source is available, anyone can compile it for their
version and tweak it if necessary. As Eric said, its more common that when
someone tweaks it in some way, they let me know about the change..etc
right? So I could somehow incorporate that into a new release or fix. Is
that how it usually works?

>	It's very possible.  I've run X applications that were 6 years old
>and worked fine in terms of the interface (they had some internal bugs).
>The X protocol is very stable.  The one things is this: follow the APIs,
>not the behaviors.  Open source people rarely make anything backwords bug
>compatible.  If something was a bug, it will generally be fixed.  If you
>didn't make a flexible work-around, but instead depended on the bug, you
>will be screwed.  If you were writing an open source app, you'd get the
>fix inside of a week.  If you are writing a closed source app, you will
>get the people who paid you money complaining.  Of course, this is, to my
>knowledge, rarely an issue.  X is very stable API-wise.  Most of Linux is
>very stable API-wise, actually.  The only things that aren't are internals
>(and you shouldn't rely on another programs internals) or development
>projects.  Don't expect gnome to stay the same for a while, it needs to
>mature first.  Expect X to stay the same for a long time, it is mature.

Ahh. Thanks for that insight! Good to know that.

>	What's the point of this "compatability"?  It basically boils down
>to, the APIs are mostly intact.  The behavior may change.  Odds are that
>your program will work unless you did anything remotely out of the
>ordinary in which case it will probably either crash more or not work at
>all.  Win 3.1->95 had plenty of programs that wouldn't work.  NT 3.51->4.0
>Had plenty of programs that didn't work on one or the other.  Hell, there
>are plenty of programs that are service pack specific under both NTs.
>Sure, most stuff will work.  Most.  The same goes for Linux stuff, except
>that mature APIs and implementations very rarely change much, and they are
>never broken to screw over competitors or drive up sales of more recent
>versions.

I AM A BELIEVER!!! :) Ok..thats what I wanted to know about. I guess the
next thing to figure out is what is mature or not. I understand the OS and
X are matrue. But that article Eric (or was it you) sent out about what
Linus said with binaries only. Basically, what you are pointing out is that
as long as I offer or give source code, other people, like yourself, could
compile the source and tweak it if need be, to make it work. For the most
part, if my app follows, say GNome (or just GTK+) then it should work fine
for years to come even if GTK+ changes? But..thats assuming GTK+ is a
mature product..which from the looks of it..it is VERY mature compared to
anything MS has! :)

>
>> But, I am saying, while I dont want to see Linux ever so close
>> ended as Windows is, it would be very nice to see some sort of
>> standardization for specific areas of computing, such as multimedia, 
>	This one is just vacuous.  Sound: OSS, Video: X, CDROM: it's a
>plain old drive.  What else falls under the umbrella of multimedia?

Hmm. Ok. I'll buy that. But I think I would rather see Sound: ALSA :)


>	This is two issues:
>*backword compatability.  This is generally better on Linux than on
>windows, Linux people don't break their APIs to sell more copies of the
>new ones.  I guess that you aren't familiar with the way that dynamic
>library versioning goes and what that means.  If so, please tell me and I
>will explain it.

PPLLLLLEEEAAAASSSSEEEE Explain it to me. I am eager to learn, Master. :) I
do not understand how it works. I am trying to implement versioning control
in my plug-in architecture for my app right nwo..but I dont much have a
clue as to how to do it, other than doing basic version strings with
timestamps on the files.  So an explanation would be good. Perhaps, as I
mentioned above a private email though..it may not suit this email group to
hear how stupid I am. :)


>*WINE progress.  The WINE (Windows Emulator) project is making great
>strides.  You can run, fairly well, some versions of word now.  I don't
>know what the future of wine holds, but it is probably pretty good.  I
>know of a bunch of games that apparently run very well under wine, and
>I've heard about a bunch of productivity programs that work well under
>WINE.

I hear of Wine. Looks promising. Let me ask this. If I were to run an
"exact" program made specifically for Linux and X, compared to one targeted
for Win95/NT. Lets assume it has the exact same functionality, but they are
two different platforms. Would the X version run faster, better, and less
prone to crashes? I have heard a number of people say X and Linux are MUCH
faster (what percentage if known??) than Windows. 

A buddy of mine has Linux and X running on a 486 Dx4-100 laptop with 28MB
ram and says while its a little slow loading X, it runs much faster than
Win 3.1 did..much less win95. And..it requires less space. IS this all
pretty much true?

>	Actually, Linus has publically stated that he hopes that Linux
>grows to around 30% of the market, but no more.  He wants interoprative
>diversity, not really world domination.  As long as everyone works with
>each other, diversity is definitely the way to go.
>	-Chris

Ah hell..lets take over the world!! :) BeOS looked like a pretty kewl up
and coming OS..but I don't think it compares to Linux. I particularly liked
the multi-media and graphics capabilities. It has very precise timing for
music apps, which I am trying to find out (do you know?) if Linux has
simliar capabilities that haven't much been exploited yet. 


Maybe I can explain a slight bit of what my app will do. Many of you
"hopefully" have heard of Cakewalk, Cubase VST, etc. Well, there are two
things I HATE about these products. First..they are WAY expensive. Even the
LITE version of Cakewalk is $100, and its not that good. Cubase is way out
of reach for the average music person that wants to explore MIDI and audio
stuff on the computer. Kids cant afford $1000 for a music program, much
less $300 plug-ins.

So my goal was to write a music application that would be cheap yet very
powerful. Cheap in that the "core" I would give away. The cores sole
purpose is a simple executable and a plug-in engine. The engine loads all
plug-ins and manages them. Basically, once a DLL (in windows) or a .so in
Linux is loaded, it doesn't do much else but sit idle. But..it maintains a
list of plug-ins, their library handles to keep them in memory (and later
free them), and keeps all version info, names, types, etc. 

That said and done, the next step are the plug-ins. I have created what I
believe to be a far more open plug-in architecture than any current
application uses. Basically, a plug-in is a full-blown app if need be, but
in library form instead of executable. However, the idea is to keep to the
original app plan..which is music. Its possible to do anything in plug-ins,
but hopefully developers would keep the original target in mind..music and
computers. 

The basic core allows a few types of plug-ins, but more can be created by
3rd party developers. There would be file types, which allow load/save
routines for any type of song and sound/sample format to be used. New types
can be added easily. There are visual plug-ins, which would be those
activated by a button on a toolbar and/or a menu item from a drop down menu
(or pop-up menu) and they would in turn pop up some sort of dialog or
editing window the user would use. Each of these visual plug-ins can be
done any way needed including drawing their own types of windows, menu
items, buttons, etc. Under Linux, using GTK would make this a very
themeable application. :) Under Windows, you have to "draw" your own
windows, graphics, etc to change the look of it. I dont know..but maybe
someone can answer this..using GTK, can you make a single window look
different and not change with themes if you want? In other words, could I
write a plug-in (for my app) and have it include its OWN theme just for
that specific window, and NOT change (or it could change..based on a
"preference" setting) when a user changes the desktop theme? Is that
possible? 

There are other types as well..but I haven't documented them much yet.
Now..the way it works is, a plug-in can be a "client" or a "server" so to
speak. A client plug-in can be one that does nothing more than its own
tasks, and possibly uses other plug-ins if need be. These others would be
"servers" or "hosts". They could do two things. They can be a client/server
in one, or a server. Basically, a server/host plug-in allows other plug-ins
to USE its routines by requesting the function addresses to them. Then,
they can directly call those other plug-ins routines at any time necessary.
I have implemented a "direct" messaging system. Every plug-in has a built
in "handler" procedure that receives a MSG type and can "crack" that
message to determine what to do next. But..unlike Windows, its not buffered
and handled when it can. Its like calling a function directly. Control
passes to the message handler of a plug-in, then to the function that
handles that..then back to the calling plug-in. 

Ok..after all thats said and done, what I would do is provide basic
sequencer plug-ins initially. The routines to load and save MIDI, as well
as my own song format to handle more advanced capabilities. I would provide
routines that allow plug-ins to directly access the song structure, track
structure, and individual events. All events would "stream" in from MIDI IN
and back out to MIDI out (somehow..not sure yet how I will implement this),
so that MIDI FX plug-ins can "filter" the streaming events on a per track
basis (or tie several tracks into one stream). This would allow MIDI
effects like making a chord from a single note event, removing specific
notes or events based on some criteria, etc. I call these MIDI FX plug-ins.
This would be simlar for Audio, but audio FX plug-ins would work on the
outgoing audio only. It would be possible to make a Sound Editing plug-in
to add to this application (so as to have a complete all-in-one application
for sound editing, sampling, effects, midi in/out, etc), which in turn
could have plug-ins that "change" sound as its recorded, etc. 

The list goes on and on. I dont mean to publish my whole idea here. :) I
wont go into depth. I would really love some 3rd party plug-in developers
to eventually help me out once I get the basics working. I do have to make
a simpel Piano Roll editor, and a track view. I plan to have a project
manager so as to allow multiple songs loaded at once. I have tons of ideas
for plug-ins..but since each plug-in can take from a couple of hours (an
EVENTS editor) to many months (Score editor) to complete, I dont know if in
the next year or so I would even have a decently running sequencer. 

ANYWAYS. That is my goal, and why I joined ALSA, so as to be able to use
all the soundcards under Linux for my application when I port it. I am
currently using Delphi (Pascal) to do the core project..but I am going to
switch to C++ to port it. The thing is, on the Windows platform, I
personally cant find a tool as fast and effecient as Delphi to write apps
and plug-ins with. Not even BCB (based on Delphi) is near as good. The code
produced by Delphi is amazingly fast and small. So I prefer to use that.
But, I will also make a C port of the core and stuff, to release under GPL
(I believe I will do this..when I ever get Linux set up the way I want. :).

I welcome any ideas or feedback on the music program I one day plan to have
working.


Oh yeah..I forgot to mention the other reason why I started my music
project. The MAIN reason is..I got so sick and tired of waiting for
Cakewalk or Cubase to release a new version with not only bug fixes but
KEWL kick ass features that I wanted. AND..it never would happen. Cubase
has plug-ins, as does Cakewalk, but they are of very limited capabilites.
Mostly audio FX plug-ins with some fancy interfaces to them. I cant add a
new song type to Cakewalk (I think you can do this with Cubase), nor can I
add new filters, FX, features, etc. I want my app to allow 3rd party
developers to develop plug-ins that make my app much more powerful, adn
thus one day the defacto standard for music!! :) I also would like to see
studios use it, and as such plug-ins could be written to do special
functions. Using Linux as the OS, if its capable of very precise timing
(lets say under X with no jobs running..just the OS and X and my app..so as
to free up the CPU for the music program), I am hoping that with its
ability to use multi-processors, it could one day be possible to write
multi-threaded plug-ins that use 2, 4 or more cpus to really speed up
performance. Thus, this could allow a studio to use a 4-cpu PIII 800Mhz cpu
(by the time this project is done..thats what should be available) and
really use some real-time hardcore DSP effects on a 64-track song that is
being written to digital 32-bit audio format for later reproduction to CD
by none other than a built-in plug-in that writes to CD-Rs!! :) Thats my
dream!

There you have it. Windows doesn't cut it. I plan to release on Windows,
but I want an OS that is more stable and more timing capable than Windows.

So..Will Linux do the job?

Thanks fellas..for putting up with my newbieisms and stupidity along the
way. You guys seem to be a great bunch of fellas. Chris, Eric and the lot
of you.

Hope to hear some feedback on my project, but also learn with you guys, and
hopefully provide some insight (one day) to ALSA.




Kevin Duffey
kduffey@inprise.com

