Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7535 discussions

by Will Godfrey

Apart from the new list of helpers, there is little visible change for most users, but the command line has now been greatly extended. Full details are in doc/Yoshimi_1.5.9_features.txt Also, there have been significant changes in the underlying code. These were always planned, but maybe not reported and explained as well as they could have been. More info is in dev_notes/Selection_Structure.txt -- 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.

7 years, 4 months

[LAD] [ANN] QjackCtl 0.5.4 - An Early Autumn'18 Release

by Rui Nuno Capela

That's it! QjackCtl 0.5.4 (early-autumn'18) is out! QjackCtl [1] is a(n ageing but still modern, maybe not so 'simple' anymore) Qt [2] application to control the JACK [3] sound server, for the Linux Audio [5] infrastructure. Website: https://qjackctl.sourceforge.io http://qjackctl.sourceforge.net Project page: http://sourceforge.net/projects/qjackctl Downloads: http://sourceforge.net/projects/qjackctl/files - source tarball: http://download.sf.net/qjackctl/qjackctl-0.5.4.tar.gz - source package (openSUSE Tumbleweed): http://download.sf.net/qjackctl/qjackctl-0.5.4-33.rncbc.suse.src.rpm - binary package (openSUSE Tumbleweed): http://download.sf.net/qjackctl/qjackctl-0.5.4-33.rncbc.suse.x86_64.rpm - AppImage [7] package: http://download.sf.net/qjackctl/qjackctl-0.5.4-5.x86_64.AppImage Git repos: https://git.code.sf.net/p/qjackctl/code https://github.com/rncbc/qjackctl.git https://gitlab.com/rncbc/qjackctl.git https://bitbucket.com/rncbc/qjackctl.git Change-log: - Graph port-type colors are now configurable (cf. menu View > Colors. - Make Graph nodes (ie. client boxes) transparent for yet some eye-candiness ;). Also keep the (Graph) current selection across port (dis)connections. - Drawing patchbay connector lines as (bezier) curves is now a difinitive and fixed feature (as long as no moreremains from the so called "Cambric explosion era" are still lurking in there). - AppStream metadata updated to be the most compliant with latest freedesktop.org specification and recommendation. - Graph auto-layout improvement for brand new node clients. - Avoid showing setup warning when no server settings have changed. - Fixed JACK D-Bus settings for MIDI driver parameter. License: QjackCtl [1] is free, open-source Linux Audio [5] software, distributed under the terms of the GNU General Public License (GPL) version 2 or later [6]. See also: http://www.rncbc.org/drupal/node/1941 References: [1] QjackCtl - A JACK Audio Connection Kit Qt GUI Interface https://qjackctl.sourceforge.io http://qjackctl.sourceforge.net [2] Qt framework, C++ class library and tools for cross-platform application and UI development http://qt.io/ [3] JACK Audio Connection Kit http://jackaudio.org [4] ALSA, Advanced Linux Sound Architecture http://www.alsa-project.org/ [5] Linux Audio consortium of libre software for audio-related work http://linuxaudio.org [6] GPL - GNU General Public License http://www.gnu.org/copyleft/gpl.html [7] AppImage, Linux apps that run anywhere http://appimage.org/ Enjoy && have fun! (what else?) -- rncbc aka Rui Nuno Capela

7 years, 4 months

[LAD] should JACK programs autostart the server?

by bill-auger

the debian maintainer of freewheeling suggested that it should autostart the server if it is not running (change JackNoStartServer to JackNullOption) i have my opinion; but i am interested in others https://sources.debian.org/src/freewheeling/0.6.4-1/debian/patches/060_jack…

7 years, 4 months

[LAD] Yoshimi V 1.5.9

by Will Godfrey

Amongst many other things this will have a new child of the 'About' window. This will consist of an acknowledgement of all the people who've helped Yoshimi in some way. If anyone particularly *doesn't* want their name on it please let me know. Then again, if there are missing names I'd like to know about that too! This list (Yoshimi_Helpers) has only existed in the source files since V 1.5.1 and is my best attempt at finding everybody. Release is planned for later this month. -- 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.

7 years, 5 months

[LAD] connect(2) call to /dev/shm/jack-0/default/jack_0 failed (err=No such file or directory) (again...)

by Fokke de Jong

Hi all, Sorry to bother you again with this. I’m running into the same problem again as before (see the latter part of the [LAD] jackd not using jackdrc… thread). And apparently my last fix involved some magic rather than replicable logic… :-( i.e. the problem seems to have disappeared on that system, without knowing exactly why) Now I am installing my jack client again on another fresh install of ubuntu 17.04. and a get the same error. I have installed jackd1, to be exact, these packages are current. jackd/artful,artful,now 5 all [installed,automatic] jackd1/artful,now 1:0.125.0-2 amd64 [installed] jackd1-firewire/artful,now 1:0.125.0-2 amd64 [installed,automatic] libjack0/artful,now 1:0.125.0-2 amd64 [installed] qjackctl/artful,now 0.4.5-1ubuntu1 amd64 [installed,automatic] when I start my client jackd is automatically started but i get the error: connect(2) call to /dev/shm/jack-0/default/jack_0 failed (err=No such file or directory) By browsing the jack sources i found the message seems to come from libjack/client.c in server_connect() peeking into the /dev/shm directory it seems /dev/shm/jack-0/default/jack_0 is briefly created,but disappears again, presumably just before the client is able to connect. I have been breaking my head over this, but I really have no clue why this is happening, especially as this has worked fine in the past. I would really like to know what could possibly cause this error and how to fix it. thanks, fokke

