Re: [LAD] Is Piperware a successor to Jack/Pulseaudio?
On Thu, Jul 01, 2021 at 06:57:59PM -0400, bill-auger wrote: > On Thu, 1 Jul 2021 07:01:31 +0100 Keith wrote: > > the distro is not at fault for "failing" to support something, > which did not exist, or was very immature, or proprietary, when > the dirsto was released > The distro is at fault for not packaging it. > the pipewire devs are the ones who had the option to decide > which distros it may be compatible with - obviously, ubuntu18 > was not one that "mattered" to them - but no project is obligated > to support any specific distro, so there is no fault there either Is there anything that prevents you from compiling and building pipewire on 18.04? If not, then it is a distro problem. They have not packaged pipewire for 18.04, and they probably won't package it since 18.04 is a stable release so major new changes won't be made. It would be possible to add it in as a backport, that could optionally be added. -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is there an LV2 plugin that can add echo like echo added by large cathedrals?
On Tue, Apr 06, 2021 at 01:00:53PM -0700, Yuri wrote: > I remember listening to the talk of researchers who were traveling to > different old cathedrals, particularly to Hagia Sophia in Turkey, and > measuring echo in these cathedrals. Such buildings add a lot of deep and > very prolonged echo which depends on the building's shape and materials. > They were quantifying the noise response too. > > > Are there LV2 plugins that can add same or similar echo as cathedrals add? > It sounds like what you're looking for is a "convolution reverb", if you want to get the exact sound of a space, or just any reverb plugin if you're not too fussed. Normal digital reverbs use combinations of different sized delays to provide a dense "wash" of sound. By twatting about with the phase through allpass filters and having combinations of very long and very short delays that don't sync up - at least one has to be modulated to stop it sounding "pingy", you can get a very realistic reverb effect. Convolution reverbs effectively multiply each individual sample of the incoming audio with every individual sample of an "impulse" which is a recording of a loud bang in a reverberant space. So, for each input sample you've got an output a few seconds long. One single pulse - just a one-sample click - would play out the impulse, and a sustained sound would sound like it was being played in that space. There are tricks to make it less insanely computationally expensive, but that's basically the size of it. Now even if you don't have exactly the answer, you've got the right words to put into Google :-) -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] The mysterious revival of www.nekosynth.co.uk
Hi folks, Some of you may recall that about ten years ago I wrote some LADSPA and DSSI plugins and hosted them on a Trac install on www.nekosynth.co.uk until I moved away from doing music with computers, and gradually the site became abandoned and the domain lapsed. Someone pointed out that the site is back up on https://www.nekosynth.co.uk with a load of content downloaded from archive.org and indeed there it is - loads of it although the audio examples are missing. This is seriously weird. Like, really, really weird. It wasn't one of you lot, was it? I'd love to try and get in touch with whoever put considerable effort into setting it up. If anyone knows anything I'd appreciate the information. -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] A short technote on digital state-variable filters
On Thu, Nov 19, 2020 at 10:05:00PM +0100, Fons Adriaensen wrote: > Hello all, > > Some people have asked me to provide a bit more documentation > on the state-variable filters I used in zita-eq1 and zita-jacktools. > > So I've written a short technical note on this. You can find it at > > <http://kokkinizita.linuxaudio.org/papers/digsvfilt.pdf> I wish I was good at maths! This makes it all look so simple, and it works well. I guess with the corrected parameters, you can't get it to self-oscillate without Q really being infinite? With the uncorrected parameters it seems to go "over unity" with Q set to about 10, but a soft clipper would stop it blowing up. It behaves well if you interpolate the c1 and c2 values to sweep the filter across a block of samples, which is handy. -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Linux Synth dev primers
On Sun, Oct 18, 2020 at 05:58:04PM +0100, Martyn Cox wrote: > Hi, is it still active here? > > I’m trying to locate some help for developing a basic subtractive synth for > Linux with support for sound patches. > > Can someone point to any primer material? And What dev libraries for synth > development are essential? > > Thanks in advance You could do worse than look at the source code for Xsynth, that's all I did when I was getting started :-) -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] SoundTracker 1.0.2 first pre-release
On Tue, Oct 13, 2020 at 12:25:17AM +0300, Yury Alyaev wrote: > Hi all! > > Today I have finished a large amount of work: support of user actions > logging in SoundTracker. This means that almost all operations can be undone > / redone. Before this I have redesigned the sample editor. Although these > are not all improvements scheduled for 1.0.2 release, I would like to start > testing of the above two features. So I have issued the first pre-relase > available as usual at https://sourceforge.net/projects/soundtracker/files/ > > I invite everyone to test this and send me bugreports. But I'd like to warn, > that this pre-release couldn't be pretty stable and can occasionally crash. > If you are familiar with gdb (GNU debugger) please compile ST with > CFLAGS=-DDEBUG and after crash explore the core file with gdb and send me > the backtrace. This fails to build for me (Ubuntu Studio 20.04.1). The configure script fails to pick up the lack of libsndfile headers, but that's minor. /usr/bin/ld: envelope-box.o: in function `envelope_box_set_envelope': /home/gordonjcp/devel/soundtracker-1.0.2-pre1/app/envelope-box.c:1058: undefined reference to `update_sustain_line' /usr/bin/ld: /home/gordonjcp/devel/soundtracker-1.0.2-pre1/app/envelope-box.c:1059: undefined reference to `update_loop_lines' collect2: error: ld returned 1 exit status -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] PSIndustrializer 0.2.6 released
On Wed, Jun 24, 2020 at 12:09:07PM +0300, Yury Alyaev wrote: > Hi all, > > After a long period of lethargy, with a help from Wladimir J. van der Laan, > I have revived Power Station Industrializer, a percussion sound synthesizer > base on physical modelling. I *love* PSindustrializer! Thanks for this! -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] 9 soundcards ?
On Wed, Nov 13, 2019 at 07:22:52PM +0100, Manuel Haible wrote: > Now I decided for a no-compromise chain (thats why I choose Linux) > - and I am aware that there are different scientific statements about 48 vs > 96k. You needn't go above 48kHz/16 bit. In double-blind tests I've yet to find anyone that can tell that apart from 192kHz/24 bit. In practical terms you're going to be listening to it with 32kHz/12 bit ears anyway ;-) -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Bit shift
On Sun, Mar 17, 2019 at 11:56:40AM -0500, Jonathan Brickman wrote: > That is likely to change depending on GCC optimization setting, no? > This is why you can't trust very high level languages like C, and should be wary of high-level languages like assembler. -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] So in 2019, which plugin "format"?
Hi folks, At the risk of igniting a flame war, if one were to develop softsynth plugins for Linux, what would be the "framework" of choice these days? Back in the day I wrote some using DSSI, which was a model I was pretty comfortable with. I had a look at LV2 but couldn't work out how to generate the huge incomprehensible non-human-readable "ttl" files. Where does the world stand now? -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is -ffast-math safe for audio?
On Fri, Nov 23, 2018 at 10:33:24PM +0500, Nikita Zlobin wrote: > In Fri, 23 Nov 2018 14:18:01 + > Gordonjcp wrote: > > > On Fri, Nov 23, 2018 at 02:09:02PM +0100, Robin Gareus wrote: > > > On 11/23/2018 01:00 PM, Will Godfrey wrote: > > > [...] > > > > Thanks for going into this in such detail Robin. I never realised > > > > fp stuff could be *quite* so, umm, approximate! > > > > > > Depending on context and the maths, the difference may not matter at > > > all, or may be off completely.. > > > > Surely the answer is just to use 16-bit ints for everything, then...? > > > > Let me note - it would be at least 32-bit int, since in 32bit float > significand is 23bit. We don't need that much precision, we only have 10-bit ears. -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is -ffast-math safe for audio?
On Fri, Nov 23, 2018 at 02:09:02PM +0100, Robin Gareus wrote: > On 11/23/2018 01:00 PM, Will Godfrey wrote: > [...] > > Thanks for going into this in such detail Robin. I never realised fp stuff > > could be *quite* so, umm, approximate! > > Depending on context and the maths, the difference may not matter at > all, or may be off completely.. Surely the answer is just to use 16-bit ints for everything, then...? -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.
On Sun, Dec 10, 2017 at 09:26:55PM +0100, Markus Seeber wrote: > >> and be done with it, let offensive software die. In my eyes writing a > >> plugin GUI > >> in GTK/Qt is very bad practice for exactly these reasons. > > So what would you write it in instead? > > > You can still statically link for example with FLTK and derivatives or roll > your That doesn't answer the question, really. For one thing, statically linking *anything* is utterly ridiculous and anyone doing that now or indeed at any point in the past 30 years of Unix development should have their hands cut off. Why would FLTK be any better than Gtk or Qt? It's slow, bloated and fairly ugly, and is yet another set of deps to pull in. -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.
On Sun, Dec 10, 2017 at 08:37:08PM +0100, Markus Seeber wrote: > On 12/10/2017 03:31 PM, Paul Davis wrote: > > On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber < > > markus.see...@spectralbird.de> wrote: > > > >> > >> Just employ static linking when sensible. > > > > unortunately, several large toolkits of various types make this impossible > > because they themselves use dynamic (runtime-driven) loading of shared > > objects. GTK (and its dependency stack) is a particular offender there, but > > I believe the same is true of Qt. You can't statically link against this > > type of toolkit if your goal is to end up with a self-contained binary. the > > g* stack has made a few improvements in this area in recent years, but > > AFAIK it still isn't possible to build a self-contained binary. JUCE > > differs from this, I believe. > > > > That is exactly the problem with plugins. At the same time I'd say: > "Don't use these GUI librarys for plugins and do not load any plugin that > exports these symbols." > and be done with it, let offensive software die. In my eyes writing a plugin > GUI > in GTK/Qt is very bad practice for exactly these reasons. So what would you write it in instead? -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.
On Sat, Dec 09, 2017 at 02:24:37PM +0100, Louigi Verona wrote: > This is a good point, Fons. > > On Windows it is typical to bundle a program with stable libraries and > dependencies. Is this strategy thinkable on FLOSS systems? No, and it's a stupid idea on Windows too, which is why Windows uniquely suffers from "DLL Hell". Just write your software so it doesn't break APIs. -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] https for linuxaudio.org
On Tue, Nov 21, 2017 at 11:01:07AM -0500, Janina Sajka wrote: > As a user of Arch and various music related apps, please, please, > please! > > I can report that Let's Encrypt is very easy to use. The cli tool > certbot handles things very nicely, and the docs are easy to follow. > This should not be hard to implement. I'm using Let's Encrypt on https://rangerovers.pub and it's been pretty hassle-free. I had minor issues at the start because some people were visiting from the old domain name, but nothing insurmountable. If you have anything where you accept user input on your website (the obvious case being a username and password, but even a search box) then you should absolutely be using HTTPS, right now. -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Jack buffer requirements
On Fri, Sep 15, 2017 at 09:37:43AM -0700, benravin wrote: > Hi Gordon, > > Thanks for the link. In fact I'm developing broadcast receiver for digital > radio standards like DAB, ISDB-T etc. I had a look at your source code. By > using mplayer the IQ output will be fed into jack input port which is the > capture port right ? That's correct. That allows me to have a prerecorded IQ capture file that I can play back without an off-air signal. I wrote lysdr in the first place because converting Quisk to accept prerecorded files was such a massive pain in the arse, and I wanted to demo Software-Defined Radio at my local amateur radio club with no aerial in the distinctly RF-hostile centre of Glasgow :-D > DAB frame duration is 24ms which corresponds to 24ms of audio. But the > audio frame size can be max 60ms. Can JACK support different buffer lengths > for each clients ? You'll need to talk me through that a bit. Does that mean that you end up buffering more input frames than you're playing out? Or do you have 60ms output from a 24ms input that arrives somewhere in a 60ms timeslice? -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Jack buffer requirements
On Thu, Sep 14, 2017 at 10:56:14AM -0700, benravin wrote: > > I don't have any disk I/O operations, I receive data from a USB dongle at a > constant rate. > Hi! It sounds like you're writing an SDR. You might be interested in lysdr: http://gordonjcp.github.io/lysdr/ -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] crosstalk between jack clients/ports?
On Wed, May 27, 2015 at 10:32:01AM +0200, Vaclav Mach wrote: I want to avoid the echo and I have two ideas where the problem can be: 1) there is a crosstalk between jack ports/clients 2) there is a crosstalk in my HW (mainboard sound device with intel_hda driver) Most likely the latter. Check you haven't got the mix parameter turned up. Try a different (external?) soundcard. -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Thu, Apr 23, 2015 at 12:50:06PM +0300, Vytautas Jancauskas wrote: On Wed, Apr 22, 2015 at 11:39 PM, Fons Adriaensen f...@linuxaudio.org wrote: On Wed, Apr 22, 2015 at 06:34:25AM -0700, Len Ovens wrote: A knob is ok if it works similar. Knobs that insist that I touch the knob pointer and move that in a tiny arch to adjust and where the pointer flips from one end to the other if I make the wrong move are not easier to move on stage... That's just bad design. I never understood that. Who would think that having to operate a circular knob by moving the mouse in a little circle is convenient? It's also a bit harder to implement. Is there some argument for it I am not aware of? Even if it's a bad argument? I used to have that in nekobee but at some point (possibly not in a released version, possibly only in Gtk3) I switched to vertical movement. I really ought to dust that off. Maybe I'll make time next weekend, this weekend is a full of shite goth music and Landrover offroad contests :-D -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Tue, Apr 21, 2015 at 08:16:05AM +0200, Thijs van severen wrote: We need to be aware of the fact that most people on this list are devs and therefore do NOT represent the average user In other words : I dont like splash screens so i'm not going to implement one is (IMHO) a very very wrong attitude. The same goes for any other feature I still don't get why splash screens are a good thing. I don't want a big modal picture blotting out the middle quarter of the screen just because an app is waiting to start up. Maybe there are other things I'd like to do with the computer while I'm waiting. -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Sat, Apr 18, 2015 at 11:40:10PM +0100, Harry van Haaren wrote: Hi All, As promised just at the closing ceremony of LAC, an email opening the discussion of User Experience on Linux Audio. To all Developers, please use this as a checklist and consider supporting each item. It will improve the user experience. 1: Splash Screen If an app takes more than one quarter of a second to open, use a splash screen to give feedback. Feel free to contact me directly to collaborate on a splash screen graphic if necessary. Ensure the splash is shown immediately, before lengthy operations such as scanning for Just as long as it's not modal, or better yet make it optional. There's nothing worse than a big ugly graphic blotting out the middle of your screen preventing you from doing anything while you wait for some buggy slow piece of crap to load. Splash screens are a symptom, not a solution. -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Advanced Gtk+ Sequencer aka GSequencer now on GitHub
On Fri, Apr 03, 2015 at 11:46:17AM -0700, Len Ovens wrote: The only downside is longer sysex events. I think there is work underway to deal with this as well, but of course a long sysex no longer would have sample acurate timing (maybe the first part will be time stamped) or at least would have added latency (ie. it would no longer be real time anyway). But that is a problem rawmidi would have to deal with as well. I do not know if there is a particular byte count limit to sysex events or if it varies with jack latency (the length of the cycle). But if you expect users to use this live, then it needs to work with reasonably low latency. I can't help but think that if you're doing something that requires sample-accurate sysex messages, you're doing something a bit strange and wrong :-D -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Open Source Audio Interface
On Thu, Sep 11, 2014 at 09:17:26PM +, Fons Adriaensen wrote: Re. the format used by njbridge: for IPv4 the IP and UDP headers together take 28 bytes. That is less than 2 percent of 1500, and is a small price for having packets that can be handled by switches and routers. There is really no point in trying to reduce that sort of overhead. The njbridge format itself adds a 20 byte header to sample packets. This data is used to identify the packet, to improve the timing and handle skipped cycles, xruns, lost packets and the like. All together the overhead is less than 3.5%. But then you *must* take care of timing, since you have no idea if packets passed through a router will arrive in order, how long they'll take to traverse it, or even if they'll arrive unmangled at all. If you are going to strip it down, just go with bare Ethernet frames :-) -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Software sound
On Mon, Sep 01, 2014 at 03:07:32PM +0100, W.Boeke wrote: 'Warmth' depends on the lower harmonics. If you are aiming for warmth then start with a base signal with more lower harmonics, e.g. a square wave i.s.o. a pulse. Also equalizing and a suitable amplifier are important. And the ultimate way to get warmth is to add a small amount of 1/2 or 2/3 harmonics. In software this is easy, for real instruments it's impossible! I'm not sure why you'd say it's impossible, although I'm not sure what you're trying to describe with 1/2 and 2/3 - maybe adding in lower frequencies than the fundamental? I'm not sure why you'd do that and 2/3 would be inharmonic and sound shite. If you mean 2nd and 3rd harmonics, they're *easy*. -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Software sound
On Sun, Aug 31, 2014 at 07:42:48PM +, Fons Adriaensen wrote: On Sun, Aug 31, 2014 at 08:13:01PM +0100, W.Boeke wrote: Sorry Fons, if you google moog filter schematic you will see 3 stages, where a stage is a capacitor in series with 2 transistor emitters (which have a diode V/I characteristic). All versions I've every seen have four stages, and with three the feedback wouldn't have the right phase. If you find a schematic with three stages please post a link. Each stage is a capacitor in parallel with the series connection of two emitter impedances, and driven by a current source, the collector currents of the previous stage. Correct. Even the 18dB/octave Roland TB303 ladder filter has four stages. Why isn't it 24dB/octave? Because they're more honest about the real-world performance than Moog :-D Once you go hanging weirdass source and load impedances off your ladder the response can vary wildly. Tim Stinchcombe has an incredible analysis which shows all sorts of odd bumps and peaks in what you'd typically expect to be flat passband. About that complicated code: I saw implentations with a lot of code lines, and preventing oscillations originating from the non-linear tanh functions needed a lot of care. I analysed this thing to dead around ten years ago, when I wrote the MCP plugins. There is no instability problem resulting from the non-linearity. The main problem with a straightforward digital implementation is that it becomes a bad approximation at higher frequencies, this requires some attention to get right. The easy solution is to run it at a higher sample rate. Ah, the fons-filter. Extremely stable and a nice acid-y squelch. Since a tanh function tends to unity at either end, I can't see how that *would* go unstable. You'd need to have greater than unity gain for it to really go off. Fons - ever considered turning your analytical skill to the MS20 and Steiner Synthacon diode-chain Sallen-Key filter? -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Software sound
On Sun, Aug 31, 2014 at 08:26:18PM +, Fons Adriaensen wrote: Fons - ever considered turning your analytical skill to the MS20 and Steiner Synthacon diode-chain Sallen-Key filter? If you can provide a schematic I may be tempted... http://yusynth.net/Modular/EN/STEINERVCF/ :-D -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Digital Effects
On Fri, Aug 22, 2014 at 04:12:12PM +0200, t...@trellis.ch wrote: Hi, is it correct that the following two scenarios give the exact same result? (digital audio signal) - (record) - (playback) - (apply fx) - (result) (digital audio signal) - (apply fx) - (record) - (playback) - (result) regards Tom Only if the recording and playback process are exactly lossless. -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] ladspamm - a small c++ library for handling LADSPA plugins
On Mon, Jan 07, 2013 at 12:05:55PM +0100, Ove Karlsen wrote: Mentioning LADSPA in 2013 is wildly outdated don´t you think? I am a professional musician. I am also the developer of the millennium plugin suite, which is technically superior in anything it does, compared to closed-source variants. Why do you think LADSPA is outdated, and what do you use instead? The whole reason I stopped developing the nekosynth plugins was because of the ungodly mess that is LV2. VST is out, because I'm not interested in proprietary software. -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] ladspamm - a small c++ library for handling LADSPA plugins
On Mon, Jan 07, 2013 at 01:23:39PM +0100, Ove Karlsen wrote: I am using windows and vst at the moment. I need to do work in a professional environment, and linux is not there yet. On the Linux Audio Developer list, Windows is distinctly offtopic. I'm not aware of any professional-grade audio software for Windows, or indeed the PC platform at all. Find me a sequencer that can actually keep time on a PC, and I'll start to consider it suitable for professional use. -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Writing a library?
On Wed, Jul 23, 2008 at 03:25:47PM +0200, Julien Claassen wrote: Hi! Paul: As I understood the sfz format is text-based. I didn't take a look. But depending on what it looks like, a parser generator might be good advice. If the SFZ is an xml variant libxml might be better suited. Kindest regards Julien It's not XML, it's a sort of flat-text-ish thing with various keywords for setting keys, keygroups, mutegroups and so on. Having briefly skimmed the spec over lunch, I'm not in much of a position to say how good it is, but it looks right. Essentially an SFZ file is a text file describing what to do with a bunch of .wav or .ogg files. It's almost worryingly clueful. Gordon ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
