Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7440 discussions

[linux-audio-dev] BU FIRSATTAN RARARLANIN.

by MARAMARA Erotik Market

DIKKAT VIDEO CD : Iddia ediyoruz.. Hic bir yerden temin edemeyeceginiz ses ve g�runtu kalitesi ile yuzlerce porno video CD. arSivimiz yenilenmistir. istemis oldugunuz video CD.ler bire bir yollanir kesinlikle isteginiz harici alakasiz baSka video CD.ler yollanmaz. Anal. Oral. Vajinal. Grup. Zenci. FethiS. Ayak fethiS. Gay. Zenci gay. Trans. Transexual. Lezbiyen ve daha bircok ceSit .... <http://www.erotik.sites.cc/> ZENGIN URUN CESITLERIMIZ : Sisme Bebekler ..... (Erkek & Bayan) Kesinlikle size hayir demeyecek. Vibrat�rler ........ Istediginiz boy ve ebatlarda (Vajinal/Anal/catal.Pilli.Motorlu.TitreSimli) Suni Vajinalar ..... Asla gerceginden ayirt edemeyeceksiniz (Gercek ten hassasiyetinde) Reailistik Penisler. Gercek ten hassasiyetinde ve dokusunda (Vantuzlu/Deri kemer kilotlu) Vakum Pompalari .... Ereksiyonu kolaylastirici ve duzenli kullanimlarda peniste irilesme saglar. Geciktiriciler ..... Erken boSalmayi dert etmeyin (Sprey ceSitleri/Kremler) Kremler ............ Anal ve Vajinal iliSkilerde kullanabileceginiz kayganlaStirici krem ceSitleri Uyandiricilar ...... Cinsel istek uyandirici haplar ve damlalar. Yapmaniz gereken tek Sey <http://www.erotik.sites.cc/> TIKLAMAK .. NOT : BU MAIL REKLAM AMAcLI OLUP HIcBIR SEKILDE TARAFIMIZDA KAYDINIZ BULUNMAMAKTADIR. ILGI ALANINIZIN DISINDA ISE EGER LUTFEN DIKKATE ALMAYINIZ TESEKKURLER..

21 years, 6 months

[linux-audio-dev] request for a small app

by Dave Phillips

Greetings: I'm setting up some machines for people who want to start working with Linux audio applications. I've installed RH 8.0 and the PlanetCCRMA software, and I'm sure the users will be very pleased with these systems. However, one of the guys wants a simple app that I'm not finding (or am overlooking on my own site). He mostly wants to play his external MIDI keyboard through his soundcard (SBLive), which is no problem, but he'd like to be able to see what patches he selects via program changes sent from his keyboard. I'm wondering if it might be possible to whip up a small app that displays the following: ALSA/JACK connection status patch name update MIDI message flow (minus active sensing, of course) I'm imagining a simple 1-panel app that just lets him know that his keyboard is working and what are his selected patches. Yes, I know he can do this in MusE but he isn't interested in sequencing yet, he just likes to jam out on his keyboard. He's been using some similar app under Windows 3.1 (!!!), it would be nice if I can give him something under Linux that's at least as amenable. Comments, suggestions ? Best regards, == Dave Phillips The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://linux-sound.org Currently listening to: Brian Eno, "Unfamiliar Wind"

21 years, 6 months

[linux-audio-dev] BU FIRSATTAN RARARLANIN.

by MARAMARA Erotik Market

21 years, 6 months

Re: [linux-audio-dev] shared memory tools?

by Juhana Sadeharju

>From: "Kjetil S. Matheussen" <k.s.matheussen(a)notam02.no> > >Just define a common filename_prefix for all your processes, >and let them call the function: >You can find aipc at http://www.notam02.no/arkiv/src/k_jack.tar.gz/aipc/ I will take a look at it as soon as possible. Thanks. >From: rm <async(a)cc.gatech.edu> >> Could somebody please write these routines to me? > > yikes! [ insert nasty comment here ] What is wrong in asking somebody expert to write these routines for me? Should I write slowly everything myself and feel like a brave hacker, or should I just get the application written as soon as possible? The old hacker tradition a la A. Cox et al (did he wrote some memo on open source coding) should be forgotten yesterday. If people need utils or algorithms, they should be encouraged to ask them instead of spending days in thinking the best approach (which could kill all the fun). In any case, change in attitude does not make a harm at all, instead, we might end up to see more finished software, and less unfinished software. Experience talks. Best regards, Juhana

21 years, 6 months

[linux-audio-dev] Re: Merhaba..

by Hande

21 years, 6 months

RE: [linux-audio-dev] How to delay video?

by Sreelal Chandrasenan

