Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7535 discussions

[LAD] [ANN] Qtractor 0.6.3 - The Armed Hadron beta release!

by Rui Nuno Capela

Ah, the equinox... Twice a year a cherished planetary alignment checks in on schedule, once again. The little rock gets another round from its warmy solar furnax, from which were forged. The pale blue dot gets yet another round and to no surprise, another tinier dot gets here around: Qtractor 0.6.3 (armed hadron beta) is now released! Release highlights: * Revamped mixer (un)dockable panels (NEW) * Plugin preset selection sub-menu (NEW) * LV2 Time position/transport event support (NEW) * Constrained plugin multi-instantiation (FIX) * Automation curve node resolution (FIX) Qtractor is an audio/MIDI multi-track sequencer application written in C++ with the Qt4 framework. Target platform is Linux, where the Jack Audio Connection Kit (JACK) for audio and the Advanced Linux Sound Architecture (ALSA) for MIDI are the main infrastructures to evolve as a fairly-featured Linux desktop audio workstation GUI, specially dedicated to the personal home-studio. nb. Despite the old Qt4 stance, but still recommended, Qtractor does build, runs and does it all on Qt5 for quite some time now. However, the former recommendation prevails as the despicable LV2 plugin GUI X11/embedding support through libSUIL just does NOT work on modern Qt5. Website: http://qtractor.sourceforge.net Project page: http://sourceforge.net/projects/qtractor Downloads: http://sourceforge.net/projects/qtractor/files - source tarball: http://download.sourceforge.net/qtractor/qtractor-0.6.3.tar.gz - source package (openSUSE 13.1): http://download.sourceforge.net/qtractor/qtractor-0.6.3-13.rncbc.suse131.sr… - binary packages (openSUSE 13.1): http://download.sourceforge.net/qtractor/qtractor-0.6.3-13.rncbc.suse131.i5… http://download.sourceforge.net/qtractor/qtractor-0.6.3-13.rncbc.suse131.x8… - quick start guide & user manual (still outdated, see wiki): http://download.sourceforge.net/qtractor/qtractor-0.5.x-user-manual.pdf - wiki (help wanted!): http://sourceforge.net/p/qtractor/wiki/ Weblog (upstream support): http://www.rncbc.org License: Qtractor is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. Change-log: - Make the mouse-wheel to scroll the plugin list views, when not hovering a direct-access parameter slider. - Mixer widget gets (un)dockable Inputs and Outputs panels, also with their respective title captions. - Plugin instantiation is now constrained as much to prevent any audio channel output overriding. - Existing plugin presets may now be selected right(-click) from plugin list context-menu (ticket by Harry van Haaren, thanks). - So-called "painting" over multiple selected event values, while on the MIDI clip editor view pane below the main piano-roll (eg. note velocities, controller values, etc.) is now split into two similar painting modes, whether the sub-menu Edit/Select Mode/Edit Draw is set on (free-hand) or off (linear). - Drag-and-copy of plug-in instances across tracks or buses (ie. cloning) now also copies the direct access parameter setting (ticket by Holger Marzen, thanks). - File/Save As... now prompts and suggests an incremental backup name for existing sessions files. - Zooming in/out increment is now augmented by whether shift /ctrl keyboard modifiers are set (on a ticket request by Holger Marzen, thanks). - LV2 Time position event messages for plugin atom ports that support it is now being implemented. - Attempt to break extremely long audio file peak generation on session close or program exit (as reported by EternalX, thanks again). - MIDI Controllers Hook and Invert properties are now properly saved for tracks (after bug report by Nicola Pandini, thanks). - A segmentation fault when closing with VST plugins open has been hopefully fixed (after a patch by EternalX, thanks). - Messages standard output capture has been slightly improved as for non-blocking i/o, whenever available. - Automation curve node editing has been slightly improved in regard to time positioning and resolution. See also: http://www.rncbc.org/drupal/node/818 Enjoy && have fun. -- rncbc aka. Rui Nuno Capela

11 years, 4 months

[LAD] Some questions about the Jack callback

by Will Godfrey

Just trying to get a clearer understand so hope these aren't too noob-ish. If you have several processes wanting to send audio, does the callback go to all of them at (essentially) the same time, or does Jack poll them? If the former, is it the quickest to complete that gets processed first? If the latter, does Jack maintain the same order (assuming none stop) or might it change between buffers? I've a few more questions but they depend on whether either of these scenarios is correct! -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

