Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7448 discussions

by John Murphy

FOSS developers are so generous that all users are already in their debt and already I fear may have upset some by saying so. You/they have my admiration, but it doesn't seem enough and the debt remains. Occasionally I see an opportunity to help, if a developer hints they're near starving, or I can dispose of some hardware in someone's direction... But, to the point. I'm currently using a fabulous little suite of tools which were almost written for me by a gifted dev.. http://sed.free.fr/audiotag/ (although the version I have is 0.7) I clumsily and regrettably offered that despicable symbol of capitalism - money (or goods) to show appreciation. I don't even feel able to ask for more from sed and I said I would write a GUI and some database code to develop it to an actual application, but I can't, or I could, but it would be a mess which I could only keep to myself. It would be barely usable, even after a lot of head scratching. May I humbly ask how to ask to pay for some development? As my time runs out in old age, I'd much rather enjoy using software than experience the real discomfort I feel when I try to code, but having used it since the beginning, maybe I can see ways of using software more intuitively than some. I may well be the fastest audiotagger in the universe! How to proceed? I duckducked for Linux developers, but thought I should ask here first. -- Thanks for everything, regardless. John.

6 years

Re: [LAD] New(ish) OSS synth plugin

by Kjetil Matheussen

Daniel Swärd: > > Hi all. > > Just found out that one of the Bitwig devs has released an older (commercial) > project of his as open source: https://github.com/kurasu/surge > > Doesn't yet build on Linux, but quoting from the github page: > "It currently only builds on windows, but getting it to build on macOS again & > Linux should be doable with moderate effort." > > How about we get it building at the next Berlin LAU meeting? > I took a quick procrastination-shot at it: https://github.com/kmatheussen/surge (first copy various VST directories into the build) premake5 gmake make surge-vst2 verbose=1 -j8 ldd -r target/vst2/Debug/Surge-Debug.so undefined symbol: _ZN6VSTGUI8soHandleE (target/vst2/Debug/Surge-Debug.so) undefined symbol: _ZN3Gtk11FileChooser18set_current_folderERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE (target/vst2/Debug/Surge-Debug.so) undefined symbol: _ZNK3Gdk11DragContext12list_targetsB5cxx11Ev (target/vst2/Debug/Surge-Debug.so) undefined symbol: _ZN4Glib7ustringC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE (target/vst2/Debug/Surge-Debug.so) undefined symbol: _ZN12SurgeStorage11load_wt_wavENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEP9Wavetable (target/vst2/Debug/Surge-Debug.so) undefined symbol: __cpuid (target/vst2/Debug/Surge-Debug.so) undefined symbol: _ZN3Gtk11CssProvider14load_from_dataERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE (target/vst2/Debug/Surge-Debug.so) undefined symbol: _Z19spawn_miniedit_textPci (target/vst2/Debug/Surge-Debug.so) undefined symbol: _ZNK3Gtk11FileChooser13get_filenamesB5cxx11Ev (target/vst2/Debug/Surge-Debug.so) So, a little bit work left, but maybe it's enough to link with a newer version of gtkmm than I did. Don't know how well VSTGUI works on linux though. Using gtkmm as the underlying GUI to implement VSTGUI on top of seems worrying.

6 years

New(ish) OSS synth plugin

by Daniel Swärd

Hi all. Just found out that one of the Bitwig devs has released an older (commercial) project of his as open source: https://github.com/kurasu/surge Doesn't yet build on Linux, but quoting from the github page: "It currently only builds on windows, but getting it to build on macOS again & Linux should be doable with moderate effort." How about we get it building at the next Berlin LAU meeting? Cheers /Daniel

6 years

Yoshimi V 1.5.9

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.

6 years

[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

6 years

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…

6 years

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.

6 years

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

6 years

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

6 years

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

6 years

Jump to page:

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