Re: [LAD] VST and Qt
David García Garzón wrote: Hi, lads! Some news from the CLAM project. For anyone interested in that subject, we managed to build Qt based VST interfaces (from linux!). Not about integrating existing VST in Qt applications but building brand new plugins using Qt. This is an step to get visual prototyped VST from CLAM as we got from LADSPA and JACK on last releases. I don't think the integration could get into the next CLAM release, but i guess that just the Qt-VST integration could be useful to someone in the community. See more information here: http://vokicodder.blogspot.com/2009/04/vst-plugins-with-qt-user-interface.html The code is available in the first link to the CLAM developers list. Not the proper distribution but i plan to make it available from clam or other repository in short. Any collaborative hacking to improve it is very welcome. I'm an programmer noob, but some questions. 1) what is your aim? Building VST plugins for Gnu/ Linux? Is a VST better then an LV2 plugin? 2) why is the focus in the Gnu/Linux work on VST and not on AudioUnit plugins? Linux and OS X are both Unix like systems right? Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [LAC2009] stream team volunteers wanted!
hi everyone! for those among you who will make it to LAC 2009 in parma: we are looking for 1-2 more people to help with the streaming. your job would be to watch the paper sessions, hang out on IRC and relay the questions of remote participants to the local audience. if you're interested, you also get to play with some interesting video gear and the blazing new thusnelda encoder :) please get in touch! volunteers will be fed and watered as required, according to the Marije Baalman StreamTeam Sustenance Plan(tm). unfortunately, stream overlord eric rzewnicki can't be with us this year - i'd like to take the opportunity to offer HUGE (and i mean, like, HUMONGOUS) kudos to edrz for many years (and many more hours) of volunteer work for this community (not to mention shouldering frightening travel expenses year after year to haul himself to old europe). edrz: thanks! i hope we'll see you on IRC. best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] SDL_mixer+LADSPA was:basic in-game audio synthesis api?
Hi, My experiment so far has yielded a WAV played via SDL_mixer and by registering a callback through Mix_RegisterEffect it is processed by the following LADSPA filters: 4x4allpass and Gverb. There might be some problems here though so I am asking if anybody can advise upon using SDL for audio. The problems with SDL_mixer are as follows: 1) The callback registered with Mix_RegisterEffect has a len parameter which is the length of the stream passed to the callback. It's value however seems mysteriously derived and it would be helpful to know in advance, it's precise value or expected ranges so I can create the IO buffers for the LADSPA effects only as large as they need be (rather than excessively large) before the fx call back is registered. ( is it always 1880 samples? ) 2) Currently, I have a mono stream (i think, not entirely sure) and it goes to the FX callback, processed by 4x4allpass, and then by Gverb. I discard one of the output channels from Gverb because, what else can I do with it? Nothing AFAICT. (No buses :( ) Are there solutions to this while still using SDL_mixer? Or should I write a custom mixer, (probably start coding from David Olofson's examples) ? Regards, James. On 3/4/2009, Paul Davis p...@linuxaudiosystems.com wrote: On Fri, Apr 3, 2009 at 6:13 PM, james morris ja...@jwm-art.net wrote: Allowing the game to connect to JACK, and using LADSPA plugins for the effects was just one option I thought of, but it would be a little unusual for a game. But still, it might be interesting to try. i wasn't suggesting JACK. just ladspa. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] SDL_mixer+LADSPA was:basic in-game audio synthesis api?
On Mon, Apr 6, 2009 at 8:44 AM, james morris ja...@jwm-art.net wrote: Hi, My experiment so far has yielded a WAV played via SDL_mixer and by registering a callback through Mix_RegisterEffect it is processed by the following LADSPA filters: 4x4allpass and Gverb. There might be some problems here though so I am asking if anybody can advise upon using SDL for audio. The problems with SDL_mixer are as follows: 1) The callback registered with Mix_RegisterEffect has a len parameter which is the length of the stream passed to the callback. It's value however seems mysteriously derived and it would be helpful to know in advance, it's precise value or expected ranges so I can create the IO buffers for the LADSPA effects only as large as they need be (rather than excessively large) before the fx call back is registered. ( is it always 1880 samples? ) 2) Currently, I have a mono stream (i think, not entirely sure) and it goes to the FX callback, processed by 4x4allpass, and then by Gverb. I discard one of the output channels from Gverb because, what else can I do with it? Nothing AFAICT. (No buses :( ) Are there solutions to this while still using SDL_mixer? Or should I write a custom mixer, (probably start coding from David Olofson's examples) ? Regards, James. On 3/4/2009, Paul Davis p...@linuxaudiosystems.com wrote: On Fri, Apr 3, 2009 at 6:13 PM, james morris ja...@jwm-art.net wrote: Allowing the game to connect to JACK, and using LADSPA plugins for the effects was just one option I thought of, but it would be a little unusual for a game. But still, it might be interesting to try. i wasn't suggesting JACK. just ladspa. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev If I understand correctly, what you are talking about is the buffer size. The tradeoffs with buffer size are that with a short buffer size sonic events happen with a shorter latency (ie. if a pew pew sound goes with the laser, a shorter buffer reduces the delay between the user pushing the fire button and hearing the pew pew sound). If the buffer is too short, your CPU usage will become too large, and eventually you will probably get underruns in your output buffers, creating skipping sounds or gaps in your audio. If the buffer size is too large, you will have a sluggish feeling to the game and for faster sequences of events the sounds won't quite go with the key presses and images. Typically you want buffer sizes to be some power of two, or a small multiple of a power of two. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] basic in-game audio synthesis api?
What about using an external program like Pd or ChucK to design your sounds, and just talk to the sound engine using OSC? (Hm, yes this does seem like my answer for everything these days...) Anyways, you can run a Pd patch for example without the GUI, or a lot of the effects you mention are built into ChucK or SuperCollider as well. I find it nice to be able to separate this stuff out of a program and have it running in another process, particularly if it's going to conflict with a game loop, and allows you to design nice audio routines without worrying about headache-inducing system-level technical details. The main disadvantage of course is having to distribute source files for the audio that aren't compiled into the main executable. Not sure if that's really a disadvantage though, it depends on your intentions. (For instances many games have tons of extra data files anyways.) Another idea: if you really want to do this in C, and already using SDL to deal with sound output, but are still looking for a higher-level solution, you could use FAUST to generate C++ code which is actually not too hard to convert to C. (FAUST mostly just generates a single C++ class with a single audio routine that manipulates some arrays and floating-point numbers.) Steve On Fri, Apr 3, 2009 at 3:50 PM, james morris ja...@jwm-art.net wrote: Hi, I'm wanting to use basic synthesis techniques such as ADSRs LFOs hi/lo pass filters, echo, and reverb to generate some kind of ambient sound scape using pre-recorded audio clips, for a game I'm working on. Are there any libraries around to help make this a bit easier than coding it all using SDL_mixer? I'm not keen for a game to have audio, to depend on JACK or LADSPA plugins. Cheers, James ___ 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] SDL_mixer+LADSPA was:basic in-game audio synthesis api?
On 6/4/2009, Justin Smith noisesm...@gmail.com wrote: If I understand correctly, what you are talking about is the buffer size. Not exactly. I set the buffer size to 4096 with the call to Mix_OpenAudio. The figure I'm talking about is the length of the stream passed by SDL_mixer to my sfx processing callback. 1880 samples at sample rate 44100 (halved for 22050). I'm trying to understand how this figure is arrived at, and if I can rely on it (before any audio processing starts) when I create the buffers the LADSPA plugins will use. Changing the size of the buffers makes no difference to this figure, but changing the sample rate does. Hmmm, that kinda half answers it. james. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] VST and Qt
On Monday 06 April 2009 14:45:40 Grammostola Rosea wrote: David García Garzón wrote: Hi, lads! Some news from the CLAM project. For anyone interested in that subject, we managed to build Qt based VST interfaces (from linux!). Not about integrating existing VST in Qt applications but building brand new plugins using Qt. This is an step to get visual prototyped VST from CLAM as we got from LADSPA and JACK on last releases. I don't think the integration could get into the next CLAM release, but i guess that just the Qt-VST integration could be useful to someone in the community. See more information here: http://vokicodder.blogspot.com/2009/04/vst-plugins-with-qt-user-interface .html The code is available in the first link to the CLAM developers list. Not the proper distribution but i plan to make it available from clam or other repository in short. Any collaborative hacking to improve it is very welcome. I'm an programmer noob, but some questions. 1) what is your aim? Building VST plugins for Gnu/ Linux? Is a VST better then an LV2 plugin? 2) why is the focus in the Gnu/Linux work on VST and not on AudioUnit plugins? Linux and OS X are both Unix like systems right? The principle we follow is design once, generate many. We are aiming on building any kind of plugins or audio backends our users want to build using the CLAM framework. See: http://clam-project.org/wiki/Network_Editor_tutorial One of those targets is building VST plugins *for Windows* (crosscompiled from linux or natively from windows). The main advantage for linux users is that they can visually build their plugins or JACK applications in linux with CLAM, and then, if they want their plugin to be available for Windows users, just click a button and you'll have a VST plugin as well. LV2 is also on our roadmap, and I guess that having already support for Ladspa it won't be that difficult. But right now our interests where VST just because a project partners asked us for some vst's and, well, it was funny doing that from linux. We had vst code working for a couple of years but without GUI, and in order to make this code valuable we had to unlock the GUI front. That's what we did. The good news, if you are interested in AudioUnits, is that one of our coworkers, Ferran Orriols, already has an assigned time slot to implement AudioUnits in CLAM, after his eastern exams. Of course, any help on supporting whatever plugin/backend platform would be very appreciated as we have a limited number of hands. ;-) David. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] SDL_mixer+LADSPA was:basic in-game audio synthesis api?
passed by SDL_mixer to my sfx processing callback. 1880 samples at sample rate 44100 (halved for 22050). I'm trying to understand how this figure is arrived at, and if I can rely on it (before any audio The buffer size you get from an audio backend is normally difficult to predict, and I wouldn't advice you to do so. Sometimes it may even depend on the hardware you are using, so it is not guaranteed that it will be the same on another machine. I don't know whether SDL encapsulates that for you, that would be more a question for SDL support. Most audio processing apps use ring buffers to account for that variability. Just use any value you think provides you with a reasonable latency. If you get more from the backend, just make several calls to the LADSPA, it shouldn't mean much overhead. If you get less, just process that bit or save it for the next iteration. L ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] VST and Qt
David García Garzón wrote: On Monday 06 April 2009 14:45:40 Grammostola Rosea wrote: David García Garzón wrote: Hi, lads! Some news from the CLAM project. For anyone interested in that subject, we managed to build Qt based VST interfaces (from linux!). Not about integrating existing VST in Qt applications but building brand new plugins using Qt. This is an step to get visual prototyped VST from CLAM as we got from LADSPA and JACK on last releases. I don't think the integration could get into the next CLAM release, but i guess that just the Qt-VST integration could be useful to someone in the community. See more information here: http://vokicodder.blogspot.com/2009/04/vst-plugins-with-qt-user-interface .html The code is available in the first link to the CLAM developers list. Not the proper distribution but i plan to make it available from clam or other repository in short. Any collaborative hacking to improve it is very welcome. I'm an programmer noob, but some questions. 1) what is your aim? Building VST plugins for Gnu/ Linux? Is a VST better then an LV2 plugin? 2) why is the focus in the Gnu/Linux work on VST and not on AudioUnit plugins? Linux and OS X are both Unix like systems right? The principle we follow is design once, generate many. We are aiming on building any kind of plugins or audio backends our users want to build using the CLAM framework. See: http://clam-project.org/wiki/Network_Editor_tutorial One of those targets is building VST plugins *for Windows* (crosscompiled from linux or natively from windows). The main advantage for linux users is that they can visually build their plugins or JACK applications in linux with CLAM, and then, if they want their plugin to be available for Windows users, just click a button and you'll have a VST plugin as well. LV2 is also on our roadmap, and I guess that having already support for Ladspa it won't be that difficult. But right now our interests where VST just because a project partners asked us for some vst's and, well, it was funny doing that from linux. We had vst code working for a couple of years but without GUI, and in order to make this code valuable we had to unlock the GUI front. That's what we did. The good news, if you are interested in AudioUnits, is that one of our coworkers, Ferran Orriols, already has an assigned time slot to implement AudioUnits in CLAM, after his eastern exams. Of course, any help on supporting whatever plugin/backend platform would be very appreciated as we have a limited number of hands. ;-) David. @ Paul, thanks for your explanation. @ David, Ok, thanks for information. I read often that people regret that certain Free VST plugins are not available on GNU/Linux. VST plugin authors don't want to make it for GNU/ Linux... maybe if it's easier to build for both platforms this will improve. Also sometimes there is a GUI for the Windows version and not for GNU/Linux (I think Freeverb3 is such an example). Would be nice if such an Gui for Windows could be easily build on GNU/Linux too. Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] basic in-game audio synthesis api?
Hallo, Stephen Sinclair hat gesagt: // Stephen Sinclair wrote: What about using an external program like Pd or ChucK to design your sounds, and just talk to the sound engine using OSC? (Hm, yes this does seem like my answer for everything these days...) Anyways, you can run a Pd patch for example without the GUI, or a lot of the effects you mention are built into ChucK or SuperCollider as well. I find it nice to be able to separate this stuff out of a program and have it running in another process, particularly if it's going to conflict with a game loop, and allows you to design nice audio routines without worrying about headache-inducing system-level technical details. Or you embed Pd: It's done like that in Spore, which runs a Pd engine inside, or in RjDj, which is something in between a game and a music software and also runs Pd embedded. Advertisment: Here you can find hours and hours of RjDj-user-generated music: http://rjdj.me Recorded on iPod or iPhone, but many of the RjDj scenes used there have been made on Linux. Ciao -- Frank ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] VST and Qt
On Monday 06 April 2009 18:19:19 Grammostola Rosea wrote: David García Garzón wrote: On Monday 06 April 2009 14:45:40 Grammostola Rosea wrote: David García Garzón wrote: Hi, lads! Some news from the CLAM project. For anyone interested in that subject, we managed to build Qt based VST interfaces (from linux!). Not about integrating existing VST in Qt applications but building brand new plugins using Qt. This is an step to get visual prototyped VST from CLAM as we got from LADSPA and JACK on last releases. I don't think the integration could get into the next CLAM release, but i guess that just the Qt-VST integration could be useful to someone in the community. See more information here: http://vokicodder.blogspot.com/2009/04/vst-plugins-with-qt-user-interfa ce .html The code is available in the first link to the CLAM developers list. Not the proper distribution but i plan to make it available from clam or other repository in short. Any collaborative hacking to improve it is very welcome. I'm an programmer noob, but some questions. 1) what is your aim? Building VST plugins for Gnu/ Linux? Is a VST better then an LV2 plugin? 2) why is the focus in the Gnu/Linux work on VST and not on AudioUnit plugins? Linux and OS X are both Unix like systems right? The principle we follow is design once, generate many. We are aiming on building any kind of plugins or audio backends our users want to build using the CLAM framework. See: http://clam-project.org/wiki/Network_Editor_tutorial One of those targets is building VST plugins *for Windows* (crosscompiled from linux or natively from windows). The main advantage for linux users is that they can visually build their plugins or JACK applications in linux with CLAM, and then, if they want their plugin to be available for Windows users, just click a button and you'll have a VST plugin as well. LV2 is also on our roadmap, and I guess that having already support for Ladspa it won't be that difficult. But right now our interests where VST just because a project partners asked us for some vst's and, well, it was funny doing that from linux. We had vst code working for a couple of years but without GUI, and in order to make this code valuable we had to unlock the GUI front. That's what we did. The good news, if you are interested in AudioUnits, is that one of our coworkers, Ferran Orriols, already has an assigned time slot to implement AudioUnits in CLAM, after his eastern exams. Of course, any help on supporting whatever plugin/backend platform would be very appreciated as we have a limited number of hands. ;-) David. @ Paul, thanks for your explanation. @ David, Ok, thanks for information. I read often that people regret that certain Free VST plugins are not available on GNU/Linux. VST plugin authors don't want to make it for GNU/ Linux... maybe if it's easier to build for both platforms this will improve. Also sometimes there is a GUI for the Windows version and not for GNU/Linux (I think Freeverb3 is such an example). Would be nice if such an Gui for Windows could be easily build on GNU/Linux too. Yes, that's the point, reusing the same Qt interface for JACK apps, LV2 and VST. No need to use VSTGUI which is tailored just for VST and not even inventing a new toolkit, just taking a general purpose one. David. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] SDL_mixer+LADSPA was:basic in-game audio synthesis api?
On Mon, Apr 6, 2009 at 9:20 AM, Luis Garrido luisgarr...@users.sourceforge.net wrote: passed by SDL_mixer to my sfx processing callback. 1880 samples at sample rate 44100 (halved for 22050). I'm trying to understand how this figure is arrived at, and if I can rely on it (before any audio The buffer size you get from an audio backend is normally difficult to predict, and I wouldn't advice you to do so. Sometimes it may even depend on the hardware you are using, so it is not guaranteed that it will be the same on another machine. I don't know whether SDL encapsulates that for you, that would be more a question for SDL support. Most audio processing apps use ring buffers to account for that variability. Just use any value you think provides you with a reasonable latency. If you get more from the backend, just make several calls to the LADSPA, it shouldn't mean much overhead. If you get less, just process that bit or save it for the next iteration. L ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev The output buffer is not your only audio buffer, what we are dealing with here is the size of the LADSPA processing buffer. This is a simple matter of sending data from one buffer to another, as suggested above, using a ring buffer is you most likely solution. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] basic in-game audio synthesis api?
On Saturday 04 April 2009, james morris wrote: Taken a quick look. It looks too low-level DSP for me. I was actually thinking something along the lines of Audiality (but couldn't recall its name). As of now, Audiality is mostly off-line modular synthesis along with a basic sampleplayer (DAHDSR envelopes, FX sends etc) and a few real time effects. So far, it's really been focused on creating sounds from nothing (ie no samples), though it can import, play and process sampled sounds as well. Is Audiality dead? Yes and no. The most current release is probably the unnamed sound engine of Kobo Deluxe, though I'm just keeping it alive as I'm still using it - no real development. (As of 0.5.1, all sounds are pure modular synthesis - no samples.) http://kobodeluxe.com/ http://www.audiality.org/ The plan is a major rewrite, using EEL for scripting (setup, real time control processing etc) over a properly modular DSP engine (possibly usable as a stand-alone library, without EEL), including modular massively additive IFFT synthesis. http://eel.olofson.net/ The goal is to make it all modular, all the way from control data through audio outputs, and optionally off-line/real time, so you can have a module adapt to available resources, project requirements, user preferences etc. Think evolved MOD format, including proper sound effect support. You load up a module, which exports a bunch of controls and triggers defined by the module author. Like connecting a studio sampler to the MIDI port and have the sound guy programm away on that - only you actually ship with that thing included with the game. When? When I get around to it... :-) Anything else similar? Couldn't FMOD or some other popular game sound engine do this? I know most of them have sample playback (obviously) and effects, but I don't know how flexible they are when it comes to wiring things together... -- //David Olofson - Programmer, Composer, Open Source Advocate .--- http://olofson.net - Games, SDL examples ---. |http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --' ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