11 years, 4 months

[LAD] Fw: Re: Some questions about the Jack callback

by Fons Adriaensen

On Sat, Sep 20, 2014 at 04:10:13PM -0400, Mark D. McCurry wrote: > On 09-20, Fons Adriaensen wrote: > > Having to do 256 1024-point FFTs just to start a note is insane. > > It almost certainly means there is something fundamentally wrong > > with the synthesis algorithm used. > > I agree with that notion. > In typical patches something between 2-10 IFFTs is expected and even this > cost strikes me as too high (zero IFFTs for pure PAD/SUB synth based). > In terms of worst case scenarios ZynAddSubFX can have some rather insane > characteristics given multiple parts, kits, voices, etc. > For instance if a user decided to use all padsynth instances at max quality, > they would need 12GB of memory just to store the resulting wavetables. > > Such extremes are not really seen in practice, but things are slowly getting > optimized to avoid them when possible. You should really look at this from an information theory POV, combined with some psycho-acoustics. Suppose you have to deliver 256 samples in a period when a note starts. That amounts to around 5.3 ms at 48 kHz. That time limits the amount of spectral detail that can be detected given the output from the first period. Which means that there is no point in generating more detail in the first period of a note. Even on sustained notes the amount of spectral detail that can be detected by a human listener is limited by the critical bandwidth of human hearing (which increases with frequency). That means that any set of harmonics that fall within a critical bandwidth can be replaced by a single one with the same energy and nobody would be able to hear the difference. All this means that you *never* need 256 harmonics, not even on bass notes below Fs / (2 * 256). And if the final output is a weighted sum of those IFFT outputs you can as well compute the weighted sum of the inputs and then do a single IFFT - it's a linear transform after all. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ----- End forwarded message ----- -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

11 years, 4 months

Re: [LAD] Some questions about the Jack callback

by Mark D. McCurry

On 09-20, Fons Adriaensen wrote: > Having to do 256 1024-point FFTs just to start a note is insane. > It almost certainly means there is something fundamentally wrong > with the synthesis algorithm used. I agree with that notion. In typical patches something between 2-10 IFFTs is expected and even this cost strikes me as too high (zero IFFTs for pure PAD/SUB synth based). In terms of worst case scenarios ZynAddSubFX can have some rather insane characteristics given multiple parts, kits, voices, etc. For instance if a user decided to use all padsynth instances at max quality, they would need 12GB of memory just to store the resulting wavetables. Such extremes are not really seen in practice, but things are slowly getting optimized to avoid them when possible. The biggest flaw in the algorithm besides the current high cost of initialization is the use of some adaptive harmonics routines which do some frequency dependent spectral modifications before the IFFT. More or less that chunk of math will end up resulting in some inaccuracies when converting to any normal wavetable representation which will avoid the IFFT. Changing over to a wavetable approach will make other parts of the algorithm more correct than they currently are, but there's tradeoffs between correctness and consistency between versions. --Mark (Oops, it looks like I missed the ML the first time I sent this)

11 years, 4 months

[LAD] Production release 0.4.2 planed of Advanced Gtk+ Sequencer

by Joël Krähemann

Hi, as mentioned in subject: Production release 0.4.2 planed of Advanced Gtk+ Sequencer. Now, comes your part I would like you to test functionality. I'll do for you a wiki page of aspects to test. Please visit http://ags.sf.net and wiki page https://sourceforge.net/p/ags/wiki/testing-cheatsheet/ Happy to hear of you pretty soon! Joël

11 years, 4 months

[LAD] [ANN] Vee One Suite 0.5.1 - One second official beta release!

by Rui Nuno Capela