Hardware video delay price is around $2500-$3500. Cost is based video delay time. These are having about one second delay. -----Original Message----- From: Anders Torger [mailto:torger@ludd.luth.se] Sent: Friday, March 07, 2003 11:22 AM To: linux-audio-dev(a)music.columbia.edu Subject: Re: [linux-audio-dev] How to delay video? On Friday 07 March 2003 10.04, Nick Bailey wrote: > Just at thought, but the best place to insert the delay would surely > be the MPEG data stream. Unfortunately, I don't know of any DVD > players which have MPEG out on the back, presumably because of the > Movie maffia being afraid you can take stills of their beautiful art > and make it into a lowly mouse mat or something. Since MPEG is ?about > 2Mb/sec (just guessing), it should be quite easy to buffer a few > seconds of it. > > Incidentally, RGB would be better than the S-Video: the chrominance > in S-Video is still band-limited and QAM, but separate from the > luminance (hence the S) so that they don't interfere with eachother. Ok, I see there are some hardware solutions in separate boxes, which probably works quite well, but price is quite high, it seems to be at least 5000 US dollars to get a video delay box. /Anders

21 years, 6 months

[linux-audio-dev] [ANN] RTMix software interactive multimedia interface version 0.7 released (3/10/03)

by Ivica Bukvic

Hello fellow musicians, composers, multimedia sculptors, and developers! It is my pleasure to announce to you the newest release of RTMix version 0.7. New improvements include: *Internal error widget has been removed. *External Error Log now became a general purpose Console. *Added visuals for monitoring of data flow at the bottom of the external Console. *Sped-up the start-up time by 300-400% (literally :-) *Fixed bug where global transport events did not execute on a local client causing many scripts to fail. *Reordered Tabs on the main widget. *Made External resizable widgets resizable only when performance was not in session (in order to minimize cpu-utilization by RTMix during the performance settings). *Fixed Metronome weird resizing bug. Now when the meter is changed, the widget resizes appropriately. *Fixed color coding errors for the notification interface. *Re-arranged the settings saving routines. *Added new parameters to the config file. *Added networking authentication code and made it configurable in the settings tab. *Added filter for events in order to disable potentially malicious sys-calls to be executed. *Fixed gazillion (literally :-) bugs in the parsing engine. *Standardized error and logging output messages. *Color-coded Console messages. *Added "go-to-error" feature. *Implemented MIDI protocol as a separate thread. Users can now use MIDI for real-time events, as well as MIDI routing. *Provided new tabs in the settings menu that enable user to specify the appropriate MIDI port. *Implemented OSC (Open Sound Control) for inter-app communication. *Implemented generic OSC network communication. *Implemented OSC routing for the purpose of sharing the MIDI port. *Enabled variables to be included in notification interface messages. *Enabled multiple instance of variables and MIDI parameters to be included in functions, assigns, and events (sys calls and others). *Fixed metronome's inconsistent resizing. *Fixed bug where BPM's on the metronomes 2-4 were corrupt. *Jump events now interpret events they jump to in a proper fashion. *Added full-fledged HTML documentation (Yay!) *Included more tutorials and provided better annotations for the older ones. *Made apply button disabled in the settings menu, unless something was changed. *Made MIDI monitoring and MIDI logging buttons disabled by default, unless the real-time monitoring is enabled. *Added color-coding and more verbose descriptions of the real-time events in the table. *Enabled differentiation between keyboard presses and releases and their mappings to the real-time events. *Added line-number tool for the editor. *Fixed behavior of the probability parameters. *Annotated more parser's warnings. *Implemented protection against infinite recursion scripts. *Other stuff that I cannot think of at this moment. --------------------------------------------------------------- RTMix is downloadable here: http://meowing.ccm.uc.edu/~ico/rtmix-latest.tar.gz (approx. file size is 4.8MB). For more info, see the included HTML docs, or visit the author's webpage at http://meowing.ccm.uc.edu/~ico/ RTMix currently runs only on Linux, although the transparency of code should make it easily portable to other Unix platforms supporting Qt toolkit. --------------------------------------------------------------- If you are not familiar with RTMix, here's a quick overview: What is RTMix? RTMix is an open-source (GPL-licensed) software application designed to provide stable, user-friendly, standardized, and efficient performance interface that enables performer(s) to interact with both the computer and each other in the least obtrusive fashion. What this means is that RTMix offers an array of visual stimuli that can be utilized on-stage in order to coordinate various performing forces utilizing diverse media. What do I need it for? How many times have you witnessed an interactive work that requires coordination between the composer and performer, composer usually being off-stage and posing as an aircraft navigator sending out all kinds of signals with waving hands and other distracting (perhaps even comical) physical gestures? Have you ever questioned computer's off-stage presence when it has an important role in generating the resulting sonic landscape (or even a multimedia setting)? Did you ever wish to have an elegant on-stage interface that is easy to use and furthermore provides the least amount of distraction for the performer(s) -- an interface that offers standardization, transportability, and most importantly low cpu-footprint, therefore enabling user to utilize majority of processor cycles for the stuff that matters the most -- the content-generation, processing and reproduction? Have you ever wished to have your work more "transportable", to have it more accessible and more easily performable in settings where you were not physically available to provide technical support to the not-so-computer-literate performer? Did you ever write a chamber acoustic work that required considerate amount of coordination but you did not want to use a conductor? How about a work for a large performing groups? Do you use powerful Music-N languages for real-time work but do not have an elegant interface for real-time performance settings? Are you a PD/Max/MSP/jMax object-oriented multimedia composer, but do not want to deal with designing the user-interface for your contraptions, nor with the lack of standardization such interfaces impose on end-users (i.e. performers other than the composer themselves)? Did you ever feel like using only one multimedia tool at a time was limiting your creativity (i.e. Csound, RTcmix, Supercollider, Pd, Max/MSP, etc.) and that you always wanted to have multiple audio applications to coexist in your work? If you have answered any of these questions positively, then RTMix just might be the answer to your needs :-). Ivica Ico Bukvic, multimedia sculptor http://meowing.ccm.uc.edu/~ico P.S. Apologies for cross-posting! Some mailing lists ate up my original post :-(

