Re: [linux-audio-dev] Poll about linux music audio app usability
On Fri, 21 Jun 2002, David Olofson wrote: 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 Maybe. I really like its window snapping behavior. And I think the intention was to make it as similar to winamp as possible. Based on that, they've done a pretty good job. Taybin
Re: [linux-audio-dev] Poll about linux music audio app usability
On Friday 21 June 2002 19.29, Vincent Touquet wrote: [...] On Wed, Jun 19, 2002 at 11:20:20PM +0200, David Olofson wrote: 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 ? Well, I'll try to explain the basic ideas. First of all, we have a canvas object, quite similar to the GnomeCanvas. It's basically a drawing area onto which you can place visual objects, such as lines, circles, polygons, images and so on. (The image part I'm thinking about might be different from that of GnomeCanvas, though. I'm thinking along the OpenGL lines; textured polygons - although there probably won't be any Z coordinates, and a very simple transformation matrix, if any.) By mentioning the visual objects, I've already moved on to the layer above the canvas. As opposed to any canvas I've seen so far, this layer will also contain logic objects - objects that are invisible, and serve as a physical skeleton behind the scenes. The point with these logic objects is that you'll be able to connect nodes (vertices) of visual objects to them in various ways. For example, you'd connect the center node of a knob image to a logic line in order to construct a slider. The logic line would track and restrict the movement of the knob, so that the user can drag the knob, and the application can move it by simply passing a value to the logic line. (That is, from the application POV, the logic line object appears to be the actual widget.) 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 :) Yep. 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. Yeah - the idea is more or less to create a toolkit specifically for *audio* appications. 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 :) Well, I'll try to get started before you get bored... ;-) //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 19.40, Michael Toomim wrote: 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 I'll check it out, although I'm worried about portability. (Not being tied to X is a design goal, but getting something useful up running has higher priority right now.) //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 21.30, nick wrote: 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 :) Meanwhile, Microsoft is moving to Direct3D, and Apple to OpenGL, to get exactly that... Why maintain two sets of drivers for the same hardware features? //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 Saturday 22 June 2002 15.38, Taybin Rutkin wrote: On Fri, 21 Jun 2002, David Olofson wrote: 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 Maybe. I really like its window snapping behavior. I like window snapping as well, but I like KWM's version better. It doesn't really lock windows together; it just help you aling windows edge-to-edge very quickly, and that's just the way I like it. And KWM's snapping works for all apps. Well, short of XMMS, that is... And I think the intention was to make it as similar to winamp as possible. Based on that, they've done a pretty good job. Yes indeed, but I think they should have aimed a lot higher than emulating the WinAmp API when they were at it... :-) Granted, WinAmp actually improves (some) things on the window manegment side on Win32 - but that's just because the Win32 WM is completely useless. //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 Sat, Jun 22, 2002 at 07:13:43AM +0200, David Olofson wrote: Well, I'll try to get started before you get bored... ;-) ;-) Well, I read all the stuff you wrote and I agree. Especially the idea of logical vertices and lines is a good one and most of the time, though not always beautiful ideas can lead to nice code. (didn't say always :) I don't have more time to elaborate as of now (exams :), they will be finished the 26nd though). I'll make sure I'll get back to you about this :) regards Vincent
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] 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 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 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 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 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 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 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 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 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 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 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 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.
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] 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
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 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
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
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
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
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
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
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
-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
-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
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
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] 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
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
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
Chris Butt wrote: But yeah, could something like agnula or the lad site have a 'so you want to help but you can't compile alsa' or 'things for people with little skill but enthusiasm'? sounds like a very good idea to me. i'll think about it some more. ideas welcome. (preferably off-list, we can go back to public discussion as soon as there is a first draft on the LAD page.) regards, jörn
Re: [linux-audio-dev] Poll about linux music audio app usability
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. 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. Dave : www.pawfal.org :
Re: [linux-audio-dev] Poll about linux music audio app usability
On Thu, Jun 13, 2002 at 02:02:49 +0200, Dave Griffiths wrote: 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. I think you do yourself a disservice. Spiral loops has a great interface design. Theres a few things I would add, but its novel AFAIK, and very appropriate. - Steve
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wednesday 12 June 2002 16:37, Billy Biggs wrote: 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. There's always the classic FSF model: an agreement with a particular user that needs a feature to add that feature for a specific price. The feature then becomes part of the standard open source distro (so all the community benefits). I understand Richard Stallman made a living for many years this way. Cheers! |-| |Frederick F. Gleason, Jr.|WAVA Radio - 105 FM |Voice: 1-(703)-807-2266 | | Director of Engineering |1901 N. Moore Street| FAX: 1-(703)-807-2245 | | |Arlington, VA 22209 | Web: HTTP://www.wava.com| |-| | All progress is based upon a universal innate desire of every organism | | to live beyond its income. | | -- Samuel Butler| |Notebooks | |-|
Re: [linux-audio-dev] Poll about linux music audio app usability
On Thu, 13 Jun 2002, Fred Gleason wrote: On Wednesday 12 June 2002 16:37, Billy Biggs wrote: 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. There's always the classic FSF model: an agreement with a particular user that needs a feature to add that feature for a specific price. The feature then becomes part of the standard open source distro (so all the community benefits). I understand Richard Stallman made a living for many years this way. And what happened to sites like sourceXchange? Regardless, I don't think there is much consumer interest in this model because consumers can't afford my salary, nor are they willing to pay for something until they see the finished, working product: there is too much poorly written software out there to trust money to random developers, even those with good track records. That said, I don't want all software to be written for corporations either. Software companies don't want soft-synths or drum machines, the bulk of that market is consumers and prosumers, and what few companies that do (studios etc) can't afford my salary either, especially if I'm competing with commercial software that's only a few hundred dollars per fully featured app. -- Billy Biggs [EMAIL PROTECTED] http://www.div8.net/billy [EMAIL PROTECTED]
Re: [linux-audio-dev] Poll about linux music audio app usability
Alexander Ehlert wrote: You just have to find someone who likes GUI programming... I like GUI programming!
Re: [linux-audio-dev] Poll about linux music audio app usability
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? I'd expect there to be a lot more HCI people in the computer-music circles...
Re: [linux-audio-dev] Poll about linux music audio app usability
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. regards Vincent
Re: [linux-audio-dev] Poll about linux music audio app usability
Of course, since I have a market size of 1 (myself), and pretty much no interest from the open-source community, the project hasn't gone anywhere else. But I'm quite happy with it. :) Make that two!! :) ttrk has been one of my favorite audio apps for a while now. Thanks to the well-defined set of functionality and the way it is implemented, there just isn't much to complain about. ;) Make it three! ttrk is just about perfect at doing what it does. It's by far the best tracker I've ever used, mainly due to the fact that it doesn't scroll as it plays, so you can edit in real-time in a much less fiddly way than most trackers. Having working midi sync is a big bonus too. I have actually done some minor hacking of the user interface -- I've been meaning to send you the code for ages, but I can't do it for a while becuase I am not in the same country as my linux box.
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wed, 2002-06-12 at 10: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. Theyre not *that* difficult really, it's just the initial learning which is a problem. In fact, i'd say skinned ones are easier to write because you dont have to write the code to render stuff, its all in a pixmap already (this is from my experience writing amSynth http://amsynthe.sf.net). The problem is that everyone likes a different toolkit.. for example, I used GTK--, and so I wasnt able to just use an existing GTK bit of code, it was easier to write one from scratch in GTK--.. I think an effort should be undertaken to get a group of people to write these damn things :) But yes, a library of these would be damn sweet. in the style of gtkext (extra widgets for gtk) we could make one, but then the problem is the user must have this extra library installed, and us developers hate extra dependencies to worry about (at least *i* do). Perhaps making a static library would be best.. Or maybe just writing them and giving out the code so others can incorporate it and/or modify it for thier needs? So we are stuck basicly to implement these things for *all* the major toolkits, GTK, QT, etc. Now theres the problem ;-) Regards, 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 Wed, Jun 12, 2002 at 11:19:56AM +0100, nick wrote: (cut) Theyre not *that* difficult really, it's just the initial learning which already (this is from my experience writing amSynth http://amsynthe.sf.net). The problem is that everyone likes a different toolkit.. for example, I used GTK--, and so I wasnt able to just use an existing GTK bit of code, it was easier to write one from scratch in GTK--.. Hm, nice project by the way :) But yes, a library of these would be damn sweet. in the style of gtkext (extra widgets for gtk) we could make one, but then the problem is the user must have this extra library installed, and us developers hate extra dependencies to worry about (at least *i* do). Well, at least they are not forced to use them. They are Free to do what they want :-) It's just that such a thing is not available yet IMHO, but it should be otherwise I think lots of good audio developers start wasting their time on the same thing: writing (sometimes ugly) widgets (hey its not ok to expect audio programmers to be masters in GUI too :) Paul: didn't you write some sort of a GUI widget for Ardour ? What do you think about this ? Perhaps making a static library would be best.. Or maybe just writing them and giving out the code so others can incorporate it and/or modify it for thier needs? Yup, code code code :) Once the code is there the rest is easy I think. So we are stuck basicly to implement these things for *all* the major toolkits, GTK, QT, etc. Now theres the problem ;-) Well, we can start with one :) Rome wasn't built in a day ? regards Vincent
Re: [linux-audio-dev] Poll about linux music audio app usability
Keep this idea on hold for a while (but keep on discussing :). I'm going offlist for a while (won't read it till end of June), cause exames are up and I always find a good excuse inhere not to study ;) so see you later ! regards Vini
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wed, Jun 12, 2002 at 11:19:56AM +0100, nick wrote: (cut) Theyre not *that* difficult really, it's just the initial learning which already (this is from my experience writing amSynth http://amsynthe.sf.net). The problem is that everyone likes a different toolkit.. for example, I used GTK--, and so I wasnt able to just use an existing GTK bit of code, it was easier to write one from scratch in GTK--.. Its funny that you have chosen to show knobs as collared rotary encoders, on a system that has no moving parts :) http://amsynthe.sourceforge.net/shots.html - Steve
Re: [linux-audio-dev] Poll about linux music audio app usability
Paul: didn't you write some sort of a GUI
widget for Ardour ?
What do you think about this ?
gtkmmext contains several relevant widgets, the most relevant of which
is Gtkmmext::MotionFeedback. this takes a set of pixmaps, a
Gtk::Adjustment and a few other arguments, and uses the set of pixmaps
to display the current value of the adjustment. Mouse motion initiated
by a click on the widget can be used to alter the value of the
adjustment, which in turn affects the pixmap displayed. It doesn't
care how many pixmaps are involved, what the value ranges are etc. It
also has an option to display the numeric value of the adjustment in
addition to the pixmaps.
I also made a GTK+ widget from GLAME more general purpose, the
GtkPixScrollbar, which takes two pixmaps, and slides one over the
other. It figures out whether they should be horizontal or vertical
from their aspect ratios. I think this may have been fed back into
GLAME, but its also gtkmmext.
Based on this, there is Gtkmmext::SliderController which comes with
builtin MIDI control capabilities. This is a hard one, because its
mostly a GUI widget, but it has to know about MIDI, which means it
really belongs in a library all by itself. Right now, its still in
gtkmmext, but uses libmidi++. The inheritance tree looks like:
Gtkmmext::[VH]SliderController HAS-A PixScrollbar and IS-A
Gtkmmext::SliderController IS-A
Gtkmmext::Controller IS-A
MIDI++::Controllable IS-A
I think I planned to put a MIDI-controlled version of MotionFeedback
in there at some point, but I don't seem to have done that yet.
There is also GtkLevelHold, and its counterpart Gtkmmext::LevelHold,
which is mostly written by Eric Tiedemann, and is the level meters you
see in screenshots of Ardour. It needs rewriting as a Canvas item,
IMHO. There is also GtkMarkedCurve/Gtkmmext::MarkedCurve, which I used
to use in Quasimodo for envelope editing, Gtkmmext::HexEntry which I
use for manual entering of hexadecimal data such as raw MIDI bytes and
a few others.
For Ardour, most of the custom widget work has been Canvas items,
which include:
canvas-waveview: takes a generic object that can fetch raw+peak
data for a mono waveform and renders it
directly to the canvas RGB buffer,
caching chunks of it for fast updates.
loosely modelled on GtkWaveView by David
Bartold, but drastically altered to use
externally computed peak data and to
render directly to RGB. Extremely,
extremely fast and efficient (assuming
access to the underlying data is quick)
canvas-simple{rect,line}: extremely efficient drawing of
rectangles and lines into the canvas
RGB buffer
The {Gtk,Gnome}Canvas is a thing of beauty and people should get to
know it and probably its Qt counterparts well.
But I've said before that the wave display stuff is the hardest to
generalize. How it works depends a lot on the basic design of the
application using it. GtkWaveView, for all of its elegant design,
didn't work for me because it was based on a model of an editor like
snd, or audacity or sweep. Its likely that you would not be able to
use the GtkCanvasWaveView item for such an editor without modifying it
in ways that I haven't thought of. In addition, there is a big
difference between the basic model of a CanvasItem and a widget, and
although a simple description of each would sound similar, they are
not really interchangeable (which is a shame). 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. 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.
--p
Re: [linux-audio-dev] Poll about linux music audio app usability
How do they get about theming their controls in Xmms / mplayer ... ? i don't know about xmms, but the GTK+ crowd, particularly havoc, really don't like xmms since it violates most of the basic rules about using GTK+. Slider bars get different sizes and sometimes shapes in such programs, yet they retain their basic functionality. they just use pixmaps for everything. see my other message.
Re: [linux-audio-dev] Poll about linux music audio app usability
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.
--p
Re: [linux-audio-dev] Poll about linux music audio app usability
Paul Davis wrote:
The {Gtk,Gnome}Canvas is a thing of beauty and people should get to
know it and probably its Qt counterparts well.
I can only speak from the Qt side of things but I quite agree. We use
QCanvas and QCanvasView with a bunch of QCanvasItems and specialisations
thereof for our top level Segment view and very happy with it we are
too.
I'm flame-bait again really but Qt specialisations are something of a
joy to behold. If you don't find what you need you can usually knock
up something that does in next to no time.
R
--
http://www.all-day-breakfast.com/rosegarden
http://www.bownie.com
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wednesday 12 June 2002 06:19, nick wrote: But yes, a library of these would be damn sweet. in the style of gtkext (extra widgets for gtk) we could make one, but then the problem is the user must have this extra library installed, and us developers hate extra dependencies to worry about (at least *i* do). You might want to check out a small library I've been working on (Qt based). It's still in the early stages, but so far I've implemented faders, volume controls and audio metering (among other things). The Qt signal/slot mechanism has proved to be an elegant architecture for this sort of work. http://linux.blackhawke.net/revolution12/ The library name is 'libradio'. There's also a screenshot (for the Revolution12 package, which uses the library). Cheers! |-| |Frederick F. Gleason, Jr.|WAVA Radio - 105 FM |Voice: 1-(703)-807-2266 | | Director of Engineering |1901 N. Moore Street| FAX: 1-(703)-807-2245 | | |Arlington, VA 22209 | Web: HTTP://www.wava.com| |-| | The day-to-day travails of the Windows (tm) programmer are so amusing | | to most of us who are fortunate enough never to have been one -- like | | watching Charlie Chaplin trying to cook a shoe. | |-|
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wed, 12 Jun 2002, David Olofson wrote: Well, I'm *interested* - I've actually downloaded it and looked at it! :-) Problem is that I don't really like the traditional tracker idea anymore. I just record stuff from the keyboard and prefer editing notes using some kind of piano roll view. The typical sequencer event list editor *really* sucks, though. Something more like an Old Skool tracker interface might work for that part... I do need to add in some code to let me record from MIDI in: right now I use my MMT8 for that work, and since the MMT8's event list editor sucks, ttrk is my step record device, for basslines, drum hits, and other background stuff. I actually have a nice system set up so I can 'upload' ttrk loops right into the MMT8 so I don't need to take a computer to shows. 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, 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. Different styles for different types of music really. 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). -- Billy Biggs [EMAIL PROTECTED] http://www.div8.net/billy [EMAIL PROTECTED]
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wed, 2002-06-12 at 13:50, Paul Davis wrote: How do they get about theming their controls in Xmms / mplayer ... ? i don't know about xmms, but the GTK+ crowd, particularly havoc, really don't like xmms since it violates most of the basic rules about using GTK+. really? any examples of thing *not* to do? (is there a discussion of this somewhere?) 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
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, 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 also make house music, and to me the tracker view doesn't make sense. Imaggine that! In this view it's difficult for many people to see exactly where a note starts, when it ends and how the general line feels. In a piano rool view I can see all these things at a glance. Not to mention that the tracker view doesn't support polyphony. What I'm trying to say is that a software should support all the major ways of working. Like Sonar or Cubase, which can work like a real hardware mixing desk, by recording the knob moving when the track plays, but can also automate them through envelopes. This way everybody's happy and the user can choose the most effective way to get the job done. Of course, because your tracker it's written for your own personal use it's normal to not spend time implementing things you don't need. But developers which make software intended to be used by a large number of users should try to implement things people like even if they seem stupid to them. I'm thinking at FruityLoops which is the most popular program for electronic dance music. It's a tracker/sequencer hybrid which is easy to use and very powerful at the same time.
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wed, 12 Jun 2002, xk wrote: Of course, because your tracker it's written for your own personal use it's normal to not spend time implementing things you don't need. But developers which make software intended to be used by a large number of users should try to implement things people like even if they seem stupid to them. I'm thinking at FruityLoops which is the most popular program for electronic dance music. It's a tracker/sequencer hybrid which is easy to use and very powerful at the same time. This is fair. I know that usually I write software for myself, and sometimes I try to throw in features that would make my software appeal to a larger market. As a hobbyist my hobby is writing code first and making applications/products second. There is too much code I want to write to have enough time to spend a year polishing every app. Personally I see this as the 'flaw' with free software: most of it is code first and application second. And I'm totally ok with that, although it's awkward to read posts from users who expect things to work the other way around. I just don't see the large number of hobbyist programmers becoming product manager hobbyists any time soon, despite how badly the linux userbase wants that. :) -- Billy Biggs [EMAIL PROTECTED] http://www.div8.net/billy [EMAIL PROTECTED]
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wed, 2002-06-12 at 19:27, Billy Biggs wrote: Personally I see this as the 'flaw' with free software: most of it is code first and application second. And I'm totally ok with that, although it's awkward to read posts from users who expect things to work the other way around. I just don't see the large number of hobbyist programmers becoming product manager hobbyists any time soon, despite how badly the linux userbase wants that. :) Exactly. I mean, I'm happy to let others use my software, but ultimately I write it because I want a tool to do a particular thing. If people want useability features etc.. then really someone's going to have to pay for it. I don't see how anyone could have the time it takes to polish a piece of software with no compensation. 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. Well, a man can dream... 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 Wed, 2002-06-12 at 22:03, Michael Toomim wrote: nick wrote: Exactly. I mean, I'm happy to let others use my software, but ultimately I write it because I want a tool to do a particular thing. If people want useability features etc.. then really someone's going to have to pay for it. I don't see how anyone could have the time it takes to polish a piece of software with no compensation. Just to throw in my 2 cents, I don't think that this is universally true. I think that there are people out there who enjoy polishing applications more than writing internal code... people who would rather be artistic interaction designers than slave away at nuts and bolts... people who really want their programs to be popular. 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. So maybe the problem is that you need people who are both good designers AND good geeks, because without the geekdom they won't be hanging out on this mailing list? Michael All true, I do actually enjoy polishing my app(s?), and i definitely *do* want it to be popular, but it means that ive had no time to work on the actual audio code, which is where the interesting stuff is. I really appreciate nice interfaces, and would love to see my synth have one of those, but the truth is i find it hard to come up with anything i can be proud of. I suspect, however, as you have alluded to - that there arent many graphic artists hanging around on this mailing list... 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 Wed, 2002-06-12 at 22:15, Kasper Souren wrote: nick wrote: Exactly. I mean, I'm happy to let others use my software, but ultimately I write it because I want a tool to do a particular thing. If people want useability features etc.. then really someone's going to have to pay for it. I don't see how anyone could have the time it takes to polish a piece of software with no compensation. I think once the userbase is large enough, the polishing of the software will also come. The GIMP started as something not so really useful, but now it's already quite a decent alternative for Photoshop. 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 ;) 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 think a donation system would be great. Fortuneately the EU is already making donations, in the form of the AGNULA project (www.agnula.org). And Red Hat is involved, so there already is a big distributor making systems. 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. Yes, but deep down i know the users will rarely donate, good thing theyve got redhat on board. what about SuSE? theyre involved in audio, so... greetz, Kasper Regards, 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
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. May I suggest another possibility? The learning curve is huge. Consider lots of people (including me) get potted linux distributions. Mandrake for example, which now installs better than windows. Installing software at first appears to be as simple as downloading an rpm. Compiling from source is a major experience the first (few) time(s), and it's fine when it all works well, (as long as you know where everything ended up), but when it goes wrong it's very confusing. Alsa, jack and so on look really cool, but when the only available html documentation is for how to install the now-unsupported 0.5 and phrases like 'installable kernel modules' crop up - you start to wonder if maybe that bundled oss/free that works already isn't all that bad... My exams are over in just over a week, and I intend on getting my pc running linux full time with alsa and stuff. I really want to help do /something/ in the linux sound area - at the moment I'm very definetly on the needing help stage. Is there an open source careers advisor somewhere that can give you a questionnaire, find out what you're capable of, and find something for you to do? Even if it's designing chromy skins for audio apps or writing a complete dumb-ass's (TM) guide on alsa and jack for beginners? I like the way mozilla says 'Hey, you don't need to know nothing to join in, just do this, testcase that, submit bugs, etc.' Could a bugzilla be set up for linux audio as a whole, so people could be told 'hey.. you only need a minimum of 6 years experience in the pro audio industry, the ability to create your own linux distro and a degree in musical instrument technology to be useful'. Sorry... I'm sure that isn't the case, but it feels that way to me sometimes - :) But yeah, could something like agnula or the lad site have a 'so you want to help but you can't compile alsa' or 'things for people with little skill but enthusiasm'? Yours, intimidated Chris Butt ?8} --
Re: [linux-audio-dev] Poll about linux music audio app usability
My exams are over in just over a week, and I intend on getting my pc running linux full time with alsa and stuff. I really want to help do /something/ in the linux sound area - at the moment I'm very definetly on the needing help stage. Great, more power to you !! If you need help, post on the lists, we are here. Not all people must be coders though :) I really agree with Maddog Hall when he says that in the Free Software Community everyone is important. If you don't know how ALSA works, but you maintain a wiki, more power to you. If you get frustrated with obsolete or not existing documentation and you write some, the hours you have put in it will be saved many more times. Is there an open source careers advisor somewhere that can give you a questionnaire, find out what you're capable of, and find something for you to do? Even if it's designing chromy skins for audio apps or writing a complete dumb-ass's (TM) guide on alsa and jack for beginners? Anything :) I like the way mozilla says 'Hey, you don't need to know nothing to join in, just do this, testcase that, submit bugs, etc.' Not a bad idea. Something like a todo list. Or where people can vote for 'janitor tasks', though I find this term a bit on the negative side ... (cut) Sorry... I'm sure that isn't the case, but it feels that way to me sometimes - :) Spill your guts. We are human, we make mistaks, we want to learn from anyone who has a grudge and can explain it in a sensible way even when coding is our second nature (well not me, but consider Paul ;) and we are ninja Uebergeeks. But yeah, could something like agnula or the lad site have a 'so you want to help but you can't compile alsa' or 'things for people with little skill but enthusiasm'? If you have an itch, scratch it. Yours, intimidated Don't be, consider yourself welcome ! Minor point: this is a list for developers, maybe your points are more on topic on linux-audio-user. This is not intended to scare you off :) Just the bare facts of Internet life. respect, Vincent
Re: [linux-audio-dev] Poll about linux music audio app usability
On Mon, 10 Jun 2002, Alexander Ehlert wrote: [...] The programs you mentioned cost a lot of money and their programmers work full time on it. And they have to do those nice GUI's if they want to sell it. Having a shiny metal interface doesn't mean their sound better, anyway. If I compare reactor with glame, I'd say that glame ladsa plugins provides the better guitar fx box with less latency. They charge 200 Euro for it... Ok, we still don't have MIDI, hm For more discussion, the Korg ER-1 drum machine is, in my opinion, an amazing piece of gear. It doesn't do anything that hasn't been done before, and it's much less powerful than similar instruments, but the interface is perfect for composing and playing around. The same holds for software as well: interface is almost everything. I would much rather have a sequencer with less features and a good UI than a fully-featured one that's annoying to use. When composing it's important to forget technology: think music. This was the thought behind my sequencer: ttrk (http://div8.net/ttrk). I did a UI that I'm pretty proud of for the target platform: basically it's an Alesis MMT8 meets a tracker in 80x50 textmode on an old PC, low enough latency to have really smooth drumrolls even at high bpm, and it syncs happily to external MIDI clock (essential for my setup). Of course, since I have a market size of 1 (myself), and pretty much no interest from the open-source community, the project hasn't gone anywhere else. But I'm quite happy with it. :) -- Billy Biggs [EMAIL PROTECTED] http://www.div8.net/billy [EMAIL PROTECTED]
Re: [linux-audio-dev] Poll about linux music audio app usability
On Tue, 11 Jun 2002, Billy Biggs wrote: The same holds for software as well: interface is almost everything. I would much rather have a sequencer with less features and a good UI than a fully-featured one that's annoying to use. When composing it's important to forget technology: think music. I just couldn't agree more! This was the thought behind my sequencer: ttrk (http://div8.net/ttrk). I did a UI that I'm pretty proud of for the target platform: basically it's an Alesis MMT8 meets a tracker in 80x50 textmode on an old PC, low enough latency to have really smooth drumrolls even at high bpm, and it syncs happily to external MIDI clock (essential for my setup). [...] Of course, since I have a market size of 1 (myself), and pretty much no interest from the open-source community, the project hasn't gone anywhere else. But I'm quite happy with it. :) Make that two!! :) ttrk has been one of my favorite audio apps for a while now. Thanks to the well-defined set of functionality and the way it is implemented, there just isn't much to complain about. ;) -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Poll about linux music audio app usability
On Tue, 11 Jun 2002, Kai Vehmanen wrote: Make that two!! :) ttrk has been one of my favorite audio apps for a while now. Thanks to the well-defined set of functionality and the way it is implemented, there just isn't much to complain about. ;) Wow! That means alot to me to hear that, many thanks!! -- Billy Biggs [EMAIL PROTECTED] http://www.div8.net/billy [EMAIL PROTECTED]
Re: [linux-audio-dev] Poll about linux music audio app usability
On Tue, 11 Jun 2002 18:36:33 -0400 (EDT) Billy Biggs [EMAIL PROTECTED] wrote: On Tue, 11 Jun 2002, Kai Vehmanen wrote: Make that two!! :) ttrk has been one of my favorite audio apps for a while now. Thanks to the well-defined set of functionality and the way it is implemented, there just isn't much to complain about. ;) Wow! That means alot to me to hear that, many thanks!! I would have helped you with it if i had known about it before finsihing shaketracker, if that helps ;) btw, have you worked anymore on it? Juan Linietsky
Re: [linux-audio-dev] Poll about linux music audio app usability
On Tue, Jun 11, 2002 at 03:48:27AM +0200, David Olofson wrote: Then again, We Have Paul! :-) Huh? Wha'd I do? ;-) -- Paul Winkler www.slinkp.com Muppet Labs, where the future is made - today!
Re: [linux-audio-dev] Poll about linux music audio app usability
On Tuesday 11 June 2002 12.29, Alexander Ehlert wrote: That's basically why I think inventing Yet Another, Although Much Cooler Looking GUI Toolkit would be worth the effort, if it could help cutting GUI development time without dropping chrome and/or features. (Whether or not it's possibly is another issue. Guess I'll just have to try it...) Oh no, please not. Not another GUI toolkit... Better waste your time writing some kewl wave editor/display widgets with a good API for qt or gtk. Maybe - but what would be the point? I'm not a supernatural programming genious, and I can't spend 12+ hours a day hacking, so why would my GTK+/Qt/WhateverTk be any more successful than the other sequencer projects? I don't think betting on the same concept *again* sounds like a great idea. It's still seems to be failing, and despite the increasing interest in Linux, I don't see countless hackers coming this way to help. There are a bunch of sequencer projects already, but the complexity of such an application seems to be a major issue, since most of the projects seem to be failing to produce anything like Cubase, Cakewalk or Logic. I've written this kind of code before, and my experience only confirms the 80/20 (or 90/10) rule; nearly *all* development time is spent getting seemingly trivial GUI stuff to work properly. As to toolkits, the most useful widget usually turns out to be the basic canvas, on top of which you implement your own custom widgets. For example, you can't really use a normal toolkit to construct a clip oriented song view. What you do is just implement it from the drawing and blitting level and up, on top of some very basic widget. 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. //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 Mon, 10 Jun 2002, Juan Linietsky wrote: I think this raises some questions.. My feeling is that most people aiming to write music on this OS is expecting to have apps with super easy and intuitive interfaces, where you only go trough displays, knobs, sliders and paintabe areas. Why we dont have apps such as Reason, Reaktor, Sonar, Sound Forge, etc? I dont mean full apps, but at least projects aiming for that kind of thing. We do have very powerful tools, but i have to admit that for most of them we have to learn some script programming. Do we lack good APIs? Alsa MIDI api is the best I have seen for it's kind. Also, sould linux apps really take this windows approach of making huge bloated interfaces with lots of eye candy, or should we try to improve on making our apps intercommunicate between eachother, while still giving some importance to ease of use? What do you think about this issue? Well ... I've been a programmer and mathematician for 40 years -- I started in a time when assembly language, FORTRAN, COBOL and LISP were the only languages available. And I've been interested in computer music since then. All the trapping you speak of came into being since then. So I *personally* work just as well, or maybe a tad better, at a fairly low level, preferring the efficiency of direct contact with the machine and familiar skills. However, most computer musicians are just that -- musicians. They view dealing with computers as a frustration. I know many who have simply given up out of frustration; they use computers, if they use them at all, as score editing tools. Those who have persevered with the steep learning curve expect the usability of their favorite tools and will *not* tolerate anything less. I personally am a composer -- I build tools to make the computer music I want to hear. I don't expect to spend large amounts of time, given that computer music is a hobby and not my business, making tools for other composers. A final word, for those of you who *do* want to make tools for other musicians ... pay little attention to what people *say* and look at what they *do* and what they *buy*. There's a reason there are a lot of tools that only exist on the Mac, for example. -- M. Edward Borasky [EMAIL PROTECTED] http://www.borasky-research.net/HarryIannis.htm How to Stop A Folksinger Cold # 5 Where have all the flowers gone... Beats me.
Re: [linux-audio-dev] Poll about linux music audio app usability
I read: What about jMax and Reactor? I'm not sure what you mean reaktor runs on win and mac and jmax runs on linux,osx,win32,irix but max/msp != jmax and certainly not reaktor supercollider is totally different from all the above hmm.. x -- [EMAIL PROTECTED]Postmodernism is german romanticism with better http://pilot.fm/special effects. (Jeff Keuss / via ctheory.com)
RE: [linux-audio-dev] Poll about linux music audio app usability
In reply to the 'not having the same sound as everybody else', I think this is a question of how you use software and not what you use. You can play a million things/styles etc on a guitar. The same goes for software synths etc. Yes, but guitar still sounds like a guitar (with the exception of the extended performance techniques and guitar preparation), acid loops still sound like acid loops, and DX-7 synth patches still sound like DX-7 patches. Keep in mind that software is not musical style (i.e. rondo vs. waltz vs. rap vs. rock etc.), but that software is an instrument. I am not trying to say that each person's music does not have that grain of individuality but rather that by using more-difficult-to-use software, I am likely to use tools that are less used by others, hence my music has a greater chance to sound unique. Try listening to some of the academic electronic music and see just how different it is from everything else out there. The truth is we will never have all the apps that are available for windows ( unless commercial software becomes a happening thing ). But if we are prudent we can focus on the core type apps and frameworks. I disagree. Time works for us, not against us. Open source apps have the great advantage over the commercial offering in that they can be updated indefinitely by a huge number of developers -- and every time they get updated, they become [mostly] even better. Commercial apps do not have a secure life span and a lot of developers have to reinvent the wheel due to closed-source nature of commercial software. For instance look at opcode's Vision DSP (one of the first versatile pro Midi/Audio Studio solutions), it's dead now since the company is out of business, and all their effort and money spent for it is now completely useless, since app will never have its source code released nor ported into anything beyond OS 9). What we really need in Linux is already happening, and that is a dedicated group of developers working on versatile tools within an open-source framework. Ico
RE: [linux-audio-dev] Poll about linux music audio app usability
I read: What tools are you talking about? I mean, I own both PCs and Macs, and except Digital Performer I don't know about any other major package that only exists on the Mac. max/msp supercollider regards, x Except that max/msp is coming to Win platform this fall (and besides there are better alternatives to this app on Linux/win platforms i.e. Mix24 (or something like that, forgot the name), Eyesweb, Glame, pd, jmax, Visual Orchestra etc.), and Supercollider has gone open source so it should be available on Linux platform (and possibly Win platform as well) rather soon (for alternatives see Rtcmix, Csound etc.). Ico attachment: winmail.dat
Re: [linux-audio-dev] Poll about linux music audio app usability
Hi, something like that, forgot the name), Eyesweb, Glame, pd, jmax, Visual cglame even compiles on MacOSX, the problem is that mmap doesn't work the same way as it does in Linux and so our swapfile backend doesn't work. As richi and I are proud owners of iBooks we might resolve that problem. Another problem is gtk, you could use glame with the XDarwin Xserver, but writing a native GUI, hmm, I don't think so. Maybe we should go commercial for OSX ;-) Cheers, Alex
Re: [linux-audio-dev] Poll about linux music audio app usability
On Monday 10 June 2002 18.52, Alexander Ehlert wrote: Hi, Why we dont have apps such as Reason, Reaktor, Sonar, Sound Forge, etc? I dont mean full apps, but at least projects aiming for that kind of thing. Because only 2% of the linux audio programmers try to make a living of that. I personally dislike GUI programming, programming soundfx is much more interesting and I usually do that for my personal pleasure. And other people can benfit of that work, too. The programs you mentioned cost a lot of money and their programmers work full time on it. And they have to do those nice GUI's if they want to sell it. Free/Open Source hackers also have to sell their work to be truly successful. Nice user interfaces attract users - and around here, many users like to hack their favourite tools if they can. There is a difference, but it's not all that big. Having a shiny metal interface doesn't mean their sound better, anyway. Right, but some users would say that nice GUIs are more inspiring to work with... [...] kind. Also, sould linux apps really take this windows approach of making huge bloated interfaces with lots of eye candy, or should we You just have to find someone who likes GUI programming... ...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. //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 Tuesday 11 June 2002 04.09, Taybin Rutkin wrote: On Tue, 11 Jun 2002, David Olofson wrote: That's basically why I think inventing Yet Another, Although Much Cooler Looking GUI Toolkit would be worth the effort, if it could help cutting GUI development time without dropping chrome and/or features. (Whether or not it's possibly is another issue. Guess I'll just have to try it...) What do you want that can't be done with themes and/or additional widgets? * Visual Construction of new widgets without adding new widgets to the toolkit. Somewhat like building stuff with some of those visual multimedia and game development tools. * Visual GUI building tools, that preferably let you construct a great deal of the logic behing the GUI by simply connecting ports through links with configurable logic or mathematical functions. (Nothing insanely sophisticated, though - one might as well hack real code when it makes sense.) * No themes in the traditional sense. A theme is part of the look'n'feel of the GUI, and allowing users to apply any theme to any GUI puts many restrictions on what you can safely do with graphics resources and widgets. Think VSTGUI rather than GTK+. * An API model that allows multiple clients within the same thread. This taking over the main loop crap is totally banned. * 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.) In short, I want GUI designers to be able to focus on the *design*, rather than arbitrary limitations caused by traditional thinking and obsolete 2D rendering APIs (*). (*) Well, Microsoft, Apple and others are moving towards dropping 2D APIs and drivers entirely, and using the 3D subsystems for *everything*. Makes sense, considering that the majority of video cards in use today are designed primarilly for 3D acceleration. //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 Tuesday 11 June 2002 04.19, Juan Linietsky wrote: That's basically why I think inventing Yet Another, Although Much Cooler Looking GUI Toolkit would be worth the effort, if it could help cutting GUI development time without dropping chrome and/or features. (Whether or not it's possibly is another issue. Guess I'll just have to try it...) Actually, Instead of writing another GUI toolkit i think the best is to write widgets that would go well for audio programs in some existing widget set such as GTK. I think that's just pushing the problem in front of us. When implementing widgets (on top of GDK, for example), you're basically writing very low level graphics rendering code - which few really enjoy, and which takes time to do well. I'd much rather use something more structured and higher level than the rendering backends of traditional toolkits, but lower level than a normal toolkit. One could use it from C or C++, but the point is that it should help with some of the low level *logic* - just not basic rendering on a plain canvas. Primitive objects that can be clickable, draggable, interconnected etc, and have graphics primitives, images and stuff hooked up to them. That is, use the API to *build* the widget, rather than rendering it. Of course, one could strap a scripting language and/or a visual editor onto that, and have something like a multimedia applet authoring tool. (Well, people are using Macromedia Flash and the like to build plugin GUIs, so why not?) We do have very powerful tools, but i have to admit that for most of them we have to learn some script programming. Some people think this is a good thing because the tools are ultimately more capable and less limiting. Others disagree. I'd like both... Fiddle knobs and draw curves until you get the basic sound, and then, if required, unscrew the chrome panels to hack same more complex logic and/or math in. :-) Doesn't make things easier, does it? Personally I'd rather move knobs than trying values. I write my apps usually in the userfriendly way becuse of this. Well, it's just that when you're up to tens of knobs just to describe how velocity affects the vowel of a formant filter, I start feeling stupid. Some things are just much easier to express as code, and I would like to have that tool around when that happens. (Oh, and it's probably easier to build those GUIs with that scripting language in the first place, if you're going to have it around 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
However, forgot to mention, that it would be still nice to see user-friendliness become a standard in Linux ;-) -Original Message- From: Ivica Bukvic [mailto:[EMAIL PROTECTED]] Sent: Monday, June 10, 2002 1:42 AM To: '[EMAIL PROTECTED]' Subject: RE: [linux-audio-dev] Poll about linux music audio app usability What I think is that this is great since there is less likelihood that someone else will be using the same tools I do and hence less likely will my music sound like thousands of others :-) Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ [EMAIL PROTECTED] To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God -Original Message- From: [EMAIL PROTECTED] [mailto:linux-audio-dev- [EMAIL PROTECTED]] On Behalf Of Juan Linietsky Sent: Monday, June 10, 2002 1:10 AM To: [EMAIL PROTECTED]; linux-audio- [EMAIL PROTECTED] Subject: [linux-audio-dev] Poll about linux music audio app usability I thought this may be of interest to the list. In a k5 poll about usability of linux audio apps, ( http://www.kuro5hin.org/poll/1023512126_OSelOkZS ) So far, out of 38 answers the results are: -How do you like music software for Linux? 2 % - Great! It has everything I need. 13 % - Good, but i wish apps were more userfriendly (Like Reaktor or SoundForge) 31 % - Could be better, I think the apps are not yet mature enough for my needs. 15 % - It's unusable, the apps plain suck. 10 % - Dont care about composing on computers 26 % - Dont care about composing. I think this raises some questions.. My feeling is that most people aiming to write music on this OS is expecting to have apps with super easy and intuitive interfaces, where you only go trough displays, knobs, sliders and paintabe areas. Why we dont have apps such as Reason, Reaktor, Sonar, Sound Forge, etc? I dont mean full apps, but at least projects aiming for that kind of thing. We do have very powerful tools, but i have to admit that for most of them we have to learn some script programming. Do we lack good APIs? Alsa MIDI api is the best I have seen for it's kind. Also, sould linux apps really take this windows approach of making huge bloated interfaces with lots of eye candy, or should we try to improve on making our apps intercommunicate between eachother, while still giving some importance to ease of use? What do you think about this issue? Juan Linietsky