Howdy, The gand-of-three aka. the Vee One Suite of old-school soft(ware)-instruments, featuring synthv1 [1], a polyphonic synthesizer, samplv1 [2], a polyphonic sampler and drumkv1 [3], as a drum-kit sampler, are once again released in beta phase though. The changes for this one second beta release are the following: - Fixed LV2 plugin relative/absolute file path state resolution. (drumkv1 [3] only). - One decimal digit added to all scalar parameters and knobs. - Stand-alone JACK client ports outrageously renamed from a zero based numbering scheme into a plus one natural one. - Experimental LV2 Time/position atom-event support (Delay BPM). Please, don't hesitate to ask whether any of the above esoteric babbles doesn't get you on to update as soon as you can. One special note goes for all the users out there of drumkv1 [3] LV2 genre: the update is not just interesting but a must, seriously ;). As usual, all is available in dual form: - a pure stand-alone JACK [4] client with JACK-session, NSM [5] (Non Session management) and both JACK MIDI and ALSA [6] MIDI input support; - a LV2 [7] instrument plug-in. The Vee One Suite are free and open-source Linux Audio software, distributed under the terms of the GNU General Public License (GPL) [8] version 2 or later. The gore details are as follows ;) * synthv1 - an old-school polyphonic synthesizer [1] * synthv1 0.5.1 (second official beta) is out! synthv1 is an old-school all-digital 4-oscillator subtractive polyphonic synthesizer with stereo fx. LV2 URI: http://synthv1.sourceforge.net/lv2 website: http://synthv1.sourceforge.net downloads: http://sourceforge.net/projects/synthv1/files - source tarball: http://download.sourceforge.net/synthv1/synthv1-0.5.1.tar.gz - source package: http://download.sourceforge.net/synthv1synthv1-0.5.1-18.rncbc.suse131.src.r… - binary packages: http://download.sourceforge.net/synthv1synthv1-0.5.1-18.rncbc.suse131.i586.… http://download.sourceforge.net/synthv1synthv1-0.5.1-18.rncbc.suse131.x86_8… * samplv1 - an old-school polyphonic sampler [2] * samplv1 0.5.1 (second official beta) is out! samplv1 is an old-school polyphonic sampler synthesizer with stereo fx. LV2 URI: http://samplv1.sourceforge.net/lv2 website: http://samplv1.sourceforge.net downloads: http://sourceforge.net/projects/samplv1/files - source tarball: http://download.sourceforge.net/samplv1/samplv1-0.5.1.tar.gz - source package: http://download.sourceforge.net/samplv1/samplv1-0.5.1-18.rncbc.suse131.src.… - binary packages: http://download.sourceforge.net/samplv1/samplv1-0.5.1-18.rncbc.suse131.i586… http://download.sourceforge.net/samplv1/samplv1-0.5.1-18.rncbc.suse131.x86_… * drumkv1 - an old-school drum-kit sampler [3] * drumkv1 0.5.1 (second official beta) is out! drumkv1 an old-school drum-kit sampler synthesizer with stereo fx. LV2 URI: http://drumkv1.sourceforge.net/lv2 website: http://drumkv1.sourceforge.net downloads: http://sourceforge.net/projects/drumkv1/files - source tarball: http://download.sourceforge.net/drumkv1/drumkv1-0.5.1.tar.gz - source package: http://download.sourceforge.net/drumkv1/drumkv1-0.5.1-14.rncbc.suse131.src.… - binary packages: http://download.sourceforge.net/drumkv1/drumkv1-0.5.1-14.rncbc.suse131.i586… http://download.sourceforge.net/drumkv1/drumkv1-0.5.1-14.rncbc.suse131.x86_… References: [1] synthv1 - an old-school polyphonic synthesizer http://synthv1.sourceforge.net/ [2] samplv1 - an old-school polyphonic sampler http://samplv1.sourceforge.net/ [3] drumkv1 - an old-school drum-kit sampler http://drumkv1.sourceforge.net/ [4] JACK Audio Connection Kit http://jackaudio.org/ [5] NSM, Non Session Management http://non.tuxfamily.org/nsm/ [6] ALSA, Advanced Linux Sound Architecture http://www.alsa-project.org/ [7] LV2, Audio Plugin Standard, the extensible successor of LADSPA http://lv2plug.in/ [8] GNU General Public License http://www.gnu.org/copyleft/gpl.html See also: http://www.rncbc.org/drupal/node/815 Enjoy && have fun. -- rncbc aka. Rui Nuno Capela

11 years, 5 months

Re: [LAD] [LAU] Open Source Audio Interface

by Len Ovens

