Re: [LAD] Guide to Linux Sound APIs
On Sat, Sep 27, 2008 at 6:14 AM, victor [EMAIL PROTECTED] wrote: There is also pulseaudio, which is quite simple to program and use in simple apps. What's the percentage of linux systems which have pulse audio ? I know I don't on my system, and it is a very popular one (ubuntu). cheers, David ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Guide to Linux Sound APIs
On Sun, Sep 28, 2008 at 4:36 PM, David Cournapeau [EMAIL PROTECTED] wrote: What's the percentage of linux systems which have pulse audio ? I know I don't on my system, and it is a very popular one (ubuntu). It's the default sound server in Ubuntu 8.04. Pretty sure it'd be the default in Fedora, I think the o/p works for redhat. Ubuntu + Fedora would make up a decent percentage of new linux installations. - Steve ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Guide to Linux Sound APIs
On Sun, Sep 28, 2008 at 3:52 PM, Steve Lindsay [EMAIL PROTECTED] wrote: Ubuntu + Fedora would make up a decent percentage of new linux installations. Yes, but Ubuntu + Fedora Ubuntu 8.04 + Fedora 9. Also, I guess it depends on how you upgrade, because my workstation is 8.04, which is upgraded every year or so for 2 years and a half now, and I don't have pulseaudio. One of the package I want to add sound support for is for science mostly, and many people are still using Ubuntu Dapper, Fedora 3, etc... So it does not look like pulseaudio is that great if you want to support various linux and have very little needs for audio. cheers, David ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Guide to Linux Sound APIs
On Sun, 2008-09-28 at 16:04 +0900, David Cournapeau wrote: On Sun, Sep 28, 2008 at 3:52 PM, Steve Lindsay [EMAIL PROTECTED] wrote: Ubuntu + Fedora would make up a decent percentage of new linux installations. Yes, but Ubuntu + Fedora Ubuntu 8.04 + Fedora 9. Also, I guess it depends on how you upgrade, because my workstation is 8.04, which is upgraded every year or so for 2 years and a half now, and I don't have pulseaudio. One of the package I wan't to add sound support for is for science mostly, and many people are still using Ubuntu Dapper, Fedora 3, etc... So it does not look like pulseaudio is that great if you want to support various linux and have very little needs for audio. As Lennart tried to make reasonably clear, the primary goal of PulseAudio is NOT to act as a new API, but to act as a new *infrastructure* that supports existing APIs transparently. I am sure that he would be happy if it eventually takes over the world and everybody writes apps using its API, but that doesn't appear to be the goal right now. --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Guide to Linux Sound APIs
However, doing so (writing apps using his API) is dead easy. Victor - Original Message - From: Paul Davis [EMAIL PROTECTED] To: David Cournapeau [EMAIL PROTECTED] Cc: Linux-audio-dev@lists.linuxaudio.org Sent: Sunday, September 28, 2008 8:38 AM Subject: Re: [LAD] Guide to Linux Sound APIs On Sun, 2008-09-28 at 16:04 +0900, David Cournapeau wrote: On Sun, Sep 28, 2008 at 3:52 PM, Steve Lindsay [EMAIL PROTECTED] wrote: Ubuntu + Fedora would make up a decent percentage of new linux installations. Yes, but Ubuntu + Fedora Ubuntu 8.04 + Fedora 9. Also, I guess it depends on how you upgrade, because my workstation is 8.04, which is upgraded every year or so for 2 years and a half now, and I don't have pulseaudio. One of the package I wan't to add sound support for is for science mostly, and many people are still using Ubuntu Dapper, Fedora 3, etc... So it does not look like pulseaudio is that great if you want to support various linux and have very little needs for audio. As Lennart tried to make reasonably clear, the primary goal of PulseAudio is NOT to act as a new API, but to act as a new *infrastructure* that supports existing APIs transparently. I am sure that he would be happy if it eventually takes over the world and everybody writes apps using its API, but that doesn't appear to be the goal right now. --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Guide to Linux Sound APIs
On Sun, Sep 28, 2008 at 4:38 PM, Paul Davis [EMAIL PROTECTED] wrote: On Sun, 2008-09-28 at 16:04 +0900, David Cournapeau wrote: So it does not look like pulseaudio is that great if you want to support various linux and have very little needs for audio. As Lennart tried to make reasonably clear, the primary goal of PulseAudio is NOT to act as a new API, but to act as a new *infrastructure* that supports existing APIs transparently. I got that, but you missed the context of the discussion: both victor and me were talking about the API. Victor mentioned pulseaudio API as an easy one, and I expressed my concern about availability of pulseaudio in my case (extremely limited audio needs, but available on many distributions, potentially quite old). cheers, David ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Paul Davis wrote: i ran into quite a lot of really significant problems which could only be solved using google-fu As is natural. I have no problem with this and did a great deal of it myself. When I say the information wasn't mentioned anywhere, I mean *anywhere*. I suspect that, because of the minimal take-up of DSSI, both in host and plugin terms, I was the one of the first people to unearth it, as I was among the first to try doing what is a fairly standard operation in the Windows / Apple worlds and noticing that one host didn't behave as expected. Having scoured the web and especially rosegarden's own site both before and after finding the issue, the only thing Rosegarden's docs have to say is expressing full support for DSSI. If nothing else -- and part of the reason for doing this -- this series of posts will provide some google feedback for any people who hit the issue in future. i am really not taking you to task for your observations on DSSI - from what you've written it really does sound like a bit of mess in this repsect, and quite possibly LV2 as well. but .. i am not entirely clear why you've approached the problem in the way you have. I claimed an implementation issue was intimately bound up with a problem inherent to certain specifications, then backed it up with facts when you called me on it. Perhaps my tone was overly irritated, and for that I apologise. To the general conversation ... As regards the merits or not of writing an instrument as a plugin, that's been addressed by some other respondents. The fact is that an instrument does *not* need OS-levels of interaction; it needs timing and midi data and output audio buffers, and optionally some facility for providing a GUI -- that's about it. Implementing it as a plugin allows the instrument to take advantage of a host's facilities. For example, a non-trivial synth or sampler can use the host's ability to host effects plugins; otherwise, the instrument has to host them itself, thus also having to provide an effects GUI generator. A second reason is that the plugin host can behave as an input mediator / sequencer for the plugin. A third reason is that, by developing an instrument as a plugin, the developer can *also* develop a stub host, thus allowing the instrument to run either as a plugin or as a standalone app, which is what NI have done with a lot of their instruments. Doing it *solely* as a standalone app means you're stuck with that model forever. Fourthly, as mentioned, there's session state saving. There's a reason that ReWire (*loosely* a jack equivalent) slowly became deprecated in favour of VSTIs on Windows. The prevalence of using the OS in the linux world is more to do with with the disparate and divided state of DAWs, host support for instruments, and the (quite wonderful) state of jack than it is to do with it being inherently the best solution. Everyone writes to jack (or ALSA) because they know it's a common denominator that's guaranteed to work well (as well as the fact that jack's architecture can replicate host provision to an extent) not because it's necessarily the best model for doing it a priori. As to session state saving, it's not something that *personally* concerns me all that much, provided each component allows the facility for saving its own configuration. Paul's right, though; it really is a big deal on the other OSs. Users are used to saving their project in their DAW of choice and having the DAW remember it, rather than them having to be responsible for saving each piece individually. DSSI provided some capability for this with the 'configure' function / OSC call. It gave the host some handle on how to reconfigure the instrument in question when loading a project. LV2 doesn't even do that from what I can see. Chris Williams ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Chris Williams wrote: There's a reason that ReWire (*loosely* a jack equivalent) slowly became deprecated in favour of VSTIs on Windows. Propellerheads won't even give you the time of day unless you're a registered for-profit corporation with a real product. Even then, they give trouble. Justin Frankel (the Reaper guy) had to argue with them, and he has a registered for-profit corporation with a real product! It will continue to be tolerated, though, as long as Reason remains a popular tool for music, and it *is* quite popular. THAT's why ReWire is dying off more than anything, assuming it is. Steinberg at least made VST an open standard (notice the flame-war-avoiding quotes there), allowing anyone to be able to develop plug-ins, even if they're free. No, it's not compatible with the GPL, but that's off-topic for this conversation, I think. As to session state saving, it's not something that *personally* concerns me all that much, provided each component allows the facility for saving its own configuration. Paul's right, though; it really is a big deal on the other OSs. Users are used to saving their project in their DAW of choice and having the DAW remember it, rather than them having to be responsible for saving each piece individually. DSSI provided some capability for this with the 'configure' function / OSC call. It gave the host some handle on how to reconfigure the instrument in question when loading a project. LV2 doesn't even do that from what I can see. My understanding with LV2 is that all communications between the GUI (whether included with the plug-in or generated by the host) flow through the host, and can be captured, analyzed, serialized by the host on the fly. Someone please correct me if I'm wrong on that. I would think that that means the host definitely *can* bring up an LV2 plug-in with state information quite intact. I don't have any knowledge of how difficult it is to do any of this, though. I'm only book smart on the issue. -- Darren ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Paul Davis wrote: It might suprise you that I probably agree with this point even more than you do :) JACK exists primarily because there was not a suitable plugin API on linux and because several of us felt it unlikely that there ever would be one. The biggest obstacle of all was the still-unsolved issue of GUI toolkit compatibility. Its remarkable and cool that JACK works as well as it does, and the isolation it provides between processes can be handy. But yeah, if we had had a single GUI toolkit and a decent plugin API ... no JACK would have emerged, probably. Wasn't JACK based at least loosely upon the same concepts as CoreAudio? I seem to remember something about that some time ago. Myself, I'm watching and participating quite eagerly in this conversation, because I would like to write a plug-in or two (or three) and I still don't know what API (JACK, LV2, etc.) I want to focus my energy on. Chances are, I'll be able to choose only one. -- Darren ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Something like Processing for audio
Hallo, Darren Landrum hat gesagt: // Darren Landrum wrote: Why couldn't we make something like that for audio? It would most likely be C++ rather than Java, but the idea of building up DSP networks using a large framework of code, plus some pre-defined functions and settings, and being able to launch our new code with a one-touch button into a JACK client (or whatever), is extremely appealing to me. Faust, CLAM, SuperCollider, Lua-AV, Common Lisp Music, CSound, (Pd) .. take your pick. Ciao -- Frank ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Something like Processing for audio
On Sun, Sep 28, 2008 at 6:20 PM, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, Darren Landrum hat gesagt: // Darren Landrum wrote: Why couldn't we make something like that for audio? It would most likely be C++ rather than Java, but the idea of building up DSP networks using a large framework of code, plus some pre-defined functions and settings, and being able to launch our new code with a one-touch button into a JACK client (or whatever), is extremely appealing to me. Faust, CLAM, SuperCollider, Lua-AV, Common Lisp Music, CSound, (Pd) .. take your pick. And ChucK (http://chuck.cs.princeton.edu/). It also has its editor. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
This isn't entirely addressed to Paul; I've just used his comments as a jumping point. Paul Davis wrote: Chris Williams wrote: As regards the merits or not of writing an instrument as a plugin, that's been addressed by some other respondents. The fact is that an instrument does *not* need OS-levels of interaction; it needs timing and midi data and output audio buffers, and optionally some facility for providing a GUI -- that's about it. You're thinking small :) File I/O, network interaction, interactions with different sorts of input devices ... there's more. Point taken, but there's nothing inherently non-plugin about doing this. There are plugin architectures in dozens of other application areas that do these things. Add file I/O to my original list and you've covered a very large chunk of use cases (but not all, I concede). JACK exists primarily because there was not a suitable plugin API on linux and because several of us felt it unlikely that there ever would be one. I think this is partly where my issues stem from. Nothing will ensure this happens faster than a half-dozen bad specs. LADSPA was good in the sense that it was brief, tightly defined, *relatively* simple to implement from the host side (provided the host-supplied GUI generator was up to scratch); *very* simple to implement from the plugin side. I've spent some of today reading LV2 in more detail. I'm honestly not sure what to make of it at this point. My first reaction was that it's attempting to solve certain problems by introducing worse ones, but I haven't thought it through fully yet. The biggest obstacle of all was the still-unsolved issue of GUI toolkit compatibility. LADSPA tried to cope with the GUI issue largely by handing it off to the host. This facilitates a large set of effects and a smaller set of instruments but by no means all. LV2 seeks to solve this via the extension mechanism. This is one of the areas I'm really not happy about, especially the current (admittedly tentative) extension mandating not only a gui toolkit (gtk), but also the idea that the plugin should implement the Widget interface while the host should already be running the gtk main loop. Ouch. The problem with the extensibility argument is that no host is going to implement it fully, properly or consistently (as mentioned, it's hard enough for this to happen with a tightly-defined, compact spec) which leaves client developers still not knowing what they are dealing with. DSSI, IMO, *attempted* to get this right. Implicit in the DSSI spec is an acknowledgment that a plugin spec can't be in the business of mandating gui solutions on a platform with many to choose from, so they tried to find a way around it using a remote gui which communicates with the host via OSC. I'm not sure this is entirely correct, either, but it's at least more right than several other ways of doing it (*cough* LV2), especially the central idea of trying to abstract the gui away from the architecture. Incidentally, the idea that this is necessarily easier on other platforms with a single widget set is, at best, only half-true. I was intimately involved for a few years with the development of three products at a company with modest fame in this area. What the Windows developers overwhelmingly tend to do (I spoke with devs at other outfits that did this too) is use the native windowing system to get a Frame and a graphics context -- nothing else. They then end up drawing directly on the graphics context manually (thus effectively developing their own gui-toolkit-lite). This frees them (to an extent) from issues involving implementing their plugins in other OSs, as you can generally always get at least a Frame and a GC, and any differences in coordinate systems can be overcome with a trivial spacial translation. Chris Williams ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Something like Processing for audio
On Sun, 2008-09-28 at 15:30 -0400, Darren Landrum wrote: I want my musical skills to be all I need to be able to make music on Linux. I want my musical skills to be all I need to be able to make music on Cello. It doesn't seem to be working out too well, so far :) To be honest, this is not an avenue that interests me individually. I view these tools as a lot like table saws, routers and jointers: things with immense power that make a lot of tasks way faster and simpler than they would otherwise be, but that do not remove the obligation to develop a set of tool-specific skills. I've never had much interest in designing table saws for people who don't want to know how to use table saws, and I personally don't have a lot of interest in designing software tools for people who don't want to learn how to use them. I do see the attraction, however. And also the marketability. I also promise to discuss this issue in my seminar at the Technical University here in Berlin, Designing Tools for Musicians. --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Something like Processing for audio
On Sun, Sep 28, 2008 at 3:30 PM, Darren Landrum [EMAIL PROTECTED] wrote: I thought I was clear on this, but I'll restate: We need this so that people who are not skilled coders, but have other skills, in math and physics and electronics perhaps, can bring their skills to bear in making synths and effects while making the coding side as painless as possible. The end result will hopefully be synths and effects usable by *musicians* and not just other coders. Click and play, as it were. It sounds like you either want FAUST, which is a good way to basically write down mathematics since it is a functional language, and generates plugins. Or you want a MATLAB/Octave compiler of some kind. That would certainly be cool. Obviously you don't see what you need in the tools that are available but I think you're having a hard time describing exactly what that is. Languages like CSound, ChucK and SuperCollider really do allow you to do a lot of things. On-the-fly programming, per-sample control of audio, simplified languages specifically targeted to audio. Can you describe exactly what it is these cannot do? Otherwise you can always write a plugin for any of these in C. I want my musical skills to be all I need to be able to make music on Linux. Well, making music on computers has always required a certain amount of technical ability. But there are many paradigms for music-oriented human-computer interaction: the DAW, the special-purpose programming language, the sequencer, the MIDI synth, the input-output effect processing, the artificial intelligence automatic accompaniement, the score follower, the notation generator. All of these are possible in one way or another on Linux. You haven't explained better what you mean by musical skills and make music on Linux, so it's hard to answer you more exactly. That the international community persists in using VSTs and FruityLoops and Cubase and Logic Audio, I have no idea. Probably the interfaces are just more simple (definitely not true for Logic Audio), and the availability of (often pirated) VST synths makes things attractive. Probably marketing also plays a large roll in this. Granted certain programs like Ableton Live or Serato have few counter-parts on Linux. Perhaps it's because programming O-S software is often oriented towards scratching an itch. The cross-section people who are both coders and musicians isn't all that large, so only some of the large set of possible itches will ever get scratched. Steve ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Something like Processing for audio
Paul Davis wrote: To be honest, this is not an avenue that interests me individually. I view these tools as a lot like table saws, routers and jointers: things with immense power that make a lot of tasks way faster and simpler than they would otherwise be, but that do not remove the obligation to develop a set of tool-specific skills. I've never had much interest in designing table saws for people who don't want to know how to use table saws, and I personally don't have a lot of interest in designing software tools for people who don't want to learn how to use them. Who said anything about not wanting to learn how to use table saws? This seems a bad analogy to me. NI's plug-ins don't make me a better musician. I still have to learn how to use them, but I don't have to know how to code them myself first. That part's already done. I'm more than willing to learn how to use a table saw, but I really don't feel like building my own table saw first. Right now, audio on Linux really does kinda force the latter, in my opinion. I'm genuinely enjoying myself debating this, though. :-) -- Darren Landrum ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Something like Processing for audio
On Sunday 28 September 2008, Darren Landrum wrote: Why couldn't we make something like that for audio? It would most likely be C++ rather than Java, but the idea of building up DSP networks using a large framework of code, plus some pre-defined functions and settings, and being able to launch our new code with a one-touch button into a JACK client (or whatever), is extremely appealing to me. Throw in some GUI-building elements (Cairo-based, perhaps) that can handle mouse-clicks, keyboard input, and the like, then suddenly people who are good at math and DSP but not so good at coding might have a shot at making some great programs. It is in no way finished, but it's a similar idea: http://tapas.affenbande.org/wordpress/?page_id=91 The webpage says: ProcessPP is the realisation of a rather silly idea: A livecoding environment for C++. As its author i can truly admit that this is a wrong statement (i should fix it). It is not yet the realisation, but it's an attempt in this direction in its earliest stages. So nothing is decided really yet.. What it is right now is basically this: - Hack some code for a process() function for a jack client. - Hit Run - Hear noise.. You can have several of these functions.. I was planning next to integrate some midi. So you can write a process_voice function that is called whenever a note needs to be played. I'm not totally sure yet on how to do this though that a] it's flexible b] it's still easy :) I just wanted to mention it... Even as unfinished as it is.. :) Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Something like Processing for audio
On Sun, Sep 28, 2008 at 03:30:52PM -0400, Darren Landrum wrote: What we need is a nice and powerful back-end that is wrapped in an easy-to-learn front end. The best of both worlds, if it's possible. [Paul D.] Why do we need this? I thought I was clear on this, but I'll restate: We need this so that people who are not skilled coders, but have other skills, in math and physics and electronics perhaps, can bring their skills to bear in making synths and effects while making the coding side as painless as possible. There is a whole world of difference to - coding a DSP algo that works given a context that feeds it one or more sample streams and absorbs one or more output streams, and - making a module that basically just performs that algo but in a context of making music with it - e.g. something that can be instantiated and deleted in real time, that control signals, reacts to asynchronous events, has well defined timing, etc. etc. Given the right framework, for the first you only need to understand the algo. The second requires another level of understanding, which can be a lot more complex than the DSP side, and may require some coding skills in one form or another. One of the qualities of tools like Supercollider and Csound is that they manage to even make the second step managable to people who are not real coders. They do that by providing an infrastructure that is a lot more complex than the one to support just DSP algos, but you are required to learn how that works, at least on a functional level. The end result will hopefully be synths and effects usable by *musicians* and not just other coders. Why would a synth or effect produced by a math or DSP expert be any more 'usable' than one made by a 'coder' ? I'd expect the DSP to be better - but there it ends. A 'coder' has in fact a much better chance of making something usable than someone who only knows the math and DSP side of things. I want my musical skills to be all I need to be able to make music on Linux. Why do you expect making music on computers to be easy ? Normally, to make music, you need not only the skills you refer to above, but also those to play an instrument. For traditional instruments that takes years of hard work. What makes you think it should somehow be easy or automatic when using a computer ? Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Something like Processing for audio
On Sun, 2008-09-28 at 22:58 +0200, Fons Adriaensen wrote: What makes you think it should somehow be easy or automatic when using a computer ? because a demo by an awesomely cool dude from insert audio tech company name here showed me that it could be? next question? :) --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Something like Processing for audio
On Sun, Sep 28, 2008 at 11:32:41PM +0200, Paul Davis wrote: Actually, I'm not sure I see much benefit when people get to use computers, period. :-) This is like the explosion of desktop publishing when everybody and their buddy thought they understood typography, typesetting and graphic design. Last week we had some festivities here and people had to be invited. My boss (windows user) worked for most of the day on the invitation and still wasn't satisfied with the result. He came to me with a printed version and said This looks ugly (he was right). When you make a stupid slide with four lines of text for your presentations it looks good. Can you redo this ? And of course I did - ten minutes work using Latex. Now is there a relation between the fact that Latex is a 'hard to use' old style, non-wysiwyg tool and the fact that it produces much better typesetting than MS word ? I think there is - even if it may not be simple to exactly find out why. the thing is that about 40 years ago, the first modular synths started to appear, and people complained about them in exactly the same way that people complain about supercollider now. then came the minimoog, which begat the polymoog and then the prophet 5 and the the DX7 and so forth, until we got synths that nobody had to know anything whatsoever about synthesis in order to use. and now things have settled down, and there is some space for the contemporary equivalents of the DX7, but there is also understanding of the quintessential values of the modular synth too. and you're talking to a bunch of people who would probably be happy building modular synths, let alone actually using them. Plus the simple observation that once we had the synths that nobody needed to understand whatsoever about, most synth music, with few exceptions, degraded to junk food quality levels. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Something like Processing for audio
Do you mean something like SynthEdit for VST ? I've never worked with it but understood it were a kind of plug'n-drag your own synth, without coding skills. Some comparable apps exist: Ingen, Alsa Modular Synth, Clam, GAlan, any more ?? If you want to code but have it easy, there is no all-in-one solution, because that would restrict developers, (I know, sometimes it's nice to have no choice ;) But there are same parts that can be combined to simplify plugin development: gui-creation: gkt: http://phat.berlios.de/ juce http://www.rawmaterialsoftware.com/juce/ tools to make tools: http://linux-sound.org/tools.html Another hint for simple coding: The SndObj Library:: http://music.nuim.ie//musictec/SndObj/main.html Good luck with all this, Emanuel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Something like Processing for audio
Fons Adriaensen wrote: Plus the simple observation that once we had the synths that nobody needed to understand whatsoever about, most synth music, with few exceptions, degraded to junk food quality levels. Being good at using a modular synth still didn't require knowing how to design and solder circuit boards along with understanding the quantum mechanics of how electrons travel through a semiconductor. Making music by coding one's own software synths *is* a lot like that, though. I seriously doubt Paganini ever felt he needed to make his own violin in order to be a better musician. I'm not trying to fob this off onto someone else. I would actually like to start this project myself, even though I'm a lousy coder and my code will probably look horrible. At this point, though, I fail to see the point, as it appears I would be completely on my own, and nobody would care what I come up with. So, I may as well stick to just doing whatever I can on my own, make my music, and stop caring about how, or whether anyone else would care how. You've already basically accused me of not being able to play just because I want to use software synthesis. -- Darren ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Chris Williams [EMAIL PROTECTED] writes: Paul Davis wrote: The biggest obstacle of all was the still-unsolved issue of GUI toolkit compatibility. [snip] LV2 seeks to solve this via the extension mechanism. This is one of the areas I'm really not happy about, especially the current (admittedly tentative) extension mandating not only a gui toolkit (gtk), but also the idea that the plugin should implement the Widget interface while the host should already be running the gtk main loop. Ouch. The problem with the extensibility argument is that no host is going to implement it fully, properly or consistently (as mentioned, it's hard enough for this to happen with a tightly-defined, compact spec) which leaves client developers still not knowing what they are dealing with. DSSI, IMO, *attempted* to get this right. Implicit in the DSSI spec is an acknowledgment that a plugin spec can't be in the business of mandating gui solutions on a platform with many to choose from, so they tried to find a way around it using a remote gui which communicates with the host via OSC. I'm not sure this is entirely correct, either, but it's at least more right than several other ways of doing it (*cough* LV2), especially the central idea of trying to abstract the gui away from the architecture. AFAIK it is perfectly possible to implement LV2 UI extension that handles GUIs in DSSI way, i.e. through OSC. This is probably the best approach if plugin author wants single custom GUI that works for most hosts. The fact that only GTK variant is defined, is caused by the fact that all currently involved parties tend to like GTK and use it in their hosts/plugins. I'm one of them, but I like generated UI's more, one of the reasons I've started dynparam extension work some time ago. So, if one wants custom GUI, options are: * Write one GUI per toolkit * Write single out-of-process GUI and route it through OSC, DSSI-like, or some other IPC mechanism. * Use low level X protocol, if possible at all - see Fons Adriaensen's followup mail. If you want single GUI that could work in any host, the additional option is generating it through some UI description mechanism, with dynparams extension being one that I use. As a side note, I think Lars Luthman made some time ago a research into hosting QT plugins in GTK host or vice versa, but I'm not sure what the result was. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp4jziPtKu5J.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Something like Processing for audio
Sorry for starting this entire argument. I'm just tired of getting nowhere with all of the same tools that everyone else seems to have no problem with. I have a very bad habit of putting myself under a great deal of pressure to exceed everyone's expectations of me. Look, I know that everything I'm asking for exists on the Linux platform. The problem is, it doesn't all exist in one place, or under a single language. I'm convinced at this point that starting over from scratch with a solid design is preferable to trying to use several disparate tools and somehow glue them all together. I've already played around with code here and there to try out some different approaches to this problem, but nothing that I've bothered keeping around. Starting tonight, I'm going to draft a very detailed design, create a code hosting account somewhere (probably Google Code), and get started. I will keep the list apprised of any progress with regular emails. It's been pointed out to me that many people on the list seem to think that I'm trying to get someone else to code this for me. That is not and never was my intention, and I apologize for any miscommunication on my part for that. I am a very slow and not very good coder, though, and it might take a little while to see any progress. First things first, though. A solid design. -- Darren ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