7 years, 5 months

[LAD] OSC

by Christopher Arndt

>From the LAU list: Am 08.09.18 um 17:23 schrieb Len Ovens: > I would be willing to help with a govering body if there are others so > inclined. I'd definitely be interested in helping OSC staying relevant. I've dabled with different OSC-to-X bridges in the past. [1] [2] [3]. My main interest is controlling applications, which talk to some MIDI device, running on a desktop or Raspi or similar, from another application on an Android device, since MIDI and USB-OTG support on Android devices is still somewhat a matter of luck. The protocols I've seen so far, which embed MIDI in OSC are often too simplistic. If I can't transmit Sysex, for example, it's no use to me. And what is the advantage of the verbose commands MidiOSC/midioscar use over just using the MIDI data type OSC provides? Also, the MIDI specification has had a few additions in the past years and a OSC-MIDI protocol hould make sure to support those as well. Chris [1] https://github.com/SpotlightKid/osc2rtmidi [2] https://github.com/SpotlightKid/osc2mqtt [3] https://github.com/SpotlightKid/touchosc2midi

7 years, 5 months

[LAD] further in on midi2udp/tcp

by Jonathan E. Brickman

I have set up and run a number of tests now. Mido under python2, uses 5-7% of two different 2.4GHz+ cores for a one-way midi2tcp --> tcp2midi link based on the sample code using blocking waits on both MIDI and TCP ports. I ran into minor difficulty getting Mido into python2, and difficulty considerably beyond my knowledge getting Mido into python3, into this up-to-date Manjaro, so my next tests were midi2udp --> udp2midi using just Python3 and libraries JACK-Client and 'socket'; this is quite promising, just 2% CPU total, and the test is a bit crude. So now I'm working on designing an algorithm which models a hardwired MIDI cable over a UDP connection. Specific goals are: - MIDI over IP. Using UDP right now, will use TCP if a reason to do so emerges. - Simplicity. I want this implementable in dedicated hardware as easily and inexpensively as possible. I want $20 boxes where I can dial the src/dest IPs using dip switches. Dreaming? Maybe... - Very well-suited for live performance. This means absolutely no MIDI event dropouts without being unaware, and using MIDI resends and reset in emergency to handle packet loss. - Solid LAN immediately. Very slightly lossy LAN/WLAN next. WAN if there is call for it. - Reliability and predictability at MIDI standard speeds -- 31.5 kHz -- not bandwidth availability. Once this works it may be doubled or quadrupled, or brought to HD-MIDI's clock once someone decides on one. The current software thought is to have both sides have two threads: one thread running callback to JACK, the other handling UDP/TCP, the threads communicating by Python FIFO queues, the UDP/TCP thread being constrained by 31.5kHz wait-state loop of some sort. Any suggestions, abridgements, et cetera? Also any thoughts on the best way to build that UDP/TCP thread wait-state loop? I'm beginning to imagine that TCP might have the advantage of being able to build up the buffering...but all of this has been fairly far from my practical programming, and I know that so many of you live here, so I thought I might ask :-) -- Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977 Hear us at ponderworthy.com -- CDs and MP3 available! Music of compassion; fire, and life!!!

7 years, 5 months

[LAD] Reminder: Call for Participation - ALMAT Workshop @ Impuls, Academy 2019

by IOhannes m zmoelnig

