Re: [LAD] Something like Processing for audio
Sorry I've been away. I've been catching up on homework and trying to put a preliminary design together. I should probably let this thread die, but no doubt this subject will just come up again anyway. Frank Barknecht wrote: _From my experience with giving some workshops in this area I believe that a growing number of artists is looking for software that allows them to build their own specific tools. They are not frightend to learn certain algorithms and how to deal with technical issues as long as these issues are art related. They actually like thinking about things like DSP algorithms for sound and video, but they don't want to think about device drivers and freeing memory (too much). I think this gets to the heart of the matter quite nicely. The goal is a system where the programming is focused on the processing and the synthesis, but a language that actually compiles to standalone applications. Though I'm not aiming for it to be cross-platform (I don't have the tools on any other platforms), I don't see why it couldn't be made so. At this point, I want to lay out the complete design, then decide what I want to finish for the 0.1 release and get to work on it. -- 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
[[sorry darren, this was meant for the list. i hit the wrong button..]] On Mon, Sep 29, 2008 at 1:38 PM, AlgoMantra [EMAIL PROTECTED] wrote: 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 have exactly the same crib. I could not have said it better, and I am convinced that this is a pressing issue. Let me list out the languages I set out to learn in sequence, and finally where I stand. Python - PureData - CSound - Chuck - Processing (after this I shifted to Ubuntu from XP and found the kind of freedom I wanted) - C/C++ (fullstop) ----.- 1/f ))) --. ---... http://www.algomantra.com I'm not your personal army. I'm MY personal army. ___ 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
I want my musical skills to be all I need to be able to make music on Linux. I feel that knowing how to compute on Linux IS a musical skill these days. ----.- 1/f ))) --. ---... http://www.algomantra.com I'm not your personal army. I'm MY personal army. ___ 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: Frank Barknecht wrote: Faust can, but: Is it really important? And why would it be important (taking aside speed issues)? Speed is a large part of it, yes. Another reason to stick to C++ is for things that need the speed and low-level abilities, like on-demand sample streaming from disk for making a sampler. It's a give and take. For some convenience I'll happily give away some speed. OTOH there are areas where speed matters, those areas should be optimized (and thus probably be coded in C/C++). The environments I mentioned can be extended with C in these critical areas. Anyway speed definitly is not what made Processing popular. The core objects in Pd are all coded in C. And generally they are quite fast. Connecting these objects adds a bit of overhead (function calls etc.), but even that is quite fast in Pd. The latest versions of Pd now work on 64-bit systems as well. Pd-vanilla can (and I do have it working), but Pd-extended still cannot. Pd-extended is shipped with an old version of Pd. If you skip the compilation part, Pd (or the other environments I mentioned, Pd is just one example) can do all that. Just bundle the Pd binary and a sh-script with your Pd application to distribute it, if you want. (I would prefer an unbundled download as I already have Pd.) Does Pd do oversampling? I seem to recall it can. Yes, you do that with the [block~] object in a subpatch. I keep bringing this up because several of the things I want to work on, namely lumped modeling/wave digital filters and non-linear processing, both require oversampling to work right, largely to avoid frequency warping and aliasing issues. One thing with Pd is that it is a block-based realtime system, so some of the techniques you mentioned (i.e. those that involve feedback delay lines) can be impossible to implement in Pd using only the builtin objects (feedback delay lines always have a minimal delay time of one block in Pd). But you can code these objects as C-externals or with Faust for Pd. A Processing-alike for audio can also integrate and abstract away things like LASH support, MIDI, and OSC. Something like LASH (session state saving, see the other current thread) is an important capability in my world. Point taken: Session management is an area where Pd isn't especially good. OTOH C++ out of the box isn't either. ;) Ciao -- Frank Barknecht _ __footils.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
2008/9/29 Darren Landrum [EMAIL PROTECTED]: 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 I don't know if it is relevant to this discussion (at least in an acceptable amount of time) but I just wanted you to know about my attempt: NASPRO (http://naspro.atheme.org). I hope people here don't take this message as spamming, because it simply is not. The ideas here are: * to make different existing and not-yet-existing sound processing technology interoperate, both general-purpose sound processing stuff (for example plugins a la LADSPA, LV2, etc.) and special purpose stuff (for example check this: http://naspro.atheme.org/content/ndf-01-file-format-overview), in both compiled and interpreted forms. * be techonlogy neutral (support for each technology implemented in external modules). * define distinct layers, each dealing with a specific aspect of the whole problem (one for sound processing, one for GUIs, one for session handling, etc.), so that a DSP coder can only work on the DSP part and have all the rest automagically implemented and working (for example, you write a LADSPA plugin or write an NDF file and you get an automatically generated GUI without writing one more line of code); * have back bridges when possible, so that applications with support for one of NASPRO-supported technologies gets support for all other technologies without writing a single line of code. * build dead-easy-to-use tools on top of that to make it easy for non demaning applications to support DSP stuff. * build tools on top of that to do data routing among each sound processing component (in other words, chain-like and/or graph-like processing) - plus, since we have those back bridges, you could also use, for example, CLAM networks (as soon as CLAM will be supported) as an alternative to these tools and have the same degree of supported technology (the same goes for gstreamer, Pd, etc). * be cross-platform (apart from Mac/Windows, alternative desktop-oriented OSes like Haiku or Syllable are getting stronger these days and could become viable to do sound processing in some near or distant future). The result will hopefully be to make it also easier to develop new technologies AND without breaking interoperability. Now, since I'm only one, and I am the only one working on this, it will take an insane amount of time probably, and getting each of these abstraction layers right is astonishingly difficult already (anyone remembering GMPI?) - at the moment I'm fighting with core level stuff and I will be doing that at least for another year or two. If you can wait, I will probably have a talk about NASPRO by the end of October and will put down some slides trying to describe the inner working of it (a lot of people complained that I wasn't clear enough on the website)... Maybe this helps :-\ Stefano ___ 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
Frank Barknecht wrote: One thing with Pd is that it is a block-based realtime system, so some of the techniques you mentioned (i.e. those that involve feedback delay lines) can be impossible to implement in Pd using only the builtin objects (feedback delay lines always have a minimal delay time of one block in Pd). But you can code these objects as C-externals or with Faust for Pd. Yes, I was wrestling with this logic back when my idea was to make a Reaktor-alike for Linux. Reaktor handles this, I think, by having a separate core layer that works sample by sample. In other words, when you're using the Core objects, you're operating at the sample level, and then when you use the objects you've made with Core, you're at the block level. That's probably not a bad way to do it. I think I may have figured out some logic to implement something like a single-sample delay as a block object. That's one of the things I wanted to play around with. There's also the possibility of playing around with templating, where an object can process a vector's worth of data or a single sample, depending on how it's called. I've been thinking about the front-end, ie, the editor with the single-button build and run system to make a pseudo-live-coding environment for C++. Since nothing to do with this front-end will ever make it into a JACK application and/or plug-in made with this system, I'm thinking I could implement the front-end with Python instead of C++ and save myself a lot of headache. Right now, though, I'm agonizing over a physics class lab assignment due today that I can't figure out, and running on 3 hours of sleep as a result. -- 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
On Sunday 28 September 2008 17:19:53 Darren Landrum wrote: Fons Adriaensen wrote: 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 ? What the heck?! When I said musical skills, that is *EXACTLY* what I meant! By musical skills, I mean the skills of being able to play an instrument or two, knowing music theory, harmony, singing, and whatever else that really has little to do with computers. If you want to use digital audio well (which is what computers can help you to do), you need to understand digital audio. If the computer (or maybe rather computation) becomes your instrument of choice to make music, you have to understand how it works. That takes learning too. I think you have to start seeing computation as another instrument to make music, and then you'll understand it takes time to develop skill at it. The point is, back when I messed with this stuff on Windows, it was amazingly easy for me to bring up a DAW, load a softsynth into it, and start laying things down on the keys. So far, my experience with Linux audio has been a lot less satisfying. I don't know... it has become fairly easy over the last few years to install an audio targeted Linux distribution and fire up a DAW, fire up some soft synths, connect them through JACK and start playing around. How does this not work for you? Reading your arguments in the threads of this discussion, you seem to want two opposite things, which is confusing I find. I think you'd do well, trying out a bunch of different programs that get close to what you are looking for, and then maybe look if there is a possibility to extend them to what you want to have. Starting something from scratch, will get you on a long development path, on which all these other programs have already been... So unless you have a really radically different new approach to audio DSP programming environments, please start designing something new... but to know whether your idea is really radically new, you have to look in depth at the existing ideas... sincerely, Marije ___ 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
2008/9/29 nescivi [EMAIL PROTECTED]: If the computer (or maybe rather computation) becomes your instrument of choice to make music, you have to understand how it works. That takes learning too. The question here is: what to learn? I would not expect a musican to learn programming in order to record audio nor a synth-sound developer to learn dsp coding technics. There are different layers of complexity and approaches and maybe Darren is right, that the complexity is not enough hidden, I mean in the background of the task to accomplish, in linux, so that easier tasks can soon become confusing, or flood the banks, by introducing different technics and requiring in-depth knowledge. For example: If I wanted to write a synth plugin, I would not expect in the first place, to worry about things as realtime privilegs, threads, realtime memory allocation, server-client handling communication, double-buffering, image-rendering etc... Unless I wanted to do something completely new, I would hope, to have predefined known working solutions for most of these requirements. To have them simplified as much as possible by a host application, because otherwise everyone would have to think about it again and again... instead, I'd prefere to concentrate on the actual task. Maybe LV2 etc. have not gone far enough, in this sence. My 2 €-Cent, 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
On Mon, 2008-09-29 at 18:22 +0200, Emanuel Rumpf wrote: For example: If I wanted to write a synth plugin, I would not expect in the first place, to worry about things as realtime privilegs, threads, realtime memory allocation, server-client handling communication, double-buffering, image-rendering etc... yet thousands of VST plugins have been written where people had to worry about precisely these issues, and a veritable industry has grown up around it. does VST address darren's desires? no, it doesn't. but keep in mind that as time keeps ticking by, what used to be entirely acceptable barriers to entry turn into problems that people want to solve. --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
Hallo, Emanuel Rumpf hat gesagt: // Emanuel Rumpf wrote: 2008/9/29 nescivi [EMAIL PROTECTED]: If the computer (or maybe rather computation) becomes your instrument of choice to make music, you have to understand how it works. That takes learning too. The question here is: what to learn? I would not expect a musican to learn programming in order to record audio nor a synth-sound developer to learn dsp coding technics. If we're talking about a Processing for audio, then programming is exactly what the users of such a tool want to learn. They just like their programming to be less of a chore, i.e. they want Python or Lua instead of C++ and maybe blocks and patchcords instead of vi/Emacs. _From my experience with giving some workshops in this area I believe that a growing number of artists is looking for software that allows them to build their own specific tools. They are not frightend to learn certain algorithms and how to deal with technical issues as long as these issues are art related. They actually like thinking about things like DSP algorithms for sound and video, but they don't want to think about device drivers and freeing memory (too much). 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
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] 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] 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
