Linux-audio-dev October 2004

linux-audio-dev@lists.linuxaudio.org

68 participants
60 discussions

Re: [linux-audio-dev] 3D fft analysis program

by Downer

> I'm hoping that you're thinking of a realtime display, in which the > peaks roll off to create a true waterfall effect. Baudline (http://www.baudline.com) is a fantastic viewer that does fft cascade. I've used it for a couple of years, and it is great for figuring out how different sounds "work", and it has an oscilloscope-type display as well. Cheers, Jason Downer

17 years, 11 months

[linux-audio-dev] Drum synth

by Dmitry Baikov

Hello. I finally started making my pet music project and realized I need a drum synth to make some cool sounds. psindustrializer is good but also need some tr-909-style sounds. I remeber from my old windoze days I used a nice piece of software called Stomper. Does anybody know any software for linux with comparable capabilities? Or we need to write one? Stomper does not work under wine :( Thanks.

17 years, 11 months

[linux-audio-dev] Re: Drum synth

by Juhana Sadeharju

Hello. I had a couple of articles on drum synths. Check ftp://ftp.funet.fi/pub/sci/audio/devel/lad/drumsynth/ I built the circuit in a00*.jpg at the time when this article was fresh. The article b00*jpg mentions an earlier article. I will check that out at library. Hmm.. I coded a drum synth for Commodore VIC-20 at the time. VIC provided an audio chip with three oscillators, noise, and a common volume if I remember correctly. What I did was to modulate osc pitch and volume parameters with a fast and accurate (compared to Basic) assembly code. The drum sounds were assigned to the keys. This was about 1984, inspired by Yamaha's digital RX drum synths, not by analog drums. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

17 years, 11 months

[linux-audio-dev] adm: list archives at eca.cx going away

by Kai Vehmanen

Hello, this is not an urgent issue, but I'd like to warn in advance that the laa/lad/lau list archiving at www.eca.cx/la[adu] will stop some time next year. I'm not sure of the exact date, but sooner or later anyway. Note that I'm not going to take the existing archives offline, so all links pointing to mails at eca.cx will still work. Fortunately we nowadays have many other archives of the lists. We just now need to pick a new official archive and update the links at: http://www.linuxdj.com/audio/lad/archive.php3 I propose that we use the archives at columbia.edu: http://www.music.columbia.edu/pipermail/linux-audio-dev/ ... and so on. Very good archives can also be found at gmane.org: http://gmane.org/info.php?group=gmane.linux.audio.devel ... and so on. -- http://www.eca.cx Audio software for Linux!

19 years, 4 months

[linux-audio-dev] anyone interested to develop a new apps ?

by dubphil＠free.fr

Hello, I want to setup a sound system with linux. For this, I need an app that could split an audio file in four tracks in order to add them separately some effects. I tried to achieve this using Jamin which have this kind of "Crossover" functionnality, but it is defenetly not usable for what I need. The ideal application should not be too complex : it should be compatible with Jack and could just get a stereo channel for input and provides 4 stereo channels. The 4 stereo channels would be the result off a crossover spliting by frequency ranges of the input stereo channel. we could give a default preset like this : 1st stereo channel : low 2nd stereo channel : low-mid 3rd stereo channel : high-mid 4th stereo channel : high of course thoose ranges should also be set manually. each channel could have the gain controlled and could have assigned 4 effects with LADSPA plug-ins. each slider or knob should be midi controlled (I know that Jack Rack already does this). Does this kind of apps should take a long time to be developped ? I'm not skilled to undergo this kind of project alone as I'm a poor PHP/Perl and little Python developper. Anyone interested for this kind of project ? Kind regards Philippe

19 years, 5 months

[linux-audio-dev] Ardour 0.9beta20 released

by Paul Davis

This is intended to be the last beta release before Ardour 0.9 is released. No new features will be added before we release 0.9. FYI, 0.9 is intended to differ from 1.0 only with respect to bug fixes, install and first-time user experience. We do still have a few significant crashing and other major bug fixes to be resolved before 0.9 can be released, but optimism is in the air. http://ardour.org/releases/ardour-0.9beta20.tar.bz2 NEW FEATURES ------------- * Added support for midi parameter feedback. When enabled, controls that are bound to incoming midi events will send out that event when modified. This lets you control generic midi control surface with motor faders and/or led encoders (like the incredibly affordable Behringer BCF2000, which was used for testing), to match the internal state. Note the extra/changed options in the option editor's midi tab. Reminder: to bind a fader or bar-control to midi, do a Control-Middle-Click on it, then send some midi control. * automation playback will send MIDI parameter feedback, thus making external motorized faders etc. move with automation. Note: this feature will probably be reimplemented in the future because of interlocking problems with the realtime audio thread. * Added generic midi bindability for mute, solo, and rec-enable controls. to do it, you can do Control-RIGHT-click on the mute and solo buttons (the normal binding click is taken on these buttons for other functions). For the Record-enable button, it is the normal ctrl-middle-click. You can also pick it from the context menu of the mute button. A menu will be added to other buttons later. * add -V/--novst flag to avoid using VST even if it was compiled in * multiple selected regions can be dragged across tracks (nick mainsbridge) * normalization can be undone (patch from jkyro) * export dialog redesigned - master outs appear in their own selector, preselected - button to control visibility of specific other tracks * new playlist selector (uses a tree structure in a scrolled window, instead of menus) * add "nudge by capture offset" operation for regions * remove zoom changes from the undo/redo history * sessions still load when audio files are missing or corrupt * Ardour is believed to build on OS X (CVS and/or this release) FIXES ----- * templates now get installed/uninstalled/rolled-into-tarball/etc. Let me know if some corner of "make" doesn't work with the templates. * Removed libglib dependency from libardour. Instead of guint32, we use stdint.h's uint32_t, etc. * fixed some midi prompter dialog issues * fixed some midi binding state saving issues * change entire buffer management scheme to be (more) RT-safe * a major CVS commit that includes the first pass of changes to fix some serious errors in the way ardour handles threads when exiting. it also includes a significant fix to make export work when sync'ed with JACK * new functions to do "internal seeks" within the existing playback buffer of a DiskStream, avoiding a new disk read for small adjustments of playhead position * lots of work on MTC slaving * changed prototype of pthread_exit_pbd() * don't send a message via error/info/warning/fatal if thread is not registered with GUI * remove "eox" signal from MIDI parser * cleanup a few details of MIDI parsing - importantly, all sysex messages get eox on the end when passed to specific functions * add "timecode-source-is-synced" option to ardour.rc(.in) * remove Session::request_roll() * fix bug with MMC rec-enable handling (only odd-numbered tracks could be enabled) * make region export progress bar move in the right direction * more MTC slaving fixes and improvements (not done yet) * remove wrong-thread-calling of Session::clear_event_type(), which should help a number of loop-related crashes * remove erroneous use of "abort" in function call * Automake-1.7 or higher is required for libmidi++ now * add "nudge by capture offset" operation for regions * enlarge playhead/edit cursor arrows a bit * avoid duplicate keyboard target registration * pay attention to "virtual" window enter/leave events, but continue to ignore "inferior" ones (may help with keyboard focus issues) * cancelling tempo/meter create dialog doesn't insert a default tempo/meter marker * tempo/meter create dialogs have minimal WM decor, and use standard ArdourDialog API * 2d panner fixed in many ways (still not to my taste and not really correct) * context-click on 2d panner shows context menu (Bypass is the only entry so far) * bypass added to stereo panner context menu * general panner state load/restore fixes * master outs added to connections menu * added optimizations for peak metering (use of fabsf, flag constants as floats, avoid implicit double/float casting) * Updated the Italian and Brazilian translations. * handle disk over- and under-run errors in the GUI, and be more comprehensible to regular users. * fix panning bypass for 2d panner * fix stereo panner "mute" menu item so that it doesn't toggle panner mute state every time it pops up * fix more subtle elements of panner state restoration * remove window crossing debug messages * add "OK" button and remove window decoration from "can't connect to JACK" dialog

19 years, 6 months

Re: [linux-audio-user] Re: [linux-audio-dev] How to automate hdsploader

by ico＠fuse.net

Thanks a lot for the help Paul! One more quick question though, has the issue with jackd + alsa + hdsp ever been fixed where jackd only allows 2 periods and no other number? Best wishes, Ico >Hence, I've been wondering what do I need to do to automate hdsploader as soon > as the cardbus has been connected? using the new modprobe.conf syntax .... install snd-hdsp /sbin/modprobe --first-time --ignore-install snd-hdsp && { /usr/bin/hdsploader; }

19 years, 6 months

[linux-audio-dev] Linux and Standards

by Ivica Ico Bukvic

Hi all, As some of you may already know, I am going to present a paper/demo at the upcoming ICMC 2004 conference in Miami on Linux titled: Linux as a Mature Digital Audio Workstation in Academic Electroacoustic Studios – Is Linux Ready for Prime Time? As promised I will be posting an expanded version of the paper online right after the presentation that is slated for the Wednesday next week. I would like to use this opportunity to thank all the members of this wonderful community for their insight and help in making my final paper as accurate and objective as possible. Furthermore, I would like to thank everyone involved in the development of audio software for the GNU/Linux platform because without you none of this would've been possible. Finally, just a couple days ago I was invited to serve as one of the panel members on Matthew Wright's discussion titled "Standards From the Computer Music Community" that will take place on Saturday November, 6. He wants me to present the Linux audio community's angle on standards and considering that this conference encompasses faculty as well as researchers and programmers from all across the World, I feel that this is a perfect opportunity to voice out our angle on the given topic and perhaps that way further expose the strengths that Linux can offer. I would like to share with you a short overview of my thoughts on this issue and would like to encourage those of you who may have additional thoughts to please send me your suggestions and/or corrections. Your help in this matter is most appreciated! However, please bear in mind due to fact that I am leaving for the conference on Sunday afternoon and am not sure how regularly (if at all) will I be able to check my e-mail while away from home, I would really appreciate it if you would please send me your responses before Sunday 2pm or so. I would of course appreciate also belated comments just in the case I do get to check my e-mail, I just cannot guarantee I'll get to read them prior to the presentation. My sincere apologies for the unusually short window of opportunity. At any rate, here's my blurb: ---------------------------------------- My initial presentation will be limited to 5-7 minutes since panel will consist of a number of members. Following everyone's initial presentation, there will be a discussion driven in part by the questions from the audience. LINUX AS A STANDARD I feel that considering linux as a standard is on one hand a kind of a paradox as it is built on the premise that individual truly can tweak it to heart's content and therefore it is relatively unlikely that any two Linux boxes would look and/or perform the same. Yet, on the flip-side of the coin Linux stands as a most successful offspring of the GNU movement and as such it is the most revolutionary and therefore the standard-setting OS in a category where it has no competition. Furthermore, this diversity it offers perhaps stands in its own light as a kind of a standard offering the end-user to shape their computer as a personalized instrument. PLANET CCRMA/DeMuDi/THAC'S RPMS/AUDIOSLACK The diversity seemingly suggests lack of standards, yet the software packages in most cases seamlessly compile on various distributions. This diversity is simply a byproduct of the diversity of the commercial Linux distributions. This is where lies perhaps the biggest problem with Linux, and that is the issue of different file tree across the different distributions which introduces hurdles for the "compile-from-the-source" crowd and in part feeds the demand for the prebuilt distros and subsequent fragmentation (a vicious circle if you like). KERNELS There is no "standard" audio kernel even though some of the kernel releases in conjunction with patches yield better performance. This diversity is however irrelevant as most of the applications work just fine on different sub-versions of the same kernel without a recompile. Therefore such disparity is more of a nuisance for the end-user than a potential standard-breaking anomaly. Furthermore the fix for such disparity is provided via aforementioned distributions. APPLICATIONS The powerful thing about Linux is that while everyone is welcome to contribute their own ideas or even design their own applications from ground-up, the strongest concepts rather than most developed applications are the ones who set the standard (i.e. JACK, ALSA, etc.) which is not always the case with the commercial proprietary World where often PR plays a critical role (i.e. VHS vs. BETAMAX -- although this is not the best example as this is not software-related but you get my point). Eventually, the strongest concepts do become also the most developed ones, but due to the fact that the source is readily available and that other developers choose to implement and therefore support those interfaces which look most promising, should there ever a new standard arise it will always have the chance to rise and overcome the leading standard, no matter how well the leading standard is established, and will likely do so in a least painful fashion for the end-user (i.e. ALSA vs. OSS as opposed to OS9 vs. OSX transition). Finally, open-source nature of the software minimizes the potential for misrepresentation of the format's features (a.k.a. false advertising in the commercial world). This is where Linux truly shines. That being said, Linux has its own share of disparate formats which impede the development of a standard (i.e. every sequencing software has a different format for saving the sessions). However, it is my feeling that this is simply a transitional phase and in due time the strongest will prevail. As far as the standard or core applications of the Linux community are concerned, I really do not wish to go there as that may spawn heated discussion which may completely detract from my goals. Besides, it is exactly this individualized preference that drives the diversity in Linux's software offering. AUDIO-RELATED STANDARDS THAT CAME FROM LINUX COMMUNITY (in no particular order -- it's 3am, give me a break ;-) Jack, LADSPA, LASH, ALSA, Ogg/Vorbis, others? (Lash is especially interesting as it is designed to unite seemingly different standards under one umbrella session controlling mechanism which is something unique for the Linux platform -- other proprietary formats are imho harder to unite under such a meta-standard, if you like, because they are often conceived to work just by themselves and do not necessarily encourage efforts from various competitive companies to conform to them; they rather come up with their own standard unless the existing standard is too strong to compete with which in either case results in a less adequate solution for the end-user) What is both interesting and in part detrimental (at least in short-term) to the Linux audio community is that many formats due to their openness are not readily supported by the proprietary world as they have no profit-making value (i.e. Apple's DRM-ed AAC is safeguarded by Apple so that they can profit from licensing it to other companies and/or locking in their iTunes/iPod market). One final remark on Linux standards as a whole is that Linux holds an upper hand when it comes to longevity of their standards as they are not encumbered by the IP limitations imposed by a particular company and therefore directly dependant on the company's longevity. ---------------------------------------- Sorry for the messy spill of thoughts, hopefully you'll get the main points of my ideas. I am just too tired at this point to try to clean-up my prose. I would really appreciate your thoughts as well as any potential additions you may have. Many thanks! Best wishes, Ivica Ico Bukvic, composer & multimedia sculptor http://meowing.ccm.uc.edu/~ico/ --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.784 / Virus Database: 530 - Release Date: 10/27/2004

19 years, 6 months

[linux-audio-dev] gtkmeter and threads?

by Dan Mills

Hi all, I am working on a project that makes very heavy use of the gtkmeter code (borrowed from JAMIN), and seem to have a hard to track down problem.... I am using jack so there are a few threads involved and the meters are updated from a g_timeout_add timer callback, the update_meters function is protected by gdk_threads_enter/leave. The problem is that in spite of this I still sometimes get the GUI locking up. There are no locks shared between the GUI and the DSP code and when this happens the DSP continues to run just fine. I remember a CVS version of JAMIN used to do something similar? Does anyone here remember what the cure was, it might give me some hints.... Regards, Dan.

19 years, 6 months

Re: [linux-audio-dev] Linux and Standards

by lazzaro

On Sat, Oct 30, 2004 at 03:23:04AM -0400, Ivica Ico Bukvic wrote: > AUDIO-RELATED STANDARDS THAT CAME FROM LINUX COMMUNITY (in no > particular > order -- it's 3am, give me a break ;-) > Jack, LADSPA, LASH, ALSA, Ogg/Vorbis, others? RTP MIDI was prototyped on Linux (sfront). And while I'm pretty sure Eric Scheirer prototyped saolc (MPEG 4 Structured Audio) on SGI IRIS, a lot of the late-stage debugging and Corrigenda changes were done as part of sfront. Although, in the interest of full disclosure, I switched my desktop to OS X a few years ago, so at this point its fair to say the reference platform going forward for sfront-related standards work is OS X ... although if I had enough energy to maintain two desktops I'd make the second one Linux :-). --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu ---

19 years, 6 months

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 October 2004