Re: [linux-audio-dev] Poll about linux music audio app usability
"STEFFL, ERIK *Internet* (SBCSI)" wrote: > > > -Original Message- > > From: Joern Nettingsmeier [mailto:[EMAIL PROTECTED]] > > "STEFFL, ERIK *Internet* (SBCSI)" wrote: > > > > > > that said I have to admit we're not there yet, I am just > > trying to get > > > soundblaster live! to record something (audio) and it just > > doesn't:-) > > > > assuming you use alsa, try scrolling a little to the right in > > alsamixer: > > there is another control named "capture" that needs a capture flag as > > well (not just the line or mic you're recording from). > > thanks, I'll try that. > > Is there any place where the mixer controls for SB Live! are described? > It's quite hard to figure out what they are doing, some are obvious but lot > of them are not - e.g. this Capture control, then there are capture controls > for some of the input (e.g. there's Line LiveDrive & Line LiveDrive Capture, > but there's only Line LiveDrive 1 - no capture control for this one), the > headphone controls (Headphone LFE 1, Headphone 1, Headphone Center 1) , LFE, > etc... I've checked the live! web page, creative webpage but found no > details (yet) - any pointers? alsa-cvs/alsa-kernel/Documentation.SB-Live-mixer.txt this might help some. although i must confess that after 2 yrs of use, many of the features are still a mystery to me :)
Re: [linux-audio-dev] Poll about linux music audio app usability
On Friday 21 June 2002 16.27, Bill Bland wrote: > On Fri, Jun 21, 2002 at 04:05:47PM +0200, Vincent Touquet wrote: > > I was thinking about some callback model: > > you provide the callback to redraw your > > knob after you changed the parameters. > > Sounds quite like the way FLTK works to me (see www.fltk.org). Yes, it's an old idea, used in various places. The problem I'm seeing with it is that there's no way such a design could make anything *significantly* easier. You still have to hack code as soon as you need a new or modified widget. *That's* what I'm trying to avoid - you shouldn't need to code new widgets all the time. //David .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `---> http://www.linuxdj.com/maia/ -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -'
Re: [linux-audio-dev] Poll about linux music audio app usability
On Friday 21 June 2002 16.05, Vincent Touquet wrote:
[...]
> >It's like replacing the graphics of a game; drawing a bunch of
> > images for each object, whereas normal ("GTK+ style" themes
> > consist of generic textures and images used by all widgets.
>
> Thats exactly what I'm aiming at :)
> I didn't mean themeability in the themes.org sense of the word.
Ok; then we're thinking along the same lines, basically. :-)
> Just an abstraction of functionality:
> - sliderbars
> - rotational knobs from 1-10
> - rotational knobs without beginning and end
> ...
Yes... Although I'm trying to figure out a way to design a slightly
lower level abstraction, where it's more like assembling a very small
set of logic building blocks into widgets.
For example, a slider bar would be a draggable object tied to a
"path" object, that restricts it's movement. A rotational knob would
be an object pinned to the background with a single point "patch"
that restricts movement to nothing, but allows rotation.
> Just how far you can go, I don't know.
Same here - but I think you can do a great deal with a sensible
design. If you can create a whole game (well, not another Q3A, but
anyway) without hacking a single line of code, one would assume that
visual GUI building could be slightly more powerful than the Delphi
or Visual Basic variants. (BTW, Delphi isn't that far off - if you're
into databases... The actual GUI toolkit is still rather "stupid" and
restrictive, though.)
> Someone mentioned that the xmms coding style was
> to be avoided.
Actually, I have to agree, although it's not as simple as "XMMS is
bad". There are two parts; the GUI and the window management. XMMS
messes with *both*, for no good reason, and it doesn't even result in
a good user interface. The bypassing of the window manager is just
stupid and pointless in this case, and has XMMS integrate poorly no
matter what desktop you're using. It doesn't provide anything of use,
but it *does* disable most of the nifty features of your favourite WM.
There are applications that should preferably use their own internal
WM - in some cases, maybe even a whole desktop enviroment, but they
are few, and your average media player (which is just supposed to
play music while you're hacking :-) is *not* one of them.
> I was thinking about some callback model:
> you provide the callback to redraw your
> knob after you changed the parameters.
That's one way, and I definitely think there should be hooks like
that.
However, I think about 95% of the work can be done by the toolkit,
without any application code at all. This goes for the interaction
between "logic objects" as well, but I actually think the rendering
is the *easy* part in this regard.
If you have a rendering library with the usual shapes, images,
textures etc, the actual rendering is just a matter of passing it a
list of operations with arguments. (Heard of OpenGL display lists...?)
Throw in some very basic flow control (iterators, simple conditionals
etc), and you have a simple "scripting language" for which code can
easilly be generated by something like a structured drawing program.
You just draw your GUI as a structured image, and then you select
visual objects and connect them to logic objects in various ways to
make the GUI dynamic and interactive.
> This way you could plug the functionality
> of the knobs etc. in your program,
In my design, you'd "ask" certain logic objects about some of their
properties. (In the slider example; "Knob, where on the path object
are you now?" or "Knob, tell me where on the path object you are
whenever you're dragged.")
> just
> by providing the graphics and using
> the toolkit you want...
Yes. Provide some data generated by that "dynamic structured
graphics" (DSG :-) drawing program I'm talking about, and there's not
much code left for you to hack WRT the GUI. And anyone can grab your
DSG data and start fiddling around with the objects in the editor,
pretty much like you can fiddle around with the data of a game.
Oh, and it should be possible to implement this on top of any toolkit
that supports basic "drawing area" widgets. (I plan to do it for SDL,
OpenGL, GTK+ - and possibly Borland's VCL, if I'm bored some day.)
> Obviously I must have missed all the difficult parts ;)
Well, any design takes at least three times as long to implement as
you could possbly imagine - if it works out at all, that is.
So, check back in a few years, and I might have something to demo! ;-)
//David
.- M A I A -.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`---> http://www.linuxdj.com/maia/ -'
.- David Olofson ---.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-> http://olofson.net -'
RE: [linux-audio-dev] Poll about linux music audio app usability
> -Original Message- > From: Joern Nettingsmeier [mailto:[EMAIL PROTECTED]] > "STEFFL, ERIK *Internet* (SBCSI)" wrote: > > > > that said I have to admit we're not there yet, I am just > trying to get > > soundblaster live! to record something (audio) and it just > doesn't:-) > > assuming you use alsa, try scrolling a little to the right in > alsamixer: > there is another control named "capture" that needs a capture flag as > well (not just the line or mic you're recording from). thanks, I'll try that. Is there any place where the mixer controls for SB Live! are described? It's quite hard to figure out what they are doing, some are obvious but lot of them are not - e.g. this Capture control, then there are capture controls for some of the input (e.g. there's Line LiveDrive & Line LiveDrive Capture, but there's only Line LiveDrive 1 - no capture control for this one), the headphone controls (Headphone LFE 1, Headphone 1, Headphone Center 1) , LFE, etc... I've checked the live! web page, creative webpage but found no details (yet) - any pointers? erik
Re: [linux-audio-dev] Poll about linux music audio app usability
"STEFFL, ERIK *Internet* (SBCSI)" wrote: > > that said I have to admit we're not there yet, I am just trying to get > soundblaster live! to record something (audio) and it just doesn't:-) assuming you use alsa, try scrolling a little to the right in alsamixer: there is another control named "capture" that needs a capture flag as well (not just the line or mic you're recording from).
RE: [linux-audio-dev] digigram's "ethersound"
> From: "Men Muheim" <[EMAIL PROTECTED]> > > > I wrote > > http://www.cs.columbia.edu/~hgs/rtp/history.html > > this link seems a bit out of date! Six years is eternity in this > business... > > -- men Yes, but the expired patent mentioned is still expired: April 1977 J. Flanagan (of BTL) applied for a patent on Packet Transmission of Speech. July 1978 US patent 4,100,377 granted to J. Flanagan. And this classic patent is still unexpired: May 1988 US patent 4,748,620, Time stamp and packet virtual sequence numbering for reconstructing information signals from packets granted to Harry W. Adelmann and James D. Tomcik I haven't read either of these, but I'd guess these are the baseline intellectual property for packetizing audio, and newer patents build on them -- if you're worried about IP on this issue, start worrying with these, not Gibson or Digigram ... - John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -
Re: [linux-audio-dev] Poll about linux music audio app usability
On Fri, Jun 21, 2002 at 12:36:49PM -0700, STEFFL, ERIK *Internet* (SBCSI) wrote: > freeamp allows you to specify bitmaps of arbitrary size/shape for gui >elements and place them where you want (there's an xml file that specifies >the GUI), you can omit the GUI elements you don't need/want in particular >skin etc. - that makes it possible to really make a difference - e.g. you >can create a skin that would make it easy to dock/swallow it in some launch >pad/task bar/whatever (e.g. small play/stop and volume controls) or you can >create a big full screen art work that also serves as mp3 player etc... That's the functionality I would be aiming at. Maybe I should have a look at their code :) regards vincent
RE: [linux-audio-dev] Poll about linux music audio app usability
> -Original Message- > From: David Olofson [mailto:[EMAIL PROTECTED]] ... > However, there's one thing that's seriously worrying me: Software > piracy. I saw a poll somewhere, that indicated that a vast *majority* > of computer users considered piracy more or less "OK". It's like they > simply don't consider it a crime at all. > > What this means to us is that we're effectively competing with high > end professional software *ON EQUAL TERMS*! Actually, worse than > equal terms: They make money, while we do not. > > * Most of these users couldn't care less about > Open Source (if they even know what it's about), > so that's not an advantage for us. > > * Most of them don't give a damn about paying for > the software they use anyway, so we have no > advantage there either. > > As to true professionals, I believe a large portion of them don't > have a real problem with paying for good software - and either way, > they'll just pay what it costs to get a sufficient solution. Doesn't > matter if it's free, Free/Open Source or whatever, if it doesn't > quite cut it. obviously, it has to be better. I think you can make the same argument in all other areas where opensource software is used and IMO it will be successfull in multimedia apps for the same reason it is successfull in other areas - the user is in control. that's what everybody likes - from joe to disney (they are switching to linux, you would think the big corp like them can afford to pay for window, yet price is one of the reason they are changing, not the only one of course). the fact that it's free makes it more convenient then non-free to work with it (support!) and to get upgrades - note that apart from paying for upgrades it's usually not that easy to upgrade non-free apps (because of different mindset), even less easy when you want to pirate it (you have to a friend who has the software, get it from warez sites etc., not hard but not as easy as apt-get dist-upgrade). that said I have to admit we're not there yet, I am just trying to get soundblaster live! to record something (audio) and it just doesn't:-) but the inmportant part is that it works a lot better then it used to recently - most of the reports that I read are pleasantly outdated - most of the stuff they list as not working already works. erik
RE: [linux-audio-dev] Poll about linux music audio app usability
> -Original Message- > From: David Olofson [mailto:[EMAIL PROTECTED]] ... > That said, the XMMS/WinAmp model *is* in fact of the first kind I > mention above; GUIs with custom graphics. A skin for such an > application is basically just a set of images that replace the > original custom graphics. ... freeamp is the application that has IMO good implementation of such a model, xmms/winamp are IMO sucky (in this area) - the biggest usage problem being that it's always the same size (too small for my taste) [and, of course, all the skins look basically same:-)] what I don't like about it is that all it provides is superficial change of look - all the items (buttons etc.) are in the same places (and of course, they are all the same buttons with same functionality) - very shallow and useless - basically a hint of what can be done. freeamp allows you to specify bitmaps of arbitrary size/shape for gui elements and place them where you want (there's an xml file that specifies the GUI), you can omit the GUI elements you don't need/want in particular skin etc. - that makes it possible to really make a difference - e.g. you can create a skin that would make it easy to dock/swallow it in some launch pad/task bar/whatever (e.g. small play/stop and volume controls) or you can create a big full screen art work that also serves as mp3 player etc... erik
Re: [linux-audio-dev] Poll about linux music audio app usability
On Fri, 2002-06-21 at 18:40, Michael Toomim wrote: > Why don't you just use Evas? It was designed for just what you're > talking about. > > http://www.enlightenment.org/pages/evas.html Ive been thinking of using that myself. hardware accelerated gfx. mmm :) nick _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [linux-audio-dev] Poll about linux music audio app usability
Cool, they must be lucky I didn't think of patenting it when I just thought of it now ;) vincent On Fri, Jun 21, 2002 at 11:05:10AM -0400, Paul Davis wrote: >Sounds quite a lot like the way almost every GUI toolkit I've looked >at works (see XForms, GTK+, Qt, Gtkmm for examples) :) > >--p
Re: [linux-audio-dev] Poll about linux music audio app usability
David Olofson wrote: > * Fast, high quality rendering with OpenGL style > blending effects and the like. (In fact, I'll > probably use OpenGL for the first implementation. > I've been messing a bit with 2D-on-OpenGL anyway, > to implement the SDL API on top of OpenGL.) Why don't you just use Evas? It was designed for just what you're talking about. http://www.enlightenment.org/pages/evas.html
[linux-audio-dev] [Fwd: OS file format/authoring of Generative Media]
Greetings: Ja, ja, I'm the forwarding spam-king... But this message refers to a nice chunk of cash for the deserving developer... Best regards, == Dave Phillips The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://linux-sound.org --- Begin Message --- Dear Dave, I am investigating the field of generative media (generative art, music and design) and would ask you for help/advice in these terms. I am not sure how much informed you are in this purticular direction of media arts, but a number of artists, researchers and software developers have tried to capture the power of undeterministic reproduction or more siply said -- avoiding the fixed score in reproduction by introducing live performance qualities. Brian Eno wrote interesting texts on this subject and helped develope Koan music application (www.sseyo.com), which led to his Generative Music album. A lot of people in electronic music/sound art scene also tried to do similar things using fuzzy logic, AI, random input systems (mostly Max/MSP some PD users also). Previosly mentioned SSEYO Inc. has developted very sofisticated authoring software called Koan Pro and more simple KoanMix... Thay support Winnows and Macintosh but not Linux platform, however thay have opened their API and file format thay use is txt based so someone can (at least in theory) develop Linux version. Thay basicly mix the MOD way with .mp3 samples and realtime effects that are available in their engine. Knowing your activity (following the articles you publish) with LinuxSound (which is sometimes usable for sound in general) I would appreciate your recomendations in terms of what you think might be a good starting point for creating open generative music/sound file format. Which tools would be good to be used, in order to get relativly big userbase and number of supported platforms ? jMAX ? PD ? C-Sound ? Which format structure should be taken? maybe xml based with embeded .ogg samples ? existing ones from C-Sound? Why am I asking you this now? Well I am working on a project of getting a few generative artists/researchers/developers together in early October in Croatia for GenArtLAb event, and would like to announce this event as a place where we could actually try to start establishing some kind of a standard ? We also have some money (around 1000$) to award the first developer who submits substential amount of GNU/GPL code with this idea in mind. If you think this is something worth investingating please consider joining our effort and helping with the project (with txt to be included in catalogue publication, code or references). Best wishes, Zeljko Blace Multimedia Institute, Zagreb CROATIA p.s. as I am avid user of (Open)BeOS I am trying to see which of the Open Source Linux applications can/can't be ported to BeOS, so would you help me buy pointing out how to see which applications rely on which libraries and widgets (since GTK is almost ported and Tk is no where in sight)? Is there a way to get listing on Sound/music apps that use Tk so I can actually see if it is worth bothering BeOS developers to port Tk (I miss PD and mash tools the most): --- End Message ---
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wed, Jun 19, 2002 at 11:20:20PM +0200, David Olofson wrote: (cut) >of programming. It looks like it would be a fast and easy hack, as >everything's so visually "obvious" and intuitive, but that's just an >illusion... I think I agree, though my GUI programming experience is quite nonexistant :) (or: :() >> I think an effort should be undertaken to >> get a group of people to write these damn things :) >Yes, but how about motivation, and getting the right people to do >their best? I'm motivated :) Now only to find time and someone who can tell the bad code from the good. >> I fear model-view-controller separation >> doesn't apply here, as we are entirely >> in the view realm. >I don't agree there. The major difference is probably that there's >much more "logic" inside the GUI part - not that there all of a >sudden is a good reason to mix things that don't belong together. :-) Actually, I wrote this to stir some reaction. I don't agree with it myself. I believe there is stuff that can be abstracted about this GUI thing. >In fact, the separation between engine and UI is an absolute >*requirement* for real time audio/MIDI applications, as you simply >cannot make them work reliably if there are too many places where the >UI may interfere with the timing of the engine. True, writing anything inside the GUI event loop is wrong (at least when you want low latency). (cut) >The design I have in mind could be implemented inside any toolkit >that provides access to the underlying "drawing toolkit" - or >directly on top of the rendering target or API (SDL, X, fbdev, >svgalib, GDI, DirectDraw, Direct3D/Graphics, OpenGL...), for that >matter. Lets put this on the table then :) Could you draw a class diagram or something to show us your model ? >The only truly required feature is a way of rendering rectangular >images into windows. All higher level stuff is just to allow certain >targets to use hardware acceleration for specific features - ie >performance hacks. (That is, stuff that optimization freaks can play >around with after the toolkit is implemented and working. :-) Well, we could just skip this at first as premature optimization is the root of all evil :) >Either way, the major issue here is not *how* we should go about >getting proper GUIs for more and larger Linux music application, but >how we should get anyone to do any serious GUI hacking *at all*. >There are a few exceptions, but the fact remains: The LAD community >consists mostly of *audio* hackers. (Makes sense, sorta'... ;-) :) you have a point. We have here a large based of knowledgeable coders though and a potential userbase. So involving LAD in this seems sensible enough. And hey, I'm interested. I hang around here, for the same reason as I hang around on other lists, to learn. I like to read the code. And I like to make code, even though I need some project that will tickle my mind. Such as this :) regards Vincent
[linux-audio-dev] Re: Streaming solution for a cybercafe
Greetings: Here's the text from the forwarded message I referred to earlier. You will all be glad to know that the list moderator is hard at work doing his job (instead of practicing! ;), so the original forward was trapped due to an attached JPEG (a picture of the cafe's setup). Abdul-kadir's questions are quite beyond my expertise in these matters. Perhaps some of the streaming media gurus here can lend him some assistance ? Best regards, == Dave Phillips The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://linux-sound.org > abdul-kadir wrote: > > Hello Dave, > > My name is Abdul-Kadir, and currently designing a business solution > for a close client in Nigeria that want to roll-out a large cybercafe > in Lagos Nigeria. > > I would like to ask for your advise in certain areas of Linux OS, > however, let me intimate you with what we are planning. > > The main services that will be provided include the following. > 1. Standard Internet access for sending and receiving mail. > 2. Video mails > 3. desktop video conferencing > 4. Live streaming of events that take place at a multi-purpose hall > that is within the same building. > > The total number of PC's is 170PC, with 80 having webcams.(Attached is > a photo that is similar to what we are planning) > We want Linux on all the PCs. > Questions > 1. How good and reliable is the Gnomemeeting and OpenMcu server under > Linux. If I install a 4MB broadband link to my home in the UK, will > you advise me to install Linux webserver and the OpenMcu on it? > 2. For the live streaming, I have been considering Darwin streaming > server of Apple, Darwin has been developed for other OS on open > source. It will server the main objective of 4,000 concurrent users > watching my stream. The only drawback is that all my viewers via my > website will need quick time. Is there any other plug-in that will > enable my viewer seen the videos via their browser? > 3. Within my cafe, I want some users who want to watch films and > movies on the LAN, to do so. Any Linux application that can support > Video on demand within a LAN with a DVD quality output or any good > format? I know quick time does. > 4. Any billing system that can help cut off users at the cafe when > their time expires? Or can that be done within Linux > 5. I know Linux can be configured as a PBX for phone calls. Any tips > 6. I want the customer's login screen to have my logo and advertising > windows before and after logging into the network. > > I hope I am not asking too much. I am considering SUSe 8.0, which I > have confirmed that can be configure as server and desktop on 2 > different machines. Any advise on the services we are considering and > the OS we have considered. Red hat maybe or Mandrake? > > I look forward to hearing from you ASAP > > cheers. > > Abdul-Kadir > >Name: topcom-cafe9.JPG >topcom-cafe9.JPGType: JPEG Image (image/jpeg) >Encoding: base64
[linux-audio-dev] whoops...
Greetings: My apologies for sending a JPEG attachment with that last forwarded message. I forgot that it was there... Also, I hope I'm not being presumptuous by forwarding such messages to LAD or LAU. I do try to answer such messages myself, but I'll defer to the real experts when I know I'm in deeper waters than I can handle. Best regards, == Dave Phillips The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://linux-sound.org
Re: [linux-audio-dev] Poll about linux music audio app usability
>It's like replacing the graphics of a game; drawing a bunch of images
>for each object, whereas normal ("GTK+ style" themes consist of
>generic textures and images used by all widgets.
well, sort of.
a full GTK+ theme actually consists of:
a) methods to draw a set of low level primitives:
line
box
polygon
arrow
circle
b) methods to draw some slightly higher level primitives
sliders
text on a background
c) colors and background images for specific widgets
Its (c) that corresponds to a "style", but full GTK+ themes define
more than this. You need a shared object containing the drawing
methods to use a theme, however.
--p
Re: [linux-audio-dev] Poll about linux music audio app usability
>> as a history, GtkCanvas is essentially the same as the Gtk+-1.2 >> GnomeCanvas, but available in a separate package and with functions >> renamed accordingly. GnomeCanvas used to be available only as a >> part of the Gnome libraries. >> >> the Gtk+-2.0 version of GnomeCanvas is available as a separate >> package, which does not depend on anything but Gtk+-2.0 and libart >> (which is one of the canvas backends in 2.0 as well). So, I know >> why paul pushes GtkCanvas, but people looking for a maintained >> package and don't mind Gtk+-2.0 (which is very stable) should take >> a look at the GnomeCanvas instead. > >Aaargh! This is exactly what I don't like about these sort of >solutions. > >Why is the "Canvas API" part of either a toolkit or a desktop >environment? Why do they have different (even if only slightly so) >APIs? 1) GtkCanvas is a "backport" of the GnomeCanvas so that it was free of the "desktop-isms" of GnomeCanvas. However, since the Gnome crew realized the error of their ways, they removed all such references to the rest of Gnome themselves. The result is still considered to be part of Gnome rather than GTK, mostly for political reasons. But from a technical point of view, it has the exact same dependencies as GTK+ itself, so its usable as a standalone library without any part of Gnome not already used by GTK+ (ATK, Pango, glib). 2) its part of a GUI toolkit because thats what it is. Unless you create an entire toolkit around the idea of a Canvas-like object, the Canvas-like object is just another widget in the toolkit. it was never really part of a desktop environment. it started life in Gnome because of politics rather than technicalities. --p
Re: [linux-audio-dev] Poll about linux music audio app usability
>On Fri, Jun 21, 2002 at 04:05:47PM +0200, Vincent Touquet wrote: > >> I was thinking about some callback model: >> you provide the callback to redraw your >> knob after you changed the parameters. > >Sounds quite like the way FLTK works to me (see www.fltk.org). Sounds quite a lot like the way almost every GUI toolkit I've looked at works (see XForms, GTK+, Qt, Gtkmm for examples) :) --p
Re: [linux-audio-dev] Poll about linux music audio app usability
> However, there's one thing that's seriously worrying me: Software > piracy. I saw a poll somewhere, that indicated that a vast *majority* > of computer users considered piracy more or less "OK". It's like they > simply don't consider it a crime at all. Can you honestly say that pirating software, music or movies is a crime? Are the victims really victims? Of course, if 100% of the people would do it, I don't know where we would be today. Maybe in a free world ? (just kidding ;-)
Re: [linux-audio-dev] Poll about linux music audio app usability
On Thu, 2002-06-20 at 00:26, David Olofson wrote: > On Thursday 13 June 2002 00.07, nick wrote: > [...] > > I suspect, however, as you have alluded to - that there arent many > > graphic artists hanging around on this mailing list... > > Well, although it was some time ago I spent considerable amounts of > time doing graphics, I consider myself at least 0.5 graphic > artists... ;-) > > Problem is (as usual) that doing quality stuff takes time, > inspiration and good ideas, just like coding, creating music or > whatever. Yeah, that's what I keep forgetting, whenever i try to do gfx.. Well, if you _did_ ever fancy knoking up some GFX for amSynth http://amsynthe.sf.net ;-) Nick _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [linux-audio-dev] Poll about linux music audio app usability
On Thu, 2002-06-20 at 00:28, David Olofson wrote: > On Thursday 13 June 2002 00.25, nick wrote: > > IMO, the GIMP has never really had those polishments(?) - artists > > still prefer photoshop and the like, and certainly people i know > > just dont get on with the interface, choosing paint shop pro > > instead, much to my horror ;) > > Well, I almost forgot how to use PhotoShop, and strongly prefer GIMP. Personally, i prefer GIMP too ;-) But the fact is it doensnt meet the needs of the professional artists. But then again, no-ones trying to sell the GIMP to this market, so thats understandable.. More annoying for most users - try drawing simple shapes in gimp. no, you cant. most people just want to draw lines, circles etc.. But ill stop because this is an audio list ;-) Nick _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [linux-audio-dev] digigram's "ethersound"
> radical is to shoot the cookie originator. paul is just resisting > gandhi-style. What did the poor cookies do to you to make you such a bad person ;-?
Re: [linux-audio-dev] timing
On Thursday 20 June 2002 16.37, Juan Linietsky wrote: > On Thu, 20 Jun 2002 11:43:46 +0100 > > dunk fordyce <[EMAIL PROTECTED]> wrote: > > whats the best way to handle timing in a music app? > > I use /dev/rtc in shaketracker, It works very well, but the problem > with it is that > it cant be shared between apps (Athought i'm working on a patch > that would enable it to be shared). Great! I've been thinking about doing that as well. (For non-audio stuff - which is why I got the idea. I didn't want my little project to conflict with audio apps also wanting to use the RTC.) I've also considered implementing the sharing in user space. How about a library that implements an API similar to the multimedia timers of Win32? > Still, unless your app is root, you cant have a latency over 64hz, > so for an userspace app, > it's actually worse than the system timer (10ms) Yeah... Why 64 Hz, when some platforms have HZ = 1000 or 1024 by default, and other drivers are capable of producing much higher IRQ frequencies? IMHO, this value is obsolete, and should be changed to 1024, at least. Either way, with the user space lib solution for RTC sharing, one could avoid this issue by using a root/CAP_RESOURCE daemon to program the RTC frequency. No kernel hack needed. (Or am I missing something?) Of cource, such a library could also be ported to whatever timer implementation you like, including mmtimers or Win32, if anyone cares. :-) (In fact, on platforms that have a usable timer API with sharing, the "port" doesn't even need a lib. A wrapper header would be sufficient.) > I also did some experiments of other approaches, SIGALRM works very > well (better than polling > from what I tried, which skips a lot more). Probably because signals are *slightly* closer to interrupts than blocking methods, such as poll()... > So far, I've also had > some success for reducing > latency by starting 20 threads constanty polling and updating the > timer. Uuurgh! :-D [...] > > i have been looking at tracker code but havent got any solid > > ideas. > > Normal trackers (unless you mean shaketracker/tektracker) use > the audio interrupt through blocking calls. It is a vaid approach > to use those as timers, Yes, and it sort of gives you internal audio/MIDI sync for free. You just have to figure out what N samples mean in MIDI time. > and it's the most common way one under > windows. Are you sure about that? (I don't read much Win32 source these days - and there isn't much source available to read anyway... *heh*) AFAIK, all major audio/MIDI sequencer apps on Win32 still use mmtimers for MIDI-only projects, and I'm quite sure they use them even with audio, since there's no way audio timing can match the accuracy of the commonly used 1 kHz mmtimer rate. > Still, I dont think it's a very clean. I agree. Audio timing is fine for very low latency apps running on Linux/lomlatency (ie > 1k fragments/s), but that's about it. You can't use that kind of fragment sizes in other environments, and less than 1 kHz "MIDI driver clock" degrades MIDI timing accuracy quite substantially. //David .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `---> http://www.linuxdj.com/maia/ -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -'
[linux-audio-dev] [ANN] amSynth 1.0beta4
Hi all. The amSynth beta4 tarball is available now. Get it while its fresh at http://amsynthe.sourceforge.net and be sure to read the README This release provides some significant improvements: * Full ALSA support (PCM audio + MIDI sequencer layer) * MIDI control messages (for preset/patch selection) has been reenabled * Parameters can now be controller with standard MIDI controller messages * Minor fixes and improvements to the interface (mainly the diologs) * New example presets * Fixed an obscure GTK SUID permission problem ! I haven't been able to test the build on a system without ALSA, in theory it should work, but... please tell me if it fails Enjoy Nick _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
RE: [linux-audio-dev] digigram's "ethersound"
> A useful reference for the history of patents and prior art on > packetized audio: > > http://www.cs.columbia.edu/~hgs/rtp/history.html this link seems a bit out of date! Six years is eternity in this business... -- men
Re: [linux-audio-dev] Poll about linux music audio app usability
On Fri, Jun 21, 2002 at 04:05:47PM +0200, Vincent Touquet wrote: > I was thinking about some callback model: > you provide the callback to redraw your > knob after you changed the parameters. Sounds quite like the way FLTK works to me (see www.fltk.org). Cheers, Bill. -- Dr. William Bland, NetPD Ltd. email: wjb at netpd dot com. Microsoft makes simple tasks easy and complex tasks impossible. Sometimes it makes the simple tasks impossible too.
[linux-audio-dev] using LADSPA under cygwin?
Hello again, sorry to bother you all with another stupid question, but I was wondering if anyone can give me any pointers on getting LADSPA stuff to work under cygwin. (I'm not trying to do anything especially clever here, I just want to learn to write plugins but I won't have access to a linux box for a few months, so I figured I'd try to get something working with applyplugin, ready for testing properly when I can use my linux box again) After a little messing around I've got everything in ladspa_sdk to compile, but when I try to use analyseplugin I get Failed to load plugin "amp.so": dlopen: Win32 error 126 which I believe means the file can't be opened. As you probably know by now I'm not too good with this kind of technicality, so any help you can give me would be much appreciated. thanks, Nathaniel
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wed, Jun 19, 2002 at 11:28:14PM +0200, David Olofson wrote:
>That said, the XMMS/WinAmp model *is* in fact of the first kind I
>mention above; GUIs with custom graphics. A skin for such an
>application is basically just a set of images that replace the
>original custom graphics.
>
>It's like replacing the graphics of a game; drawing a bunch of images
>for each object, whereas normal ("GTK+ style" themes consist of
>generic textures and images used by all widgets.
Thats exactly what I'm aiming at :)
I didn't mean themeability in the themes.org sense of the word.
Just an abstraction of functionality:
- sliderbars
- rotational knobs from 1-10
- rotational knobs without beginning and end
...
Just how far you can go, I don't know.
Someone mentioned that the xmms coding style was
to be avoided.
I was thinking about some callback model:
you provide the callback to redraw your
knob after you changed the parameters.
This way you could plug the functionality
of the knobs etc. in your program, just
by providing the graphics and using
the toolkit you want...
Obviously I must have missed all the difficult parts ;)
regards
Vincent
Re: [linux-audio-dev] Poll about linux music audio app usability
On Thursday 13 June 2002 00.25, nick wrote: > IMO, the GIMP has never really had those polishments(?) - artists > still prefer photoshop and the like, and certainly people i know > just dont get on with the interface, choosing paint shop pro > instead, much to my horror ;) Well, I almost forgot how to use PhotoShop, and strongly prefer GIMP. And that PSP thingy just seems totally backwards and generally inferor to me... ;-) //David .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `---> http://www.linuxdj.com/maia/ -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -'
Re: [linux-audio-dev] Poll about linux music audio app usability
On Thursday 13 June 2002 00.07, nick wrote: [...] > I suspect, however, as you have alluded to - that there arent many > graphic artists hanging around on this mailing list... Well, although it was some time ago I spent considerable amounts of time doing graphics, I consider myself at least 0.5 graphic artists... ;-) Problem is (as usual) that doing quality stuff takes time, inspiration and good ideas, just like coding, creating music or whatever. //David .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `---> http://www.linuxdj.com/maia/ -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -'
Re: [linux-audio-dev] Poll about linux music audio app usability
On Thursday 13 June 2002 14.02, Dave Griffiths wrote: > > The problem seems to be either... > > > > A) That there aren't enough of these people to go around. > > > > B) That these people aren't in touch with the people who > > want to write code, or just have a hard time coordinating with > > them. > > > > or C) That these people aren't very deeply involved with the > > linux / free software circles... maybe because being a good > > designer doesn't necessarily make one a good geek. > > Personally speaking, I think one of the most interesting areas of > audio app design is the user interface, because there is no really > obvious way of doing it. Good point. > I'm really interested in unusual solutions > to these problems, and not necessarily only visually - I'd quite > like to get a text based interface to SSM one day. > > One of the things I'm always slightly disappointed in Linux apps > (including my own) is the lack of originality of interface and > ideas, too many clones of existing solutions - when we have the > freedom and lack of commercial worries to do whatever we want. You're missing one thing: We don't really have the freedom you suggest. We have limited resources, and need to cooperate for any major projects to take off. If you're doing "highly experimental" stuff, you're more likely to be left on your own. And of course, experimental solutions are by definition very likely not to work out right. I think Free/Open Source hackers stay away from them to minimize the risk of wasting precious hacking time on bad ideas. //David .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `---> http://www.linuxdj.com/maia/ -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -'
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wednesday 12 June 2002 14.56, Paul Davis wrote:
> >The way I'd like to do it is by throwing "live" objects into the
> >canvas, assign various graphic shapes or images to them, and then
> >connect them to the logic through callbacks, events or whatever.
> > The point is that "basic" stuff like catching clicks, handle
> > dragging, control Z order etc, should be handled by the
> > *toolkit*; not application code or custom widgets.
>
> welcome to the {Gtk,Gnome}Canvas.
I'm definitely considering using one of those - possibly both -
either as is (and just hack away :-), or as the backend for some sort
of toolkit. (The latter might be a way of avoiding tying application
code to GTK+ or Qt.)
//David
.- M A I A -.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`---> http://www.linuxdj.com/maia/ -'
.- David Olofson ---.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-> http://olofson.net -'
Re: [linux-audio-dev] Poll about linux music audio app usability
On Thursday 13 June 2002 02.03, Andy Wingo wrote:
> On Wed, 12 Jun 2002, Paul Davis wrote:
> > welcome to the {Gtk,Gnome}Canvas.
>
> BTW. This is only somewhat on-topic, but...
>
> as a history, GtkCanvas is essentially the same as the Gtk+-1.2
> GnomeCanvas, but available in a separate package and with functions
> renamed accordingly. GnomeCanvas used to be available only as a
> part of the Gnome libraries.
>
> the Gtk+-2.0 version of GnomeCanvas is available as a separate
> package, which does not depend on anything but Gtk+-2.0 and libart
> (which is one of the canvas backends in 2.0 as well). So, I know
> why paul pushes GtkCanvas, but people looking for a maintained
> package and don't mind Gtk+-2.0 (which is very stable) should take
> a look at the GnomeCanvas instead.
Aaargh! This is exactly what I don't like about these sort of
solutions.
Why is the "Canvas API" part of either a toolkit or a desktop
environment? Why do they have different (even if only slightly so)
APIs?
As an example of the Right Way(TM) to do it, I'd like to use OpenGL.
It's the same regardless of driver, hardware or operating system. The
only missing part is setting up the display, which is done
differently on different platforms.
My point is that whether you're using glx to set up OpenGL on X, or
wgl to set up a display on Win32, OpenGL is still OpenGL. Use SDL or
something to set up the display, and your code can be *totally*
portable to any platform that has OpenGL.
> And of course, as Richard mentioned, there's a Qt equivalent too ;)
Here we go again... :-)
//David
.- M A I A -.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`---> http://www.linuxdj.com/maia/ -'
.- David Olofson ---.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-> http://olofson.net -'
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wednesday 12 June 2002 23.15, Kasper Souren wrote: [...] > > Well, a man can dream... > > Certainly. And a man can hope... that AGNULA will be a success. > Since then the userbase will be expanded big time. Well, considering the number of people playing and creating music in one way or another, there must be a *gigantic* potential user base. We "just" have to bring a bunch over to Linux! :-) However, there's one thing that's seriously worrying me: Software piracy. I saw a poll somewhere, that indicated that a vast *majority* of computer users considered piracy more or less "OK". It's like they simply don't consider it a crime at all. What this means to us is that we're effectively competing with high end professional software *ON EQUAL TERMS*! Actually, worse than equal terms: They make money, while we do not. * Most of these users couldn't care less about Open Source (if they even know what it's about), so that's not an advantage for us. * Most of them don't give a damn about paying for the software they use anyway, so we have no advantage there either. As to true professionals, I believe a large portion of them don't have a real problem with paying for good software - and either way, they'll just pay what it costs to get a sufficient solution. Doesn't matter if it's free, Free/Open Source or whatever, if it doesn't quite cut it. Don't get me wrong - I believe in Free/Open Source software, even for professional audio. I'm just trying to identify the competition, and come up with some sort of strategy. (For those who care to actively fight for Linux audio, that is. Others; just hack on as usual - you're probably the most sensible people around here anyway. :-) //David .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `---> http://www.linuxdj.com/maia/ -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -'
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wednesday 12 June 2002 11.20, Vincent Touquet wrote:
> Continuing in the thinking out loud department,
> so I don't have to study ;):
>
> Seems a waste to hardcode all the GUI stuff though.
>
> How do they get about theming their controls
> in Xmms / mplayer ... ?
>
> Slider bars get different sizes and sometimes
> shapes in such programs, yet they
> retain their basic functionality.
>
> Guess we should try to do something similar,
> instead of hardcoding the actual appearance
> of a knob / slider.
That's a nice idea, but I'm afraid it leads right into that dreaded
complexity/flexibility trap. Either you make an advanced and great
looking GUI with custom graphics, or you use a themable "standard
GUI", such as GTK+ or Qt. (Of course, you can use the latter to
implement the former, but then you end up with a GUI that doesn't
care about standard themes anyway.)
That said, the XMMS/WinAmp model *is* in fact of the first kind I
mention above; GUIs with custom graphics. A skin for such an
application is basically just a set of images that replace the
original custom graphics.
It's like replacing the graphics of a game; drawing a bunch of images
for each object, whereas normal ("GTK+ style" themes consist of
generic textures and images used by all widgets.
//David
.- M A I A -.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`---> http://www.linuxdj.com/maia/ -'
.- David Olofson ---.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-> http://olofson.net -'
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wednesday 12 June 2002 14.40, Paul Davis wrote: [...] > There are rumblings in the GTK+ camp that a distant version of GTK+ > might switch entirely to the canvas model, and all widgets would > just be canvas items that drew themselves onto the canvas RGB > buffer. Sounds like my way of thinking... (Inspired by games programming.) It's also the only remotely reliable and portable way of rendering high quality graphics with blending, antialiasing etc. (Well, OpenGL works as well, but to be picky, it's not a pixel precise standard. Things will look slightly different depending on drivers and hardware.) > But this is a long way off, if in fact it ever happens. The > end result for now is that you can't mix-n-match CanvasItems with > widgets, and I suspect this is true for Qt and other toolkits as > well. How about turning most of GDK into a software rendering library, keeping only the RGB buffer as a "real" path to the display? Or is there something weird with the general design that prevents this approach? //David .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `---> http://www.linuxdj.com/maia/ -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -'
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wednesday 12 June 2002 22.37, you wrote: > On 12 Jun 2002, nick wrote: > > What would be really good is if people donated money to the > > projects they find useful (paypal/nochex), because I sure as hell > > dont see the major distros supporting media apps development any > > time soon. Maybe that's what's needed - a distributor making > > music systems, who can then put money back into the apps. > > I don't really see that as a viable option. If I solicit > 'donations' then I take on the implied obligation of doing work > which may not be possible or worthwhile due to time constraints: I > think my time is worth alot of money, probably more than my users > think. In my case, it's not really a matter of what I think my time is worth in money, but rather that I can't spend more time hacking, whether or not I get paid for it. Well, unless I get enough that I can quit my job, of course. Of course, in some cases, projects that get donations could perhaps get higher priority than others - but frankly, do we really care that much about money? At least, I don't. Or rather, I care much more about "quality time" and hacking stuff I like. Effectively working for money 12+/7 would just ruin my mental and physical health in no time, for no long term gain. (Situation's bad enough as it is! ;-) > I see only two options: Go all the way, ask all users to pay, > lose personal ownership of the project and turn it into a product, > or ask nothing and expect nothing. Anything in between puts > everyone in a bad position: users might feel obligated to > contribute even though they have no guarentee of getting anything > for it, or the author might feel obligated to continue working even > though the financial reward is insufficient and charity rather than > market driven. Exactly. //David .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `---> http://www.linuxdj.com/maia/ -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -'
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wednesday 12 June 2002 16.18, Billy Biggs wrote: [...] > But that's sort of the thought behind ttrk: be a useful hardware > sequencer. I can't stand piano roll views, they just don't make > sense for the music I'm writing. I usually write electronic dance > music where I want to see everything that happens on one beat all > at once, There *are* piano rolls that will allow you to view and edit multiple tracks at a time, but as you might guess, it doesn't work half as well as it sounds at first. And then we have controller data editing... *aargh!* > and it is _essential_ that I be able to edit the music as > it's playing: start looping one pattern and tweak it until I like > it. I do that sometimes as well - but obviously, there's a lot of jumping between tracks when doing it with a traditional GUI sequencer. *heh* > Different styles for different types of music really. I dunno... I do what I feel like WRT style and sound, and I don't like applications that try to prevent me from mixing different ways of working. Different tools for different jobs - but that doesn't mean you're supposed to use a single tool for each song. :-) > I also > think it's because when I started writing music, it was using > either a tracker or a hardware sequencer (at the time the Roland > MV-30). That's quite possible - but OTOH, I started out with trackers, eventually got into GUI sequencers, and then couldn't really go back. Initially, I had major problems doing any real work in a GUI sequencer, but now it's the other way around... //David .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `---> http://www.linuxdj.com/maia/ -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -'
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wednesday 12 June 2002 11.17, Vincent Touquet wrote: > I have never done any GUI programming before. > > Writing these comprehensive widgets > with cool knobs, smooth slides, > graphical equalizers etc. seems > difficult though. GUI programming is not really difficult IMHO, but the difference between the first estimation of development time and the time it actually takes to hack is probably the bigger than for any other kind of programming. It looks like it would be a fast and easy hack, as everything's so visually "obvious" and intuitive, but that's just an illusion... > I think an effort should be undertaken to > get a group of people to write these damn things :) Yes, but how about motivation, and getting the right people to do their best? > I fear model-view-controller separation > doesn't apply here, as we are entirely > in the view realm. I don't agree there. The major difference is probably that there's much more "logic" inside the GUI part - not that there all of a sudden is a good reason to mix things that don't belong together. In fact, the separation between engine and UI is an absolute *requirement* for real time audio/MIDI applications, as you simply cannot make them work reliably if there are too many places where the UI may interfere with the timing of the engine. "Monolith GUI + modular engine" is a basic design idea that makes sense here, IMHO. (A modular/plugin based GUI might work as well, but then we're back in this "different toolkits won't mix" mess again...) > So we are stuck basicly to implement > these things for *all* the major toolkits, > GTK, QT, etc. Yes, but perhaps we can do something about that, as a part of creating a VSTGUI style toolkit, more suitable for the kind of highly interactive GUIs we need. The design I have in mind could be implemented inside any toolkit that provides access to the underlying "drawing toolkit" - or directly on top of the rendering target or API (SDL, X, fbdev, svgalib, GDI, DirectDraw, Direct3D/Graphics, OpenGL...), for that matter. The only truly required feature is a way of rendering rectangular images into windows. All higher level stuff is just to allow certain targets to use hardware acceleration for specific features - ie performance hacks. (That is, stuff that optimization freaks can play around with after the toolkit is implemented and working. :-) If one can get away with designing such a toolkit that's actually usable, any code that uses it will happily interact with any toolkit, and it could also serve as a highly portable stand-alone toolkit. [...] Either way, the major issue here is not *how* we should go about getting proper GUIs for more and larger Linux music application, but how we should get anyone to do any serious GUI hacking *at all*. There are a few exceptions, but the fact remains: The LAD community consists mostly of *audio* hackers. (Makes sense, sorta'... ;-) //David .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `---> http://www.linuxdj.com/maia/ -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -'
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wednesday 12 June 2002 11.04, Michael Toomim wrote: > David Olofson wrote: > > ...and wants to hack a *really* complex one for a music > > application. You also need to find a good GUI designer, unless > > you're lucky enough to find someone that can do both. > > > > I'm quite sure it's not remotely as easy as you suggest. > > I don't see what the big deal is. Isn't GUI design the fun part? Well, I *like* most kinds of programming - but that only makes it harder to decide what to do. I need to code for a living, and I have a family to take care of. The remaining spare time is all I have, so I simply have to hack one or two things at a time, or I'll never get anything useful together. Obviously, that means some things have to wait until others are finished. I believe this is pretty much the situation for anyone who can't hack whatever they like, full time. In fact, it probably applies to *everyone* to some extent. > I'd expect there to be a lot more HCI people in the computer-music > circles... Why? And why would they "waste" their precious time hacking and polishing GUI stuff beyond the point where it's "usable" to them? //David .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `---> http://www.linuxdj.com/maia/ -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-> http://olofson.net -'
Re: [linux-audio-dev] digigram's "ethersound"
xk wrote: > > > cuter than that. i think they want to set a cookie. since i block > > almost all cookies with internet junkbuster, its impossible to get to > > the page ... sigh. > > Isn't that a little bit radical? You could just delete all the cookies from > time to time. radical is to shoot the cookie originator. paul is just resisting gandhi-style.
