Linux-audio-user

linux-audio-user@lists.linuxaudio.org

8 participants
20664 discussions

by Brent Busby

Usually when I want to send sysex dumps to midi hardware, I just use the amidi command from the shell, but when QJackCtl is already running (along with lots of other Jack apps), the raw device is already in use by Jack and I can't connect to it at the raw Alsa level anymore. Since it's kind of a pain to have to shut down my whole Jack session just to send a sysex dump, is there an easy way I could just sysex through Jack? Are there any shell commands I should know about that let you do this through Jack Midi rather than Alsa Midi? -- + Brent A. Busby + "We've all heard that a million monkeys + Sr. UNIX Systems Admin + banging on a million typewriters will + University of Chicago + eventually reproduce the entire works of + James Franck Institute + Shakespeare. Now, thanks to the Internet, + Materials Research Ctr + we know this is not true." -Robert Wilensky

12 years, 8 months

Joining LAD and LAU lists (And: more central instances in a "herding-cats" community are good)

by Nils Gey

Hello both lists, I see the reason for a non-discussion announcement list, LAA, but is it really necessary to have twp lists? I know there are several people who only subscribed to one list, but I don't know if this is intentional or not. Why not merge both. The immediate effect would be a stop at the cross posting just to reach the whole community. The mailinglists are from the same service, but I think in the end it would be more convenient and better for everyone to have it all in one place. Yes, I know some of you fear (mostly people in the dev list who do not read LAU) that they will get unwanted mails. But as you can tell from experience topics like "why linux audio sucks", "water as fuel" and other mega/nonsense/offtopic threads get cross posted anyway. And I know some of you think devs and users should be kept seperated. But be honest: Who in the world is subscribed to a linux mailing list and could not stend the occasional developers topic. If you want beginner-level support you most likely don't know how to use lists :) Just to be clear: I am a friend of diversity and seemingly "redundant" applications and projects. There cannot be enough sequencers, samplers, synthesizer, notation programs etc. But when it comes to infrastructure and core building blocks I see no sense in seperation. This is the strong point, compared to other operating/eco-systems. We may friendly compete on a musical or feature basis, but there is no need to border a program just to make it harder for the users to use the program of the "enemy" (from a Windows/OSX POV). In a Linux-Audio world of diversity and individuality, it is good to have central places and instances. We can do whatever we want but unlike the closed source world we have no need to create factions and standards that rival with each other, creating artificial gaps. The most successful of these instances is JACK itself. A centralized audio server, hailed and praised by everyone. And since I am writing this mail already, my personal wish list: Please join the two blog/RSS planets as well (http://www.planet.linuxmusicians.com/, http://linuxaudio.org/planet/ ) Merge Yoshimi and ZynAddSubFx, the JACK versions and experimental forks, the session managers/protocols and a few audio distributions which have not enough manpower and that can be used to boost the other distributions. "Joining/Merging" also can mean for one side to step down honorable and retire the project. Nils http://www.nilsgey.de

12 years, 9 months

light weight, full featured desktop for audio

by Len Ovens

With all the talk about minimal DE installs, and reading about the problems with different kernels and video cards... and what things cause xruns. I thought of a solution that may work well. Here is my minimal DE through the eyes of ps: joet@music:~$ ps x PID TTY STAT TIME COMMAND 3784 ? S 0:00 sshd: joet@pts/0 3785 pts/0 Ss 0:00 -bash 3886 pts/0 S 0:03 xfce4-panel 3890 pts/0 S 0:00 dbus-launch --autolaunch cc2b7c64cc6292515b70bed80000 3891 ? Ss 0:00 //bin/dbus-daemon --fork --print-pid 5 --print-addres 3893 ? S 0:00 /usr/lib/xfce4/xfconf/xfconfd 3909 pts/0 R+ 0:00 ps x ---------------------------------------------------------------- Yup, 6 things. The idea is to use two computers. Some of the mini atom MBs would easily fit two in one case and still use no fans and one PS. They all have Gb networking, so a small switch between them is all that is needed. This assumes a single audio card with enough channels for whatever you are doing, either pci, USB or (with a pci(e) FW card) FW. One computer is headless and never runs X, though it would have most of the x libs anyway. All of the audio SW would be installed on this machine. I only used xfce4-panel because it was already there (it's running ubuntustudio in real life sitting at the login screen). The panel has been cleared of all applets except for the main menu and shrunk to fit. I am not sure if this is enough, some people may need a systray as well. The panel seems to launch dbus for me too (good). The main thing is that it gives me a menu for that machine where the apps it launches all inherit the same dbus info and display. An ncurses based menu could work just as well. and there are other panels or docks which would also work. The second computer can run any linux or BSD or anything else so long as it has an xserver (even windows I think can have an xserver). It does not matter what video card you use, because you can run a generic kernel that the driver is made to run on. You don't have to think about interrupts or anything like that. Pulse run on this machine will not affect jack in any way. Rather than bother with figuring out a pulse-jack bridge, connect line out from the head board to the line of the audio board and vise versa and use zita-a2j and zita-j2a to add them to jack. My machines are not the best trial. I am using wireless networking (b version with max 11M, but most often less) but even with 100M there is some lag, though it doesn't effect the audio at all. Gb net would probably be good enough though. affects latency? yup. jack running -p16 -r 48000, guitarix on top. very few Xruns, with the DE on the same machine I had 1000s/minute. No mouse/kb irqs, no video irqs, Makes this old P4/2.4G sing. I'll have to try dual heading the gui box (aspire one netbook). So far I think this is a better solution than running the audio across the net. -- Len Ovens www.OvenWerks.net

12 years, 9 months

Interoperability between session management systems

by Johannes Kroll

A couple of days ago, I tried out non-session-manager, and thought, this is really nice. It really works in a practical, easy way. Unfortunately the number of apps supporting non-session is quite small (as is the case for *all* session management systems, AFAIK). There may be "a complete audio studio" supporting non-session, from one choice of sequencer to one synth to one sampler, but people like to use their favorite software. You can't just say, "if you want to use a sequencer, use X because it supports non-session". So its usefulness is limited. However, many apps support one session management framework or the other. So the obvious thing to do if you want to give people more choices would be to create some kind of interoperability layer between session management systems. What do you think about this? Is there an effort for something like this already underway? I personally think a good first step might be to create some compatibility between non-session (because I like it) and jack-session (because most people are using jack).

12 years, 9 months

Re: [LAU] light weight, full featured desktop for audio

by Ralf Mardorf

-------- Forwarded Message -------- From: Ralf Mardorf <ralf.mardorf(a)rocketmail.com> To: Rob <lau(a)kudla.org> Cc: linux-audio-user <linux-audio-user(a)lists.linuxaudio.org> Subject: Re: [LAU] light weight, full featured desktop for audio Date: Fri, 22 Feb 2013 14:36:53 +0100 On Fri, 2013-02-22 at 14:23 +0100, Ralf Mardorf wrote: > On Fri, 2013-02-22 at 08:09 -0500, Rob wrote: > > On 02/22/2013 03:47 AM, david wrote: > > >>>> dwm has both idiosyncrasies and a learning curve, but so too do most > > >>>> "expert" pieces of software. vim and emacs are the canonical examples, > > > Being hard to learn doesn't make something an "expert" piece of software - > > > unless you're talking about a *field* that requires lots of expertise such > > > as rocket science. Text editing isn't rocket science. A text editor > > > shouldn't be as hard to learn as rocket science. ;-) > > > > What makes something an "expert" piece of software is simply that it's not > > aimed at the layman. vi, emacs and dwm were meant for software developers > > and system administrators to use. And a musician who's also one of those > > things will probably be able to figure out those programs. A musician who > > isn't should probably use leafpad or something like that. Anything more > > involved and they're not going to be able to figure out how to turn on > > syntax highlighting, regular expression search and replace, autocompletion, > > etc. anyway. > > > > Text editing isn't rocket science, but when vi and emacs were originally > > written, it was computer science. Since then it's just been 30-40 years of > > iteration to make them more capable without much thought to whether someone > > accustomed to Windows Notepad could use them. I've used both for about 25 > > years, and have no use for the (to me ill-advised) menu extensions that > > don't really help noobs use them while taking up space on my screen that > > could be used for one or two more lines of code. > > > > For those poor laymen who have to edit files from the command line, we have > > nano now. I still get questions from people who allegedly have degrees in > > my field about functions that are prominently displayed in its little menu > > at the bottom of the screen. Instead of reading the screen, they've been > > trained to look for File/Save. > > > > Software meant for the layman but that's difficult to use, on the other > > hand, is just poorly-written software. (Expert software can be bad too, > > but usually that doesn't last 30 years.) > > > > Rob > > I'm not accustomed to Windows editors, in the past I used all kinds of > complicated editors, such as the first C64 Assembler editors, C editors > for DR DOS etc., but today I expect more comfort. I'm not aware about > syntax highlighting for Leafpad or that it can be used by the command > line. I neither program professional, nor just for interest, but I need > a command line editor to set up *NIX systems and for doing this I expect > an intuitive to use editor, such as mcedit. PS: Nano isn't available for all minimal Linux and not available for the FreeBSD basic system. It's hard enough that I always have to start with a wrong keyboard map. Editors such as Nano often have to be installed, the default often is vi(m), so before you can install Nano you often need to use vi(m) first.

12 years, 9 months

[ANN] MFP 0.01 (Music For Programmers, a graphical patching system)

by Bill Gribble

MFP -- Music For Programmers Release 0.01, "Mining For Participants" MFP is an environment for visually composing computer programs, with an emphasis on music and real-time audio synthesis and analysis. It's very much inspired by Miller Puckette's Pure Data (pd) and Max/MSP, with a bit of LabView and TouchOSC for good measure. It is targeted at musicians, recording engineers, and software developers who like the "patching" dataflow metaphor for constructing audio synthesis, processing, and analysis networks. MFP is a completely new code base, written in Python and C, with a Clutter UI. It has been under development by a solo developer (me!), as a spare-time project for several years. Compared to Pure Data, its nearest relative, MFP is superficially pretty similar but differs in a few key ways: * MFP uses Python data natively. Any literal data entered in the UI is parsed by the Python evaluator, and any Python value is a legitimate "message" on the dataflow network * MFP provides fairly raw access to Python constructs if desired. For example, the built-in read-eval-print console allows live coding of Python functions as patch elements at runtime. * Name resolution and namespacing are addressed more robustly, with explicit support for lexical scoping * The editing UI is largely keyboard-driven, with a modal input system that feels a bit like vim. The graphical presentation is a single-window style with layers rather than multiple windows. * There is fairly deep integration of Open Sound Control (OSC), with every patch element having an OSC address and the ability to learn any other desired address. The code is still in early days, but has reached a point in its lifecycle where at least some interesting workflows are operational and it can be used for a good number of things. I think MFP is now ripe for those with an experimental streak and/or development skills to grab it, use it, and contribute to its design and development. The code and issue tracker are hosted on GitHub: https://github.com/bgribble/mfp You can find an introductory paper (submitted to LAC-2013) and accompanying screenshots, some sample patches, and a few other bits of documentation in the doc directory of the GitHub repo. The README at the top level of the source tree contains dependency, build, and getting-started information. Thanks, Bill Gribble

12 years, 9 months

The Psychology of Music

by david

http://visual.ly/psychology-music?utm_source=visually_embed -- David gnome(a)hawaii.rr.com authenticity, honesty, community http://clanjones.org/david/ http://dancing-treefrog.deviantart.com/

12 years, 9 months

a little self-promotion. 100% Linux sound!

by Djého Youn

Hi, list! Here's the trailer for upcoming docu film by Marcel Wehn on Gwen van den Eijnde's Basel show. http://vimeo.com/59399369 I composed 3 pieces of music for the show and you can listen a part of it on the video. Of course, everything is done 100% pure Supercollider (3.4) on Linux (Ubuntu 10.10) machine. Thanks for taking your time to check out. -- Jae Ho YOUN http://jaehoyoun.com http://advancedsituation.com/

12 years, 9 months

Re: [LAU] Basic question about use of a lowlatency kernel

by Jeff Sandys

> From: jonetsu(a)teksavvy.com > > If a better response time from the kernel is something that's Good, why > isn't lowlatency kernels a default in Linux distros (well, at least in > Linux Mint and Fedora) If it is So Good, what are the arguments for not > having a lowlatency kernel by default ? Any drawbacks ? I presume the > Audio-oriented Linux distros do have lowlatency kernels by default, do > they ? > The Fedora Musicians Guide has a good topic on Real-Time and Low-Latency: http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Mus… My understanding: * A Real-Time kernel will give you more consistent, reliable latency. - But not necessarily lower latency * Useful, proven, RT features migrate into the main kernel. - So use the RT patches to test and prove them. * Current main kernels give reasonable performance for most musicians. - Your mileage may vary, if you get some annoying x-runs use the RT patch. - Sound travels ~1 foot per millisecond, 8 feet from the speaker = 8ms latency -- Jeff

12 years, 9 months

bristol, B3 organ, clicking sound

by Fero Kiraly

hi forum, I have a weird clicky sounds in this organ (on the begining and endig sound) I am using archlinux, newesr bristol. What can I do ? thanks. fk.

12 years, 9 months

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