I thought I would move this over here. I know there is already work being done on this hw wise. These thoughts are for a point to point raw ethernet audio transport That still allows some normal network traffic as well. On Tue, 2 Sep 2014, Len Ovens wrote: > My thought is something like this: > We control all network traffic. Lets try for 4 words of audio. For sync > purposes, at each word boundry a short audio packet is sent of 10 channels. > This would be close to minimum enet packet size. Then there should be room > for one full size enet packet, in fact even at 100m the small sync packet > could contain more than 10 channels (I have basically said 10m would not be > supported, but if no network traffic was supported then 10m could do 3 or 4 > channels with no word sync). So: > Word 1 - audio sync plus 10 tracks - one full network traffic packet > word 2 - audio sync plus 10 tracks - one full audio packet 40 tracks > split between word 1 and 2 > wors 3 - audio sync plus 10 tracks - one full audio packet 40 tracks > split between word 2 and 3 > word 4 - audio sync plus 10 tracks - one full audio packet 40 tracks > split between word 3 and 4 Nobody commented that this could not work :) 4 samples on a 100mbit link is still less than one full 1500byte data packet. The reason I am thinking about this right now, is that my studio has been flooded :P and so I have no access to work on my control surface project right now. So some background thinking: - The idea is to replace FW audio interfaces with something at least as good, maybe better. - Really low latency available (even if a lot of uses don't need it) - Really stable operation. On a desktop/rack computer where the user has access to a PCIe slot, it is obvous that a second NIC would be the best solution. Laptops should work too. - Normal network traffic will make it through this mess without ever disturbing the audio. A laptop may be used with only one NIC and still need to access network traffic. - It should "just work" on newer network hw as it is developed. - It should handle a switch in the middle for use as a range extender, but never as a network traffic mixer. (on a 1gbit link other traffic may not disturb things with low enough channel count) What I have thought of so far would tend to ignore other traffic anyway and a switch should end up just sending our traffic through our ports. This situation may require some user intervention such as pointing out which box they wish to connect to. - It should deal well with hot plugging. This feels messy, but it should be possible to let things like netman play with things first and still be able to detect an audio IF has been connected and reinit the interface for this use. In the end, the kernel module for this device should be loaded anytime a NIC is detected. (detected and has a connection) It should create both an eth* device and an ALSA device, but should only do so if it detects an audio IF online. To begin with, this would mean the user would have to do some setup to get around all the auto setup stuff already running (dhcp etc.) But as the IF was used more, normal networking stuff might be expected to detect an audio IF and leave it alone. Maybe the audio IF could have a dhcp server that refused an IP so that the dhcp client gives up and goes away. That is, use network protocols that are already available when possible. This whole effort assumes the ethernet device is connected by twisted pair from the host computer to the audio device with a separate path for each direction. This is very important as it _should_ make for a colision free environment. This interface will control both audio and data flow. Any network traffic will only be sent during times audio sending is not needed. This can be done because all network data will go through the audio driver. There are still a lot of 100mbit networks out. Lots of new equipment still has them too. I have chosen a 4 sample frame at 48k (which happens to be 16 samples for 192k... if you must) because it seems to be the lowest latency with reasonable use of overhead. (on Gbit and higher lines, this is no longer true. The internet still runs on 1500MTU and more than one full packet will travel in one sample's time) I have done all my calculations based on a 100mbit line because that happens to be what I have to play with and appears to be able to handle up to 60 audio channels with some left over for control. I understand that there are venues that use more, but gbit links will handle lots more. (600 plus, but realize the systems on each end have to be able to deal with the data as it comes in, it is not just about the link capabilities) So, My thought is that each group of packets sent will be timed by a group of 4 samples. The driver will attempt to send a packet with 4 samples worth of audio for all channels at the end of those 4 samples. The driver then calculates how much time it has before another 4 sample times are up and sends as much data as it has time for. This calculation should be able to happen only one time for any channel number setup if the hw is not doing anything too fancy (like waiting for more than one packet before it sends). It assumes the hardware/driver uses standard size guard bands, etc. SO for each 4 samples there would be two packets minimum (probably maximum too for a 100m link). One audio and one data. On a 100m link these packets would always have an mtu of less than 1500. It would not be possible to use the arrival of an audio packet as a sync signal, sync as always, would be an external line if two audio interfaces needed to be used. I expect to have an atom based MB to play with soon that has two NICs on board. as well as an audio IF. This will not be a true test low latency because the onboard AI has higher latency to begin with (runs at p64/n3 min) and so I will have 192 samples to play with at a time which I will still try sending in 4 sample bundles. (I may try putting an older PCI AI in to see if I can get that down a bit) My thought is to make the AI side a jack client (I think I can do that much :) and the host side an ALSA device (something new to learn). All control will be MIDI-able. Because there is two NICs and one of them expects to do real IP based networking, OSC is possible as well as web based control. IN the end this is also a general computer running Linux that can be SSHed into (even ssh -Y) almost anything is possible... but I would guess the first box that has a real DIY digital CODEC, S/pdif, ADAT or MADI IF will be pretty basic.... but looking at the R-Pi, basic seems to be pretty powerful anymore. In the long run this could be a very interesting device. There is no reason this could not also be, an effects box (both with local analog ports as well as through net), a softsynth (most of these boards have at least one serial port or USB), A remote mixer... drop the box FOH and use a networked control surface, Android pad... even a browser to control, a FOH snake box or even a standalone recording device. Price point? Concidering ethernet switches, USB AUdio devices, Ethernet storage controllers, set top... I hesitate to call them boxes some of them are so small? Even development boards look ok. I don't think It would be worth while to make a two i/o box, but by the time we hit 8 or so it begins to look good. -- Len Ovens www.ovenwerks.net

