Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

1 participants
7518 discussions

by Yury Alyaev

Hi all, Industrializer generates synthesized percussion sounds using physical modelling. The range of sounds possible include but is not limited to cymbal sounds, metallic noises, bubbly sounds, and chimes. After a sound is rendered, it can be played and then saved to a .WAV file. I think Power Station Industrializer v0.2.7 is matured enough to be released :-) It contained only few minor changes compared to the latest pre-release, but is tested well. You can download it here: https://sourceforge.net/projects/industrializer/files/ 0.2.7 release contains the following main new features (compared with v0.2.6): - Discretization rate selection for both playback and WAV export - Improved accuracy of setting some parameters - Rendering and playback can be interrupted. Playback can be retrigged at any time - Both actuation and sampling nodes are made selectable. This facility allows you to vary somehow the timbre of the sound and even create stereo samples with some phasing effects. Although Industrializes cannot directly deal with stereo samples, you can first render and save a sample, then change the sampling node without touching the other parameters and render another sample, after that use these samples as left and right stereo channels. Regards, Yury.

4 years

[LAU] [LAA] Guitarix2 release version 0.43.0

by Hermann Meyer

I'm pleased to announce the release of guitarix2-0.43.0 A virtual guitar amplifier for Linux running with jack (Jack Audio Connection Kit) released under the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This is a maintenance release. Fixing a couple of bugs and make the source code fit for newer compiler and library's. Changelog: * Fix build on gcc 11 * Add Fizz Remover * Implement option to enable jack session support (--jack-session) * Fix Unnatural decay at high gain (palm mutes) * Fix Fuzz Face Mayer * Add 41 tet tuner option (by Tristan Tarrant) * Fix GxAmplifiers cycling through cabinets/pre-amps/tubes is skipping items * Remove glibmm dependency from LV2 plugs * Update used faust version to 2.37.3 * Add option in GxAmplifiers to allow switch between Bass/Guitar input * Add metadat.xml file * Add X-NSM-Capable entry in .desktop file Release tarball: https://github.com/brummer10/guitarix/releases/download/V0.43.0/guitarix2-0… Project Page on github: https://github.com/brummer10/guitarix Project Page on SourceForge: https://sourceforge.net/projects/guitarix/

4 years

International Faust Conference 2022

by Stéphane Letz

IFC-22. The International Faust Conference will take place on June 7-8, 2022, in Saint-Etienne, France (in conjunction with SMC-22). We hope that many of you will come to celebrate the 20th anniversary of Faust! The call for papers and all practical information are available here: https://smc22.grame.fr/ifc.html Stéphane

4 years

Problems with Linuxsampler as VST and LV2

by Daniel Swärd

Hi all. I'm having a bit of a problem using the Linuxsampler VST and LV2 plugins (version: 5:2.1.1-1kxstudio5). For VST host I have tried with both Bitwig Studio and carla, but there's no GUI showing up. For LV2 host I've used carla, and then the only response I get is a dialog saying it failed to initialize the plugin. If I try to use Linuxsampler configured via qsampler, everything just works fine. Can someone maybe confirm that they have the same problem? Cheers /Daniel

4 years

