Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7535 discussions

Re: [LAD] Plugin buffer size restrictions

by Jeff McClintock

> I assume that computing parameter trajectories basically means > interpolating, and that inevitably introduces some latency. That's a key point. Interpolating any sampled signal introduces latency. > let the host pass a limited number of future parameter samples at each > run() (could be negotiated at instantiation time), so that the plugin > doesn't have to add latency to the audio streams in any case. Would be > only supported by "offline hosts". If the block sizes are variable, > future block sizes should be passed as well (argh?). But I don't know > if this really makes sense or has downsides... ideas, folks? I *really* hate this idea. I play my MIDI keyboard into my DAW, perhaps while using my Mod-Wheel, or artistically using the filter-cuttoff parameter...I hit record...stop.. Then I push 'offline render'. You would say - shift all my parameter events earlier in time and render the result to disk? It's going to sound different. The timing will be wrong. A DAW is like a tape recorder. Playback or offline rendering should result in an identical performance surely?. Why are you selectively shifting some musical events in time but not others, why not note-ons too? You can't provide live MIDI playing 'in advance', you can't prove parameter updates in advance, just like you can't provide live audio in advance. If the plugin wants 'future' data to interpolate stuff, it needs to introduce latency. A good host will compensate for latency if the plugin API supports that. Parameters aren't special, they don't require any different handling than MIDI. What's the difference between a MIDI controller tweaking the filter cuttoff, or directly tweaking the parameter? Nothing. They both need smoothing, they both need interpolating, they both will have latency. Don't overcomplicate it. Jeff

13 years, 8 months

[LAD] [OT] need help from a Qt guru re: slow graphics

by Dave Phillips