11 years, 5 months

[LAD] Digital Effects

by tom＠trellis.ch

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

11 years, 5 months

[LAD] Half-OT: Fader mapping - was - Ardour MIDI tracer

by Grekim Jennings

> Partly also for historical reasons, I think. In many ways digital > recording started as the "poor man's tape". Direct to disk recording with > no effects was at first all that could be handled and most peole using it > were replacing 8 track tape with it. They already had a mixer. As the DAW > developed, mix down on the computer has been next. But for many people the > recording part of the strip has been outside of the DAW, on an analog > mixer. This is changing as a new batch of people are going mic-> > interface. Their input strip is whatever the interface provides... often > only trim (either as a pot on the pre or in ALSA). Is this for convenience or not having the ability to afford something else? I think a lot of times money is spent on the wrong thing such as buying a fancy multicore computer when something from 8 years ago is totally adequate for digital audio. > > So digital recording is > also going through a two mixer to inline transition. From hybrid to > digital only. The trim controls are there, where they should be, as close > to incoming signal as possible. I don't suppose it would be too hard to > add alsa trim for a card like the d1010 to ardour, but many USB IFs (even > PCIe) have no controls in alsa. It is a physical pot somewhere. So rather > than being in front of the engineer, it is hidden and easily missed by the > newby... or even not so new. So much is done digitally, that the remaining > analog items are forgotten. This is a real problem with a two input IF, > The trim needs to be set every time and the variety of signals through one > channel is huge. Everything from a ribbon to line level. Having a set of > good pre amps could be worth while, this is probably the biggest hole in > the hobby studio. I have two, tube and solid state. (plus line) It is very simple to keep a few notes on what is a good preamp setting for a given mic and preamp combination. One inconvenience with some budget preamps is that you don't know what sort of gain it is providing, so while you may write down the setting by using a notation like 2:00 for dial position, you haven't learned anything about gain, so if you swap out a preamp you need to guess at where to start. You can get into trouble with a mismatch between preamp and converters, such that you are trying to "maximize bits" by getting a hot signal level into your converters. The preamp ends up distorting and you have a hi-res recording of a distorted sound! I actually had this problem with a remake of a vintage preamp. So it seems every preamp has a voltage sweet spot that it should be operated in. The best situation is if you have converters with analog trims, which is I think what you were saying, and set them accordingly for each preamp. I leave my preamps plugged into a specific A/D channels that have been calibrated for that preamp. One other note, some budget preamps are not qualified for certain levels of input. I have a Presonus Audiobox which can sound fine for an acoustic guitar, but throw a drum at it and it is automatically over full scale and unusable. Grekim

11 years, 5 months

[LAD] Hydrogen - multi banks per instrument

by Aurélien Leblond

Hello, I'm currently working on a feature for Hydrogen to have multi banks per instrument. In a nutshell, if you have drum samples with direct and overhead recordings, you can put those together under the instruments - one instrument Snare for example with the band direct and the bank overhead). In the Hydrogen mixer, you can chose how much direct or overhead is needed, changing completely the tone of the drums. You can chose how many banks you have per instrument, and the gain of each bank in a given instrument. A very (very very.......veryveryvery) early version is available here: https://github.com/blablack/hydrogen Very early version as the main feature works, but for example I highly doubt saving/loading songs would work just yet and the mixer GUI goes a bit crazy when banks are added/removed, I'm in the process of a massive testing/bug hunt... I would be very interested to get some early feedback, both on the feature and (for the most courageous) on the code itself. Thanks in advance ladies and gentlemen! Aurélien

11 years, 5 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