Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

5 participants
7515 discussions

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

3 years, 11 months

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 > *********************************************** >

3 years, 11 months

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

3 years, 11 months

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

3 years, 11 months

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

3 years, 11 months

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.

3 years, 11 months

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

3 years, 12 months

Re: [LAD] Programming LV2 plugin from scratch tutorial video series

by Fons Adriaensen

Sorry to _low_show - this was meant for the list. On Mon, Oct 11, 2021 at 03:19:45PM +0200, _low_show wrote: > Looks great, will make some time to try it out! Thanks for making this! I somehow deleted the original post, but refer to > https://youtu.be/51eHCA4oCEI > https://lv2plug.in/book I never got to grips with turtle. In particular not with things like: @prefix doap: <http://usefulinc.com/ns/doap#> . @prefix lv2: <http://lv2plug.in/ns/lv2core#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix units: <http://lv2plug.in/ns/extensions/units#> . All docs and tutorials I found mention that the URLs do NOT mean that an application reading a file that contains them would actually need to read them from the web (which would be a unacceptable security risk anyway). But that means that whatever is defined by those URLs must actually be hard-coded in any LV2 host that reads the 'manifest.ttl' or 'my-plugin.ttl' files. Which raises the question why those @prefix lines are required at all. They could be used in theory to check that what is hard-coded corresponds to what is defined in those URLs. But to do that the application would need to access them. So all that these lines seem to provide is some illusion of conformity which isn't enforced or checked at all. So the conclusion is that this isn't any better than any ad-hoc way of encoding the plugin metadata. Or am I missing something essential ? TIA for any reply that would enlighten me... -- FA

4 years

SoundTracker 1.0.3 first pre-release

by Yury Alyaev

Hi all! I have recently released first preview of SoundTracker v1.0.3. Here are new features of this pre-release: * General: - Indication of the current playing instrument / sample number in scopes (optional via Settings) - On new instrument or sample loading ins / sample name(s) can be overwritten or kept (configurable via Settings -> GUI settings) - Extended pattern sequence editor with DND (activaled by right-click on the playlist area) * Instrument editor: - Envelopes cutting / copying / pasting / scaling - Indication of the keys playing with the current instrument also in the pattern / song playing mode * Track editor: - Track line insertion / removal - Masking for cut / copy / paste operaions I invite everyone to test this pre-release and look forward your feedback (bugreports and feature requests). Download: https://sourceforge.net/projects/soundtracker/files/ Regards, Yury.

4 years

[ANN] Qtractor 0.9.24 - An Autumn'21 Release

by Rui Nuno Capela

Hello everybody, Qtractor 0.9.24 (autumn'21) is released! Change-log:: - A new option has been added to reset/resend all MIDI track/channel and buses controllers on playback start (cf. View/Options.../MIDI/Playback/Reset all controllers on playback start). - Whenever possible, avoid suggesting Save As... to an extracted archive/zip directory. - Fixed an old nasty mistake when renaming session names and then saving into an archive/zip bundle file (.qtz). - Fixed Mixer multi-row automatic layout consistency, when adding new or removing existing tracks or buses. Description: Qtractor [1] is an audio/MIDI multi-track sequencer application written in C++ with the Qt framework [2]. Target platform is Linux, where the Jack Audio Connection Kit (JACK [3]) for audio and the Advanced Linux Sound Architecture (ALSA [4]) for MIDI are the main infrastructures to evolve as a fairly-featured Linux desktop audio workstation GUI, specially dedicated to the personal home-studio. Website: https://qtractor.org https://qtractor.sourceforge.io http://qtractor.sourceforge.net Project page: https://sourceforge.net/projects/qtractor Downloads: https://sourceforge.net/projects/qtractor/files - source tarball: https://download.sf.net/qtractor/qtractor-0.9.24.tar.gz - source package (openSUSE Tubleweed): https://download.sf.net/qtractor/qtractor-0.9.24-67.1.rncbc.suse.src.rpm - binary package (openSUSE Tubleweed): https://download.sf.net/qtractor/qtractor-0.9.24-67.1.rncbc.suse.x86_64.rpm - AppImage [7] package: https://download.sf.net/qtractor/qtractor-0.9.24-67.1.x86_64.AppImage Git repos: https://git.code.sf.net/p/qtractor/code https://github.com/rncbc/qtractor.git https://gitlab.com/rncbc/qtractor.git https://bitbucket.org/rncbc/qtractor.git Wiki (outdated; help wanted, please): https://sourceforge.net/p/qtractor/wiki/ - static rendering: https://qtractor.org/doc http://qtractor.sourceforge.net/doc https://qtractor.sourceforge.io/doc - user manual & how-to's: https://download.sf.net/qtractor/qtractor-manual-and-howtos.epub https://download.sf.net/qtractor/qtractor-manual-and-howtos.pdf License: Qtractor [1] is free, open-source Linux Audio [5] software, distributed under the terms of the GNU General Public License (GPL [6]) version 2 or later. References: [1] Qtractor - An audio/MIDI multi-track sequencer https://qtractor.org https://qtractor.sourceforge.io http://qtractor.sourceforge.net [2] Qt framework, C++ class library and tools for cross-platform application and UI development https://qt.io/ [3] JACK Audio Connection Kit https://jackaudio.org [4] ALSA, Advanced Linux Sound Architecture https://www.alsa-project.org/ [5] Linux Audio consortium of libre software for audio-related work https://linuxaudio.org [6] GPL - GNU General Public License https://www.gnu.org/copyleft/gpl.html [7] AppImage, Linux apps that run anywhere https://appimage.org/ [8] CMake, a cross-platform, open-source build system generator https://cmake.org See also: https://www.rncbc.org/drupal/node/2288 Keep the fun, always! -- rncbc aka Rui Nuno Capela

4 years

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