Greetings: The problem: When I build Kdenlive for my Arch 64 system it compiles without problems and starts up okay. After that the sluggishness of its response is almost unbearable. For example, I've timed up to 10 seconds between a mouse click and the resulting action, e.g. right-click to Add Clip, and everything stalls badly when the program is calculating audio or video thumbnails. Response time gets better after running the program for a while, but getting it going is rather frustrating. I've already searched Google and asked about the problem on the Kdenlive forum and got no useful replies, hence my request here. Some of you use Arch systems, and some of you know Qt well enough that maybe you can advise me on this problem. (I'm hoping for a relatively simple solution, of course). Incidentally, the problem occurs with Arch's packaged Kdenlive and the binary I compile with the build script. I just upgraded both, the problem is still there. Other large Qt apps don't have the problem, e.g. QTractor. The problem is also absent with Kdenlive on my 32-bit machines. Btw, video is an nVidia GeForce 7600 GS, with nVidia's driver. Best, dp

13 years, 8 months

[LAD] Virtual Analog Filters | Fwd: [music-dsp] ANN: Book: The Art of VA Filter Design

by Florian Paul Schmidt

Maybe this is of interest to one or the other :D Flo -------- Original Message -------- Subject: [music-dsp] ANN: Book: The Art of VA Filter Design Date: Fri, 25 May 2012 10:54:25 +0200 From: Vadim Zavalishin <vadim.zavalishin(a)native-instruments.de> Reply-To: A discussion list for music-related DSP <music-dsp(a)music.columbia.edu> To: A discussion list for music-related DSP <music-dsp(a)music.columbia.edu> Hi all This is kind of a cross-announcement from KVRAudio, but since there are probably a number of different people on this list, I thought I'd announce it here as well. Get it here: http://ay-kedi.narod2.ru/VAFilterDesign.pdf http://images-l3.native-instruments.com/fileadmin/ni_media/downloads/pdf/VA… http://www.discodsp.net/VAFilterDesign.pdf (thanks to "george" for mirroring) There is a discussion thread at http://www.kvraudio.com/forum/viewtopic.php?t=350246 Regards, Vadim -- Vadim Zavalishin Software Integration Architect | R&D Tel +49-30-611035-0 Fax +49-30-611035-2600 NATIVE INSTRUMENTS GmbH Schlesische Str. 29-30 10997 Berlin, Germany http://www.native-instruments.com Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458 UST.-ID.-Nr. DE 20 374 7747 Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp

13 years, 8 months

[LAD] simple FAUST OSC example

by Kaspar Bumke

Hi all, I am trying to wrap my head around the OSC interface to FAUST and am trying to get the noise.dsp from the examples to respond to OSC messages. I have tried sending it things like "/hello" and "/1/slider1 s 'hello'" and "/hello f 1.0" on port 5010 while listening on 5011 and 5012 to no avail. I must be completely missing something here but what exactly am I supposed to send when it says "a hello message" in the docs? Could someone just go through all the simple steps of an OSC "hello world" in FAUST? Kind Regards, Kaspar

13 years, 8 months

[LAD] Proposals for JACK

by Nikita Zlobin

Hi all. Just returned from military services (mandatory period). It is likely, that i was somehow unsubscribed from list. In summary, proposed changes are joined in two parts: 1. A few advances for freewheel mode: waiting wheel and per client free/waiting wheel mode. 2. Get support for any count of "rooms", as they are called in LADISH therminology, but IMHO, a bit more flexible. Waiting wheel. Like freewheel, but doesn't speed up system. When performance is enough, behave like without any mode (produce sound). And only when it is not enough, automatically free wheel, until performance is enough again. Per client time wheel management. Clients could be joined into groups, where they have own time flow and may interact as they are not in free/waiting wheel mode (pass sound/MIDI each to others). Other proposals, in two words: - Ability to change master client (for now it is audio card) on the fly. - Attaching of audio devices as clients with ability to change driver and its settings for each (i mean - for all devices; this feature should go with previous item). Now about sctucture. Some components are plugins, which are like LADSPA / LV2 / Other kinds of audio plugins, but are optimized for use only on JACK (in short, they are JACK modules). JACK components: * single plugin shell (types: plugin host, jack / alsa app) - just to load other plugins as audio applications, connecting them to other audio systems, like alsa or other jack instance, like jack app. * Patchbay (types: plugin host, plugin). Master instance should be ran by already called plugin shell. Other instances may be loaded as plugins (making more rooms), or as jack applications. Time wheel mode changes affect all dependent clients, inluding other patchbays. * JACK app interface (plugin) * Adapter for other types of audio plugins (LADSPA, LV2, and so on). As you can see, such jack implementation may be jack app itself, and so - it is good to use existing work just as plugin host (like AMS, Ingen, Jost). Such jack structure should allow easy implementation of both multiroom session managers, like LADISH (which is forced for now to implement it by self) and even allow nested sessions: i'm thinking about universal modular session manager, which could be used as user session manager, but also allow nested desktop sessions, and could be expanded by plugins, adding integration to various systems, like X11 (to manage windows), jack / alsa (no comments needed) and so on.

13 years, 8 months

[LAD] Faust MIDI?

by Carlo Capocasa

Hi, is it possible to send and receive MIDI with a FAUST program? Carlo

13 years, 8 months

[LAD] Can an LV2 plugin legally modify input port values?

by Jeremy Salwen

It's not clear to me what is legal for an LV2 plugin to do with an input control port. Once the input port has been read, is it acceptable to use that location in memory as temporary storage in the "run" method? Is it the host's responsibility to re-fill the value of the parameter before every run call? Is it the plugin's responsibility to keep input-ports bit-exactly the same? What about transformations of the input which leave the value logically the same? For example, normalizing boolean inputs the values 0 and 1? The <http://lv2plug.in/ns/lv2core/#InputPort> documentation<http://lv2plug.in/ns/lv2core/#Port>is silent on this matter. Jeremy

13 years, 8 months

[LAD] [ANN] QmidiNet 0.1.2 released!

by Rui Nuno Capela

A pretty old and terribly overdue JACK MIDI crash bug as been fixed. Hopefully at last. Ones who've been using the ALSA-MIDI (aka. ALSA Sequencer) interface exclusively don't need to worry. All the rest please apply ;) QmidiNet 0.1.2 released! Have fun! QmidiNet [1] is a MIDI network gateway application that sends and receives MIDI data (ALSA-MIDI and JACK-MIDI) over the network, using UDP/IP multicast. Inspired by multimidicast [2] and designed to be compatible with ipMIDI [3] for Windows. See also: http://www.rncbc.org/drupal/node/508 Website: http://qmidinet.sourceforge.net Project pages: http://sourceforge.net/projects/qmidinet Downloads: - source tarballs: http://downloads.sourceforge.net/qmidinet/qmidinet-0.1.2.tar.gz - source package (openSUSE 12.1): http://downloads.sourceforge.net/qmidinet/qmidinet-0.1.2-1.rncbc.suse121.sr… - binary packages (openSUSE 12.1): http://downloads.sourceforge.net/qmidinet/qmidinet-0.1.2-1.rncbc.suse121.i5… http://downloads.sourceforge.net/qmidinet/qmidinet-0.1.2-1.rncbc.suse121.x8… Weblog (upstream support): http://www.rncbc.org License: QmidiNet is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. Change-log: - JACK MIDI in-bound buffering was originally flawed and often the cause for severe random crashes, mostly due to memory corruption, now hopefully fixed. - Changed order of JACK MIDI and UDP socket initialization, hoping the later is always owned by the current genuine process. - JACK MIDI interface were sinking all incoming events into the the first port, now fixed (heads up from Chris Goddard, thanks). - Make(ing) -jN parallel builds now available for the masses. - Fixed Makefile.in handling of installation directories to the configure script eg. --datadir. - Main context menu simple no-brainer reordering. References: [1] QmidiNet - A MIDI Network Gateway via UDP/IP Multicast http://qmidinet.sourceforge.net [2] multimidicast - sends and receives MIDI from ALSA sequencers over network http://llg.cubic.org/tools/multimidicast [3] ipMIDI - MIDI over Ethernet ports - send MIDI over your LAN http://nerds.de Cheers && Enjoy -- rncbc aka Rui Nuno Capela