21 years, 6 months

[linux-audio-dev] MWPP status for SF IETF meeting ...

by John Lazzaro

Hi everyone, The pages fly off the calendar, and its time for another IETF meeting -- MWPP is getting pretty close to Last Call, I posted a few outstanding timing issues to: http://www1.ietf.org/mail-archive/working-groups/avt/current/msg02221.html that might be of interest to some LAD folks ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

21 years, 6 months

[linux-audio-dev] For Sale Digital Audio Adapter

by Santoso Toto

for sale Audioscience ASI4312 new surplus never installd 2 unit and ASI4133 1 unit price us$ 250per unit if you interest please contact to us E-mail:yuripid@yahoo.com,Than's __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/

21 years, 6 months

[linux-audio-dev] Re: [Alsa-devel] Audigy1 MIDI input, wavetable support?

by Josh Green

On Fri, 2003-03-07 at 07:44, Mark J Roberts wrote: > I am trying to load a soundfont into my Audigy1's wavetable and play > it with a MIDI keyboard. I am using kernel 2.5.64. > > MIDI output verifiably works. However, MIDI input does not. The > cable and keyboard are not the problem--I've tried them with an > es1371, and I easily got MIDI input working. > > My procedure with the Audigy1: > > cat /dev/snd/midiC0D0 > watch /proc/interrupts > watch /proc/asound/Audigy/midi0 > > No interrupts occur and no bytes are read. I have also tried using > aconnect to connect the inputs. Does anyone else see this behavior? > > I've got one more question. What program should I use to configure > the wavetable and load the soundfonts? I found a couple versions of > "awesfx", neither of which was compatible with my ALSA. > > I know that ALSA contains support for the wavetable of the EMU8k and EMU10k series of cards (AWE 32/64 and Live! respectively). I'm not absolutely sure whether the wavetable on the Audigy is also supported, but chances are it is. The SoundFont loading API is OSS based, but ALSA uses it so awesfx (sfxload utility, etc) should work (provided the API is actually there for the Audigy). I'm convinced that software synthesis is the way to go. It allows for easier routing of the synthesized data (via Jack for example) and supports any sound card. This is the approach I have gone with with Swami (http://swami.sourceforge.net) the successor to the Smurf SoundFont Editor which was based on the OSS awesfx API. Swami uses FluidSynth (http://www.fluid-synth.org - was previously called iiwusynth) to do software synthesis of SoundFont files. Using software synthesis gives us these additional features over current Linux supported hardware solutions: - Modulator support, allowing for real time modulation of effects with MIDI controllers (or with GUI controls from Swami) - Customizable Reverb/Chorus (EMU10k doesn't have support for these effects in Linux) - Routing of audio via Jack, opening up a whole world of audio processing, effects, etc. The downside is of course the CPU usage, so in the future I will likely be re-adding support to Swami for the hardware wavetable OSS API. If you want to check these projects out, you can either wait a few days for FluidSynth 1.0 to be released which a release of Swami will follow shortly after, or you can get Swami CVS and FluidSynth CVS. Cheers. Josh Green

21 years, 6 months

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