Re: [LAD] LAD] FPGA programming and embedded Linux in the FAST project (https://fast.grame.fr)

by _low_show

Hi Stéphane I don't have the skills required for this role, but I'm really interested in this project from an interface development/ usability point of view. That is, the ease of designing and building custom physical interfaces to communicate with the underlying system. Additionally, this extends to the usability of the system as a whole (esp. from the POV of non-engineers). Is there somewhere I can track the progress (or even somehow contribute to/ participate in) of this aspect of the project? Thanks! Louis On Mon, 29 Nov 2021, at 12:00, linux-audio-dev-request(a)lists.linuxaudio.org wrote: > Send Linux-audio-dev mailing list submissions to > linux-audio-dev(a)lists.linuxaudio.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.linuxaudio.org/listinfo/linux-audio-dev > or, via email, send a message with subject or body 'help' to > linux-audio-dev-request(a)lists.linuxaudio.org > > You can reach the person managing the list at > linux-audio-dev-owner(a)lists.linuxaudio.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Linux-audio-dev digest..." > > > Today's Topics: > > 1. Compilation/System Engineer Position (18 Months) — > Fixed-Point Extension for the Faust Programming Language — FAST > Project (Stéphane Letz) > 2. FPGA programming and embedded Linux in the FAST project > (https://fast.grame.fr) (Stéphane Letz) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 29 Nov 2021 10:57:56 +0100 > From: Stéphane Letz <letz(a)grame.fr> > To: linux-audio-user(a)lists.linuxaudio.org, > linux-audio-dev(a)lists.linuxaudio.org > Subject: [LAD] Compilation/System Engineer Position (18 Months) — > Fixed-Point Extension for the Faust Programming Language — FAST > Project > Message-ID: <520087B8-5A83-4EB7-AC28-96D999B3239A(a)grame.fr> > Content-Type: text/plain; charset=utf-8 > > We’re currently looking for compilation/system engineer to work on the FAST project for a period of 18 months. > > See more informations here: https://team.inria.fr/emeraude/job-offers/ > > Stéphane > > ------------------------------ > > Message: 2 > Date: Mon, 29 Nov 2021 11:21:52 +0100 > From: Stéphane Letz <letz(a)grame.fr> > To: linux-audio-user(a)lists.linuxaudio.org, > linux-audio-dev(a)lists.linuxaudio.org > Subject: [LAD] FPGA programming and embedded Linux in the FAST project > (https://fast.grame.fr) > Message-ID: <F33133D7-DC24-4A3A-A1CA-A009640F80FE(a)grame.fr> > Content-Type: text/plain; charset=utf-8 > > The job offer is here: https://recrutement.inria.fr/public/classic/en/offres/2021-03921 > > Stéphane > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > https://lists.linuxaudio.org/listinfo/linux-audio-dev > > > ------------------------------ > > End of Linux-audio-dev Digest, Vol 177, Issue 3 > *********************************************** >

4 years

FPGA programming and embedded Linux in the FAST project (https://fast.grame.fr)

by Stéphane Letz

The job offer is here: https://recrutement.inria.fr/public/classic/en/offres/2021-03921 Stéphane

4 years

Compilation/System Engineer Position (18 Months) — Fixed-Point Extension for the Faust Programming Language — FAST Project

by Stéphane Letz

We’re currently looking for compilation/system engineer to work on the FAST project for a period of 18 months. See more informations here: https://team.inria.fr/emeraude/job-offers/ Stéphane

4 years

XUIDesigner v0.3 released

by Hermann Meyer

Goal Provide a easy to use GUI generator tool to create X11 UI's for LV2 plugins. Currently only libxputty is supported, but the generated GUI C file could be used probably with other widget tool-kits as well, just a wrapper file is needed to translate the generated file to the needs of a toolkit. Currently state XUiDesigner parse the ttl file from a selected plugin and generate the needed controller widgets. Supported been the usual lv2:port parameter and as well the new atom based LV2_PATCH__writable and LV2_PATCH__readable so as LV2_ATOM__Path. XUiDesigner use the environment variable LV2_PATH to scan for plugins when no path is given with the -p command-line parameter. So you could easily create a GUI for a existing plugin. A integrated Color chooser allow to create a Color theme for your GUI. The created GUI could be saved as UI-Bundle, which then could be build (just make) and installed (just make install) to replace or provide a new GUI for the plugin. You could as well create a LV2 plugin from scratch and save it as Full Plugin-Bundle to a selected location. The project settings window allow to setup the specs (like Author name, URI, Audio/Midi ports, etc.) for your plugin XUIDesigner save the bundle in a git repository format, contain a working LV2 plugin with all needed resources (ttl files, converted C files from used images, etc.) and build files to build, install and run the new generated plugin. All you need to do to finish your plug is to implement your DSP part. Control widgets could be created and moved/resized freely around in the top Window. A grid could be displayed and widgets could snap to grid (left, right, Center) to order them easily. Control widgets could be grouped in a frame or a tab box and then the complete group could be moved to the final position in the Window. Any control widget could be replaced with a other control widget, so for example a Toggle Button could be replaced with a ComboBox, or a Knob could be replaced with a slider, or . . You could set the range for a controller, and it's default value, You could create enums for a ComboBox, . . Most Control widgets could be replaced with images you could select from a included file browser. XUIDesigner have a test-mode as well, which will build and run the created GUI, and give some useful information out in the terminal. Currently supported widget types * Knob -> support horizontal framed png/svg * HSlider * VSlider * Button -> support png/svg/horizontal framed png/svg * Toggle Button -> support horizontal framed png/svg * ComboBox * Value Display * Label * VMeter * HMeter * Frame * TabBox * WaveView * File Chooser Button Build * git submodule init * git submodule update * make * sudo make install # will install into /usr/bin https://github.com/brummer10/XUiDesigner https://github.com/brummer10/XUiDesigner/releases/tag/v0.3 regards hermann

4 years

Jack session deprecated

by Will Godfrey

Can someone explain why this actually needed to have been done? Personally, I don't use any session management at all so it doesn't affect me. However I know a number of people who prefer it to other session managers precisely *because* it is so minimal. -- Will J Godfrey https://willgodfrey.bandcamp.com/ http://yoshimi.github.io Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

4 years, 1 month

RFT: implementation for MOTU FireWire series including CueMix DSP and CueMix FX

by Takashi Sakamoto

RFT: implementation of MOTU FireWire series CueMix DSP and CueMix FX Hi all, After investigation for protocols of MOTU FireWire series including features of CueMix DSP and CueMix FX, I've written implementation corresponding to the features in snd-firewire-ctl-services project[1]. If you are enough interested in it, would you please test the implementation? The first aim of this test request is to check whether the protocol implementation works as well out of my development environment. # Disclaimer * The aim of the work is to reveal relevant protocols so adequately and write the implementation. It is out of my scope to produce user-friendly applications such as GUI with cool user-delighted look and feel. (This is also the reason that the message is so long for general users.) # Acknowledgment When I made investigation plan for the protocols and evaluated the result of investigation, documents included in ffado source code[13] is helpful. The documentation includes a part of the result, while some parts are newly revealed in this time. I appreciate for document writers. # Current status * Below models are supported and I tested * 828 * 896 * 828mk2 * 896hd * 8 pre * Ultralite * 4 pre * Audio Express * 828mk3 (FireWire only/Hybrid) * Ultralite mk3 (FireWire only/Hybrid) * The most of control functions are available via ALSA control interface * Hardware metering support * Interaction support between on-board control component such as knob, utilizing notification mechanism of ALSA control interface # Requirements For the test, you need to solve long list of requirements since the protocol implementation is new and lays down user space as well as kernel space. I'm sorry for testers to discourage your motivation, but they are required... * Linux kernel v5.13 or later * a commit 66c6d1ef86ff ('ALSA: control: Add memory consumption limit to user controls')[2] is required since many user-defined control element sets are used. * Installation of backport codes for ALSA firewire stack * They comes from Linux kernel v5.16 prepatch (not released yet). * Please follow to instructions in my remote repository[3] * Installation of alsa-gobject v0.2.1 or later. * alsa-gobject project[4] provides libraries which perform as glue for several kind of language bindings to use UAPI of Linux sound subsystem. For detail, please refer to release announcement[5]. * Installation of libhinawa topic branch * libhinawa project[6] also provides library as glue for UAPI of ALSA firewire stack. * The topic branch (topic/motu-mixer-ioctl)[7] includes new APIs to use functions added in the kernel v5.16 prepatch. * Rust v1.51 or later * I use Rust programming language for the protocol implementation in user space side. * Build topic branch of snd-firewire-ctl-services * snd-firewire-ctl-services project[8] includes the series of implementation for protocols specific to ASICs/Vendors/Models. Additionally, as reference of service programs, it includes runtime implementation based on ALSA control interface and ALSA Sequencer interface. * The topic branch ('topic/motu-mixer-ioctl') includes implementation for the test. # Test procedure When the above requirements are satisfied, the service program can be build by below command line. It takes a bit long than compiling with C language since Rust compiler does more work than C (mainly due to type inference and lifetime check for safe runtime). $ cargo build -p snd-firewire-ctl-services The service program for MOTU FireWire series runs by below command line: $ cargo run --bin snd-firewire-motu-ctl-service CARD_ID The CARD_ID is the numeric ID of sound card corresponding to your device. You need to load ALSA firewire-motu driver in advance: $ sudo modprobe snd-firewire-motu $ cat /proc/asound/cards ... 2 [UltraLiteMk3 ]: FW-MOTU - UltraLiteMk3 MOTU UltraLiteMk3 (version:100800), GUID ... In the above example, CARD_ID should be 2. When the service program runs, you can see control elements via ALSA control interface. You can operate them by usual tools of ALSA control application, but I prefer 'qashctl' in 'qastools' project[11]. Due to specification of protocols defined by MOTU, notifications from the device for some controls are firstly available when isochronous packets are transmitted by the device. Please run any of ALSA PCM applications when testing. The aim of the request is whether the service program can be built and run out of my development environment. So I don't expect you so much. However, If you are interested, please check the other parts about which I concern: * The range of value for each control is valid or not. * Inverse evaluation of each control with boolean value. * The lack of control which should be produced by the service program. # Filing issues * Please use issue service in github.com[10]. * Preferable issues * The service program aborts when I operate control A. * The service program doesn't interact with on-board operation B. * The service program looks to be frozen when I operate C. * The behaviour of control element D is odd. * Unexpected issues * Why device A is not supported * It's preferable for you to take your time to cooperate with me if you wish. It might take a long time since the implementation lays down user space and kernel space. * If so, please file the issue to my remote repository for kernel prepatch[12]. * Why we have no GUI with cool look and feel * It's your work. The GUI application might be an ALSA control application which interacts with the service program. * I can not get which control value corresponds to actual ports * It is restriction under current design of ALSA control interface. We need to work for any extension to the design. * The name of control B is not user-friendly. * The name of controls are not fixed yet since we have few name convention for controls in studio-use equipments. It might corresponds to discussion in ALSA upstream. In my opinion, Linux audio developers have been enough lazy to the issue for recent decade. [1] https://github.com/alsa-project/snd-firewire-ctl-services/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [3] https://github.com/takaswie/snd-firewire-improve [4] https://github.com/alsa-project/alsa-gobject/ [5] https://lore.kernel.org/alsa-devel/20200623093239.GA68404@workstation/ [6[ https://github.com/alsa-project/libhinawa [7] https://github.com/alsa-project/libhinawa/tree/topic/motu-mixer-ioctl [8] https://github.com/alsa-project/snd-firewire-ctl-services/ [9] https://github.com/alsa-project/snd-firewire-ctl-services/tree/topic/motu-m… [10] https://github.com/alsa-project/snd-firewire-ctl-services/issues [11] https://gitlab.com/sebholt/qastools [12] https://github.com/takaswie/snd-firewire-improve/issues [13] https://web.archive.org/web/20110704073441/http://subversion.ffado.org/brow… Cheers Takashi Sakamoto

4 years, 1 month

Jump to page:

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