13 years, 8 months

[LAD] Open Audio Programming Tutorials

by Harry van Haaren

Hey All, After some very inspiring conversations at the LAC, I have decided to renew the efforts to document linux audio programming for beginners. I feel that although there's a lot of really useful tutorials out there, but there's still a lack of easy accessible introductory audio programming. Particularly topics such as threading, and thread synchronization are particularly difficult to learn, or even find relevant, easy to read code about. Announcing: Open Audio Programming Tutorials! This is a documentation effort, not of any particular library or tool, just "Linux Audio Programming" in general. Feel free to check the code posted, feedback on it, fork it and send me merge requests, whatever :) Currently there's 6 different tutorials, all C++ with GTKmm for user interfaces. Intentions are to add more as time permits! -Harry PS: Sending to Linux-Audio-User list in case there's people who want to try start programming, but haven't subscribed to the Linux-Audio-Developers list (yet). Replies to Linux-Audio-Developers please :)

13 years, 9 months

[LAD] New SVN version of LV2:AVW - Crashes Ingen

by Aurélien Leblond

>> I have been trying to use GDB to debug this issue. >> Problem is, as the program crashing is Ingen, I get the information as to >> where it crashes in Ingen, not where the problem lies in my plugin. >> >> Would anybody have any ideas as to how to tacke this issue? >> > > If the plugin runs in a different process, > it may be necessary to attach that process to gdb. > Don't forget to compile with debug enabled. Thanks for that. I have tried to approach so far: * gdb --args ingen -eg I would then run my plugin, remove it, Ingen would crash, but I would get the information as to why Ingen crashed. I'm not even sure that GDB would see that it should debug the vco2.so as well * gdb vco2.so (vco2.so being the name of my plugin) Now I start Ingen, get the PID, and use attach 15674 in gdb (I tried with or without the plugin running). I get the following error message in GDB: (gdb) attach 15764B Attaching to program: /home/blablack/src/avw.lv2/build/avw.lv2/vco2.so, process 15764 Could not attach to process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf ptrace: Operation not permitted. I guess GDB is looking for the vco2.so when attaching... So what stupid thing am I doing? Thanks in advance for the help, Aurélien

13 years, 9 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev