Re: [LAD] libsoundio 1.0.0 released today
On Thu, Sep 3, 2015 at 12:41 PM, Andrew Kelley <superjo...@gmail.com> wrote: > libsoundio is a C library providing cross-platform audio input and output > for real-time & consumer software. It supports JACK, PulseAudio, ALSA, > CoreAudio, and WASAPI. I'm not going to download and play with it because I have no need for it currently, but I did take a look at some of the code. It's meticulously clean. Quite readable. Thanks for taking the time to make it that way. In my quick read through some of the code, I noticed a duplicate assertion on line 756 of alsa.cpp: assert(errno != EFAULT); -- Devin Anderson surfacepatterns (at) gmail (dot) com blog - http://surfacepatterns.blogspot.com/ midisnoop - http://midisnoop.googlecode.com/ psinsights - http://psinsights.googlecode.com/ synthclone - http://synthclone.googlecode.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ladspa: dlopen failed for tap ladspa plugins
On Sat, May 17, 2014 at 10:07 PM, Zlobin Nikita cook60020...@mail.ru wrote:
Code - includes are omited, line with main() declaration is numbered
30: int main (int argc, char ** argv)
{
//LADSPAPluginSearch(describePluginLibrary);
char plugpath [] = /usr/lib/ladspa/tap_echo.so;
void * pvPluginHandle = dlopen(plugpath, RTLD_NOW | RTLD_LOCAL);
if (pvPluginHandle) dlclose (pvPluginHandle);
else printf (dlopen failed: %s\n, plugpath);
return 0;
}
If you want to find out why the dlopen() call is *actually* failing,
use dlerror():
#include stdio.h
#include stdlib.h
#include dlfcn.h
int
main(int argc, char **argv)
{
if (argc != 2) {
fprintf(stderr, Usage: %s plugin-path\n, argv[0]);
exit(EXIT_FAILURE);
}
void *handle = dlopen(argv[1], RTLD_NOW | RTLD_LOCAL);
if (handle == NULL) {
fprintf(stderr, %s: %s: %s\n, argv[0], argv[1], dlerror());
exit(EXIT_FAILURE);
}
dlclose(handle);
return EXIT_SUCCESS;
}
--
Devin Anderson
surfacepatterns (at) gmail (dot) com
blog - http://surfacepatterns.blogspot.com/
midisnoop - http://midisnoop.googlecode.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Weird USB MIDI sysex problem
Hi Ralf, On Fri, Aug 30, 2013 at 7:56 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: http://www.kasploosh.com/projects/CZ/how_to/amidi-cz101-receive.html :D I missed this, since I googeld for the list ponly, so using amidi it's possible to write a synth editor by shell script, at least sending some commands is possible without having the knowledge how to program in a Linux common high language such as C. You can also use `midisnoop` for this purpose: http://midisnoop.googlecode.com/ -- Devin Anderson surfacepatterns (at) gmail (dot) com blog - http://surfacepatterns.blogspot.com/ midisnoop - http://midisnoop.googlecode.com/ psinsights - http://psinsights.googlecode.com/ synthclone - http://synthclone.googlecode.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] So what do you think sucks about Linux audio ?
Hi Dave, On Tue, Feb 5, 2013 at 6:58 AM, Dave Phillips dlphill...@woh.rr.com wrote: Not enough native plugins, esp. instruments. I think this is one of the key problems with Linux audio. Part of the problem is that there is no clear mechanism for (non-developer) users to create their own instruments. Many VSTs are constructed with modular DSP programs like synthedit and flowstone (formerly synthmaker). There's probably an opportunity here for Ingen or a new graphical DSP program based on Faust to fill this hole. In general, I think that Linux audio has a lot of tools that help users to create music, but not a lot of tools that help users create their own tools (e.g. instruments, plugins, sample libraries, etc.) to help others to create music. On the development side, I think Aurélien and others like him have the right idea in taking instruments/plugins that are specific to a Linux audio application and porting them to LV2. There's a lot of awesome instruments that are specific to applications (e.g. ALSA Modular Synth, LMMS, etc.) that would generally be more useful if they were LV2 plugins. Poor external/internal session management. Interacting with external hardware can be frustrating. Commercial programs like Renoise account for external hardware in their workflows (e.g. latency management, MIDI clock, MMC, etc.). Most Linux Audio apps don't do this. Too much conflict/fragmentation within the development community. I've been trying to write something about conflict and fragmentation for the past 10 minutes. I think this is a complex issue. I'm not able to find the words to communicate about it right now. So, in your honest and bold opinion as user and/or developer, what do we lack most and what can we do without that we already have ? As a developer, I'm missing a couple things: 1.) User feedback. I can't stress this enough. I watch the download counts increase on the applications I create, but I hardly ever get feedback. I'm discouraged and frustrated by the lack of feedback. 2.) Non-code developers We have a lot of dedicated open source developers writing Linux audio apps, plugins, etc., but I have yet to meet an open source UI designer, or an open source graphic artist. I think a lot of the apps we create could benefit from the feedback of a user interface experience expert. There's probably more, but these are the two things that occur to me now. Dave, this is an important topic. Thanks for taking it on. -- Devin Anderson surfacepatterns (at) gmail (dot) com blog - http://surfacepatterns.blogspot.com/ midisnoop - http://midisnoop.googlecode.com/ psinsights - http://psinsights.googlecode.com/ synthclone - http://synthclone.googlecode.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] So what do you think sucks about Linux audio ?
Hi Gabbe, On Tue, Feb 5, 2013 at 9:21 AM, Gabbe Nord gabbe.n...@gmail.com wrote: 1. An easy way to provide this feedback, and encouragement to do so. There's IRC, mailinglists and forums for this, but most apps actually lack encouragement for feedback. Something as simple as writing If you like this software and have ideas/suggestions, please use [insert_method_here] to contact us, all suggestions are appreciated!. The worst thing that could happen is that the suggestion isn't used, but I think tons can be gained by making the user feel more involved. Excellent! This is a start. I can add something like this to the 'About' dialog of my applications. Questions: 1.) What else can I do, as a developer, to make users feel more involved? 2.) On a similar note, what else can I do, as a developer, to make developers feel more involved? 2. Appreciation for the feedback. Some devs are better then others on this, but I sadly think it's fairly common that users who try and provide feedback either get treated as complete idiots, or that the dev takes it as some form of personal insult. I've seen developers do this. It's really unfortunate. Thanks for your feedback! :) -- Devin Anderson surfacepatterns (at) gmail (dot) com blog - http://surfacepatterns.blogspot.com/ midisnoop - http://midisnoop.googlecode.com/ psinsights - http://psinsights.googlecode.com/ synthclone - http://synthclone.googlecode.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] So what do you think sucks about Linux audio ?
Hi Louigi, On Tue, Feb 5, 2013 at 9:56 AM, Louigi Verona louigi.ver...@gmail.com wrote: 1.) What else can I do, as a developer, to make users feel more involved? Hey Davin! One of the most responsive devs are those that a. respond quickly b. actively develop their software c. integrate suggestions quickly In Linux Audio excellent response I get from Rui on his Qtractor and on Giada. All in all, it is always best when software is developed actively. Real problems arise, when development slows down or comes to a halt. Unfortunately, this leaves some developers with a chicken and egg problem. Developers can't respond at all if there's nothing to respond to, and there's a real danger of software development coming to a halt if users don't give feedback on how things can be improved. I've seen this situation quite a few times: 1.) Developer releases software. 2.) Users download software. 3.) Users don't give feedback, or give very little feedback, on software. 4.) Developer doesn't continue to develop software because (s)he's unmotivated to continue due to a perceived lack of community interest and/or because his/her requirements for the software are satisfied. 5.) Bit-rot ensues. On a more positive note, I think this thread is helping to open a path of communication between users and developers about advancing our community that really needed to be addressed. Thanks again, Dave. -- Devin Anderson surfacepatterns (at) gmail (dot) com blog - http://surfacepatterns.blogspot.com/ midisnoop - http://midisnoop.googlecode.com/ psinsights - http://psinsights.googlecode.com/ synthclone - http://synthclone.googlecode.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] So what do you think sucks about Linux audio ?
HI Gabbe, On Tue, Feb 5, 2013 at 10:33 AM, Gabbe Nord gabbe.n...@gmail.com wrote: An idea is to make a popup that comes up occasionally (maybe once a month or so) when starting/closing the application. This popup could do several things that could increase the participation of users, for example: a) Provide encouragement for involvement. Like Do you like this application? Help improve it by visiting our forums and let us know what you think!. I think this is a good idea. :) b) Provide direct links to ongoing user surveys. This is a golden one for any application I really think. In UI-design, contact and feedback from the end-user (the people that actually use your application) is golden. Especially for smaller development teams, where you've been developing/designing the same application for very long, which of course makes every part of the UI natural and intuitive to you Since it's free and open source, people hopefully/likely won't mind helping out this way. Not everyone has the economy to donate actual money to all projects around there, but anyone can sit down and state pro's, con's and perceived issues with the software. You just need an incentive (that the dev actually care about what you think, and the fact that you can use the software for free is probably usually very well enough) and an easy way of doing it. An ongoing, shorter survey (5-10mins maybe) can give tons of very very valid and good information form your actual users. I hadn't considered this. If I created such a survey, I would be concerned that my own bias would be injected into the questions themselves. Can you suggest a few sample questions that might exist in such a survey? c) Provide an easy way to donate. Some people actually have a good income and can without a doubt donate money. Nicely asking to donate spare cash if you're satisfied could probably generate some donations this way, if people also are somewhat frequently reminded of it. I could add a mechanism like this to (a). I have some experience of both UI-design and the principles around that, and also constructing good surveys, and I would love to help out in any way I can. Like someone else in this thread said, not everyone can code, but that shouldn't stop them from being able to contribute. I can't speak for other developers, but I find your suggestions to be very helpful. On a personal note, I would absolutely love feedback on the UI design of both midisnoop and synthclone. I don't have a problem with either UI, but UI design is *not* my forte, and I have a bias about the intuitiveness of both UIs, given that I built them. Thank you for all your help and feedback. :) -- Devin Anderson surfacepatterns (at) gmail (dot) com blog - http://surfacepatterns.blogspot.com/ midisnoop - http://midisnoop.googlecode.com/ psinsights - http://psinsights.googlecode.com/ synthclone - http://synthclone.googlecode.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Kontakt sampler format (and others like EXS24) - Once again free samples, this time more uplifting
On Sat, Sep 1, 2012 at 3:13 PM, Florian Schirmer florian.schir...@native-instruments.de wrote: Is there someone who knows more about these formats? Even if it is not possible to write a sampler engine (it would not be the first [partly]binary, closed format loaded by open source software) maybe there is at least a way to get all the needed information to convert/correct them by hand or individual scripts. Besides the technical problem there is also a legal problem involved here. To protect the IP of sample developers the instruments sold by 3rd party developers are encrypted. My guess would be that using something like Autosampler to capture a certain snapshot of a library and convert that into something that your favorite can read is by far the most promising solution. But of course this depends on what you're looking for. I haven't heard of Autosampler until now, but this seems like an appropriate time to bring up synthclone: http://synthclone.googlecode.com/ ... which has some similar features, is free, and has a plugin API that allows a programmer to add missing functionality. -- Devin Anderson surfacepatterns (at) gmail (dot) com blog - http://surfacepatterns.blogspot.com/ psinsights - http://psinsights.googlecode.com/ synthclone - http://synthclone.googlecode.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Kontakt Spikes
On Mon, Oct 10, 2011 at 12:38 PM, Michael Ost m...@museresearch.com wrote: On 10/07/2011 07:46 PM, Devin Anderson wrote: On Fri, Oct 7, 2011 at 6:25 PM, Michael Ostm...@museresearch.com wrote: We are seeing unexpected interruptions of SCHED_RR audio processing threads, snip bitching snip Wow, a painful response. It's taken me all weekend to figure out how to reply. :( First, I think you are misusing this mailing list, which is a technical forum on the art of linux audio programming, for a product issue. That much is true. I have a lot of negative feelings about your company and the way they handled the OS situation, and when I saw you ask question regarding your company's product, I felt justified in posting about my experience. Muse Research made me and others like me very angry and frustrated when they didn't fulfill promises they had made to their customers, and made me feel isolated and ignored when they didn't answer or even acknowledge our questions regarding the OS situation. Of course, just because I felt justified doesn't mean I was, and for that, I apologize to the LAD community, and I apologize to you, as you are certainly not your company, and did not make the decisions that left me with negative feelings about your company. I'll send you a PM with the rest of my reply. -- Devin Anderson devin (at) charityfinders (dot) com CharityFinders - http://www.charityfinders.com/ synthclone - http://synthclone.googlecode.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Kontakt Spikes
On Fri, Oct 7, 2011 at 6:25 PM, Michael Ost m...@museresearch.com wrote: We are seeing unexpected interruptions of SCHED_RR audio processing threads, and are struggling to understand why they are happening. Does anyone have any good tips or tools to suggest to help figure out what is preempting or delaying realtime audio threads? The issues are coming up with Receptor [see (*) below for an intro] running its 2.6.24.3 CCRMA based kernel. The bug appears with Receptor in its dual core mode, with three instances of Native Instruments' Kontakt 4 in DFD + multi-core mode. Either lots of held notes, or large patches are needed to get the spikes. bitching You know, even if I could help you, I'm not interested in doing so. I bought a Receptor Pro Jr. just before the Receptor 2s came out. At the time I asked Jack Ortolani (if I recall the name correctly) if the upcoming Receptor 2 OS would be made available for Receptor Version C hardware, like the Receptor Pro Jr., and he told me that it definitely would, and that it wouldn't cost me anything. It seemed totally plausible, as a Receptor is *basically* just a souped-up PC, and the OS is just a customized version of Fedora Linux. Based on that data, I bought the Pro Jr. (approximately 2,000 USD), only to find out that Muse Research decided instead to create an upgrade path for people with Revision C hardware, with an upgrade costing almost as much as the Receptor I had just bought: http://www.museresearch.com/products/receptor2-upgrades.php Several users, including myself, tried to get Muse to address the problem: http://www.kvraudio.com/forum/viewtopic.php?t=267189 http://www.kvraudio.com/forum/viewtopic.php?t=260705 Your company insisted that the reason the OS wasn't being made freely available is because the OS would require a SATA hard drive, and that the SATA drive would be rendered unbootable after a certain number of boots due a BIOS issue in the Version C hardware: http://www.kvraudio.com/forum/viewtopic.php?p=3827915#3827915 http://www.kvraudio.com/forum/viewtopic.php?p=3927549#3927549 ... which was eventually debunked by users: http://www.kvraudio.com/forum/viewtopic.php?t=288470 http://www.kvraudio.com/forum/viewtopic.php?p=4596361#4596361 Even then, some of us wanted to have the new operating system, and would have been happy running it off of the IDE drives that came with our Receptors. Muse Research confirmed this wasn't a problem: http://www.kvraudio.com/forum/viewtopic.php?p=3936241#3936241 ... but failed to actually say why they wouldn't allow us to upgrade in that fashion. I later wrote your CEO and asked for a refund on my hardware, and he completely ignored me. I despise your company and its business practices. /bitching -- Devin Anderson devin (at) charityfinders (dot) com CharityFinders - http://www.charityfinders.com/ synthclone - http://synthclone.googlecode.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Feature requests: add JackSession support
On Sun, Jul 3, 2011 at 10:32 AM, Paul Davis p...@linuxaudiosystems.com wrote: i feel that if you spend too long reasoning about this, you will conclude, as I have, that JACK was actually a mistake (at least in terms of the basic framework in which to glue together different things processing data streams). the absence of a plugin API that was likely to be adopted by all/most developers back in 2000 is what gave rise to this situation. there's a limit to how far you can push the usability of a DAW built out of N independent processes, each one running code developed by different developers with no awareness of the others. the limit is, thankfully, not too primitive, but its also not far enough out to be able to pretend that JACK + N1 clients is actually functionally equivalent to a single host + plugins, at least not in terms of state management. I'm curious about what you might have done differently if you knew then what you know now. -- Devin Anderson devin (at) charityfinders (dot) com CharityFinders - http://www.charityfinders.com/ synthclone - http://synthclone.googlecode.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Synth/Sampler why the distinction?
On Thu, Jun 9, 2011 at 3:22 PM, James Morris jwm.art@gmail.com wrote: Since working on Petri-Foo I keep returning to the idea that perhaps it would be better to add a sampler-waveform to Yoshimi or another soft-synth. Too bad I'm not that great a coder. Anyway, the idea seems so obvious now. Are there any good reasons for why not? I never used Specimen, but, from what I can gather, Specimen was more of a sample player with envelopes and LFOs than a sophisticated sampler. So, you might be able to get similar functionality by adding waveform functionality to a soft-synth. Note that this isn't meant to be a negative statement about Specimen. I'd like to propose a different idea. How about creating an LV2 plugin that focuses on sampler waveforms? Over time, real sampler functionality (loop points, velocity splits and layers, keyboard splits and layers, controller regions, mute groups, crossfading, etc.) could be added to the plugin. Other functionality that's common to synths and samplers (filters, envelopes, LFOs, etc.) could either be added to the plugin, or the dry output of your plugin could be sent to other plugins in an app like Ingen, allowing your sampler to be passed through as many filters, effects, etc. as there are plugins supported by whatever LV2 host is being used. Just an idea. :) -- Devin Anderson devin (at) charityfinders (dot) com CharityFinders - http://www.charityfinders.com/ synthclone - http://synthclone.googlecode.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Good Mixer Library
On Thu, Mar 31, 2011 at 9:32 PM, Patrick Shirkey pshir...@boosthardware.com wrote: I am just not sure that I can get away with discussing the topic in the open due to the possibility of being struck down by the almighty power of on high or bringing disrespect to those who are believers in the sacrosanct nature of the reigning King of Kings. I'm confused. Are you trolling about not trolling? -- Devin Anderson devin (at) charityfinders (dot) com CharityFinders - http://www.charityfinders.com/ synthclone - http://synthclone.googlecode.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [OT] IR: LV2 Convolution Reverb
On Tue, Feb 22, 2011 at 1:11 PM, Nick Copeland nickycopel...@hotmail.com wrote: This list as far as I can remember has always been full of righteous opinions, and by pretty much all of its subscribers, Paul. I think you're projecting. I love what you do for the audio community, but your demeaning behavior makes you look like an ass. Please stop. -- Devin Anderson devin (at) charityfinders (dot) com CharityFinders - http://www.charityfinders.com/ synthclone - http://synthclone.googlecode.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Transport issue for Qtractor - has impact to the jitter issue
On Thu, Jul 15, 2010 at 1:15 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: Devin and some others want to know if the drum module is played before FluidSynth DSSI is played. JACK2 doesn't start with -p4096, so I started JACK2 with -Rch -dalsa -dhw:0 -r44100 -p2048 -n2 to increase the unwanted effect, to get a clear result. Without recording it's clear audible that the external drum module always is played before FluidSynth DSSI is played, plausible regarding to the audio latency (stupid idea to use such high latency ;), so there's the need to do an audio test with lower latency, to see if jitter might change what instrument is played first. As we discussed yesterday, I don't think this is due to jitter. I think this is due to the fact that the (necessary) latency imposed by JACK on audio is not imposed on ALSA MIDI. The MIDI path to your soft-synth probably looks something like this: MIDI controller - MIDI in port - ALSA - Fluidsynth ... after which Fluidsynth generates audio that travels a path that's something like this: Fluidsynth - Jack - audio out ports Jack will impose a certain amount of latency on the audio before it's output to the audio out ports. In the case above, I think it would be around 90 milliseconds or so. There might be some other, minor latency (i.e. internal buffering, etc.), but IDK, as I haven't seen the code. The MIDI path to your external drum module probably looks something like this: MIDI controller - MIDI in port - ALSA - MIDI out port - external drum module ... after which the drum module generates audio that travels a path that's something like this: drum module - drum module out ports The drum module imposes some sort of latency, but it's clearly not as high as the latency imposed by JACK with the settings above. Note that nothing is routed through JACK on the way to the drum module. Solving this problem is complex. It's unlikely that your drum module allows you to specify its latency. AFAIK, you can't directly specify the latency of ALSA MIDI ports, but I have very little experience with ALSA and could be totally wrong. If Fluidsynth supports JACK MIDI, then you might solve this problem by routing your MIDI through JACK using the ALSA 'seq' or 'raw' interfaces. MIDI that runs through JACK is subject to the same latency as audio up until it reaches the MIDI drivers, after which it's up to the driver to sync audio and MIDI if the MIDI port isn't subject to the same latency as audio. I know that the FFADO driver in JACK 2 syncs MIDI closely with audio. After looking over the ALSA drivers, I'm pretty sure they try to sync MIDI with audio too by adding a delay of `nframes` to the time that the MIDI message goes out (I could be wrong, as the code for the ALSA MIDI drivers is a bit complicated). -- Devin Anderson devin (at) charityfinders (dot) com CharityFinders - http://www.charityfinders.com/ synthclone - http://synthclone.googlecode.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