ALMAT - "Algorithms That Matter" Workshop at the impuls 11th International Ensemble and Composers Academy for Contemporary Music 2019 Special workshop for computer music practitioners, sound artists and composers Call for Participation Deadline: October 1st, 2018 with Robin Minard, David Pirrò, Hanns Holger Rutz http://www.impuls.cc/academy-2019/special-programs.html#c5169 [please distribute] Algorithms that Matter (ALMAT) focuses on the experimentation with algorithms and their embedding in sound works. Rather than conceiving algorithms as established building blocks or the a priori formalisation of a compositional idea, we look at them as performing entities whose consequences are irreducible to models. Algorithms “matter” in the sense that matter and meaning cannot be distinguished, neither can artists and their computational tools. Algorithms actively produce spaces and temporalities which become entangled with their physical embeddings. The 2019 edition of the workshop focuses on the development of a site-specific sound installation. The installation will explore the interactions of algorithmic and physical spaces and their dynamic and mutable properties. Participants will work on the premise that spaces and our perception of them change depending on presence, absence, the movement of visitors, the time of the day, the rhythm of the surroundings as well as the sonic and algorithmic interventions we bring into them. This workshop seeks to attract computer music practitioners, sound artists and composers by offering a platform for exchange and reflection about their personal approaches towards algorithmic experimentation. The participants are invited to develop their various approaches within an atmosphere of collaboration, where special emphasis will be given to the translation of environmental data (such as sensor input from the surroundings and visitors) through computer music systems developed and assembled by the participants and tutors. One question we want to pursue is how behaviours can be composed that transition from "technical and artificial" to "organic and alive", particularly through the articulation of spatiality. The workshop starts with an internal presentation of the participants for the other participants and tutors. An initial sound situation using a large number of small reconfigurable speakers forms the starting point for in-situ work. This structure will then be available for decomposition and rearrangement by the participants. The space will become a public exhibition halfway through the workshop, making it possible to observe and adapt to the interactions with the audience, a central question in the making of sound installations. The workshop will be held with technical infrastructure provided by the Institute for Electronic Music and Acoustics (IEM), including an 48-channel sound system and a selection of sensors. The workshop ALMAT was developed by David Pirrò and Hanns Holger Rutz (both IEM Graz) and will be held together with the special support by Robin Minard. How to apply: 1.) First, you must register and be accepted as a participant of the impuls Academy 2019. 2.) Along with your application, you must submit a statement concerning your specific interest in participating in the ALMAT Workshop or send this by e-mail to office(at)impuls(dot)cc. 3.) In addition, please send a description of your personal work in relation to the workshop's theme stating your previous experiences and describing employed computational approaches, their aesthetic

7 years, 5 months

[LAD] [ANN] Qtractor 0.9.2 - The Summer'18 Release

by Rui Nuno Capela

At last! Qtractor 0.9.2 (summer'18 beta) is released! Not much has changed but here's the change-log: - AppData/AppStream metadata is now settled under an all permisssive license (FSFAP); also updated to be the most compliant with latest freedesktop.org specification and recommendation. - Fix build for Qt >= 5.11.0 (by David Geiger, thanks); also for some g++ >= 8.1.1 warnings and quietness. 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: http://qtractor.org http://qtractor.sourceforge.net https://qtractor.sourceforge.io Project page: http://sourceforge.net/projects/qtractor Downloads: http://sourceforge.net/projects/qtractor/files - source tarball: http://download.sf.net/qtractor/qtractor-0.9.2.tar.gz - source package (openSUSE Tubleweed): http://download.sf.net/qtractor/qtractor-0.9.2-37.rncbc.suse.src.rpm - binary package (openSUSE Tubleweed): http://download.sf.net/qtractor/qtractor-0.9.2-37.rncbc.suse.x86_64.rpm - AppImage [7] packages: http://download.sf.net/qtractor/qtractor-0.9.2-7.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 (help wanted!): http://sourceforge.net/p/qtractor/wiki/ - static rendering: http://qtractor.org/doc http://qtractor.sourceforge.net/doc https://qtractor.sourceforge.io/doc - user manual & how-to's: http://download.sf.net/qtractor/qtractor-manual-and-howtos.epub http://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 http://qtractor.org http://qtractor.sourceforge.net https://qtractor.sourceforge.io [2] Qt framework, C++ class library and tools for cross-platform application and UI development http://qt.io/ [3] JACK Audio Connection Kit http://jackaudio.org [4] ALSA, Advanced Linux Sound Architecture http://www.alsa-project.org/ [5] Linux Audio consortium of libre software for audio-related work http://linuxaudio.org [6] GPL - GNU General Public License http://www.gnu.org/copyleft/gpl.html [7] AppImage, Linux apps that run anywhere http://appimage.org/ See also: http://www.rncbc.org/drupal/node/1933 Enjoy && Have fun. -- rncbc aka Rui Nuno Capela

7 years, 5 months

[LAD] midi2tcp and tcp2midi, working prototype

by Jonathan E. Brickman

It is working as here: https://github.com/ponderworthy/midi2tcp and quite well. Haven't come up with a single reason to make it more complicated, beyond much more careful timeout handling. It will need to be able to destroy its own socket and recreate et cetera, to be durable with marginal wifi. And performance is not very good, midi2tcp takes 3-5% of one core and tcp2midi takes 6-8% of another on this i3- 3110 at 2.4GHz. Am not sure what best to do about the performance. Will probably try converting Python to binary, but have read over and over again that that doesn't do so very much. I also had to rename it back to TCP after re-reading the Mido library docs yet again, it is using rtpmidi backend but it says it's TCP, not UDP, and it is using a connected socket which means TCP I do believe. I had thought RTP-MIDI was UDP? I wonder if judicious use of UDP would improve performance by a substantial amount? -- Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977 Hear us at ponderworthy.com -- CDs and MP3 available! Music of compassion; fire, and life!!!

7 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