Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

Re: [linux-audio-dev] more on XAP Virtual Voice ID system

by robbins jacob

On Mon, Jan 06, 2003 at 12:04:23 -0800, robbins jacob wrote: >>Alternately, we could require that event ordering has 2 criterion: -first- >>order on timestamps -second- put voice-on ahead of all other event types. >This is what I was assuming was meant orignally. >However you dont have to think of them as initiasiation parameters, voices >can have instrument wide defaults (eg. a pitch of 0.0 and and amplitude of >0.0), and the parameter changes that arrive at the same timestamp can be >thought of as immediate parameter changes, which they are. True, my post was based on the assumption that there are some plugins where a certain parameter being initialized at the beginning of the voice would affect the voice over its entire duration. The only concrete example I can give is velocity maps determining use of different samples in a sampler, which doesn't apply here. Maybe a bell model where the voice-on event is considered an impulse describes what I'm talking about; ramping up the velocity after the voice has started has no effect. Irregardless, if a plugin wants to use some parameters in voice initialization, it can do so with the events timestamped at the same point as the voice-on supplying the values for initialization. For the majority of plugins all parameters are equal and some events just happen to coincide with voice-on events, as you say. --jacob robbins ....porjects, soundtank....................... _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

22 years, 8 months

[linux-audio-dev] XAP: a polemic

by Tim Goetze

this is not meant to intimidate, rather to be a wake-up call. it seems almost unreal (and certainly unprofessional) to me that an instrument plugin api is being discussed here by a bunch of people who have little to no experience in the field of software sequencers. going into implementation details at the current level of understanding of the problem space is, excuse me, ridiculous. after all, what is going to drive your instrument networks? punched cardboard? certainly not. you'll either use realtime input, or a sequencer, or, most wanted, a combination of both. the closer the integration of the event/plugin system with the sequencer, the more uses the api can be put to, with less pain. stopping short of the mark where the api becomes useful for more applications than basically sample-rate dependent event->audio converters is narrow-minded. viewing the 'host' as a blackbox supposed to 'do the rest' without caring about its internals is blatant ignorance. i do think it's reasonable to ignore my personal input since i don't offer published code to back up my views, and when i do, you'll find it centered around my personal musical needs. however there are, afaik, people from the rosegarden team on this list. it would also be helpful having werner schweer of muse fame participate in some way or other. you might also want to look at other free/open sequencer engines. for one thing, you'll find that most, if not all, are tick-based. vst[i] is a bad candidate i think because few people here will have vst host-side coding experience, and the api itself is bound to be centered around the particular coding needs of a specific company, for a specific application that drags code with it that originated in the eighties and never was subject to public source-level review. in short, the more people with hands-on sequencer experience participating, the better. none are just too few. tim ps: if this post hasn't substantially changed your ways of perceiving this matter, please don't bother answering.

22 years, 8 months

[linux-audio-dev] [ANN] Cow 0.1.0

by Kay Pruefer

Hi, Cow Outputs Waves is a waveform editor. You draw graphs for amplitude and frequency, cow synthesizes a wavfile. The GUI uses Qt. The package includes also a program to play the cow-sounds and also wavfiles with a midi-keyboard (or any other thing that can output note on/off commands) and several tools. You might be interested in this program if you are using a tracker and need cool sounds or intent to play accords and find it ugly that the wavfiles are getting shorter or longer depending on the tone pitch. Hrm. Maybe youre also interested if you dont use a tracker :) http://kuh.sourceforge.net for pre-compiled binarys for Mandrake, Redhat and SuSE have a look at: http://apps.kde.com/na/2/info/id/1457 HAND, Kay.

22 years, 8 months

[linux-audio-dev] rave + rant

by Paul Davis

i just want to stop for a moment and reflect on the power of the open source software model. for a long time, a rather glaring defect in ardour was the inability to record at a higher frame rate (say, 48kHz or 96kHz) and then easily produce an audio file of the piece at 44.1kHz, the standard for redbook cd audio. i avoided trying to add the code because i knew that resampling was complex and had some significant depth to it - i was busy enough with other things. then erik comes along with his libsamplerate library, and it took me less than 15 minutes to add the capability to the backend of ardour (plus another 45 minutes of work on the GUI to control it). now, The Unix Way calls for the use of tools like sox to do this work: small, independent applications that do one thing and do it well. Ok, that's not exactly a good description of sox, but you get the point. There is nothing wrong with this model for some purposes, especially for people who want to play around with many different possibilities. but when rob pike wrote "the unix programming environment", he was clear (at least to me) that the main strength of The Unix Way was in providing a really productive environment for *prototyping*. it turns out that its a really nice environment for getting many kinds of real work done too, especially for many experimental music folks, and i wouldn't want to see the end of the toolset that sox is just one aspect of. but ... but ... i am just glowing with the way libraries like libsamplerate and libsndfile provide the same simple "just plug it together" functionality that the unix shell and all our pipe-connected utilities do. this time, its not to being offered (directly) to command line users, but to people writing GUI-based software and thus ultimately to their users. it really makes me feel good to be able to turn around and explain to my disbelieving kids "yes, somebody wrote this really useful software and they just made it available so that other people could use it. that made it easy for me to make my software (with which i do the same) be so much more useful for many people". thanks to erik, thanks to RMS for the GPL and thanks to everybody on this list and elsewhere who is making this revolution possible. --p

22 years, 8 months

[linux-audio-dev] Compilers

by Levi Burton

Greetings, I was curious what compiler versions people have had the best luck with. I am currently using: gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113) I am considering upgrading via RPM to what appears to be 3.2 (gcc-3.2-7.i386.rpm). Good idea? Bad Idea? Thanks! Levi

22 years, 8 months

[linux-audio-dev] [ANN] ALSA Patch Bay 0.4.1

by node＠users.sourceforge.net

Hi all, Another day.. another release :) * fixed plugin stuff to work with 2.9x C++ symbols * fixed fltk compile * added an alsa-patch-bay.desktop * fixed fltk segfault http://pkl.net/~node/alsa-patch-bay.html Bob

22 years, 8 months

[linux-audio-dev] LADSPA proposal for named values

by Pascal Haakmat

Hi all, It appears as though LADSPA at the moment lacks a means to provide names for control values (this topic has probably crossed the list before so I'll try to keep it short). The common solution for this problem (e.g. as used in Steve Harris' plugin collection) is to use an integer control port to encode for the different options that the port can have, then add some text to the PortName to describe those options (e.g. "1=sin, 2=saw, ..."). This has a few drawbacks though. First, it doesn't really solve the original problem; the user is still inputting ordered numeric values, even though the relationship that is being modeled can be totally arbitrary. Second, it makes for very long PortNames, which causes layout troubles. Therefore (if such a thing does not already exist) I propose to extend the LADSPA specification with a convention: if a PortName matches the following regular expression: .+ \((\d+=.+,)*(\d+=.+)+\) (in words: any sequence of characters following by a '(', followed by one or more comma-separated 'value'='name' pairs, followed by a ')'), then the host may assume that the given values map onto the given names and display them as such. In addition, the host may suppress displaying the '(...)' part of the PortName. This proposal follows current best practices, requires no modifications to the LADSPA protocol or data structures, is easy to implement, and highly unlikely to adversely affect any existing plugins/hosts. Any comments? Pascal. -- The GNOME U sound editor: http://awacs.dhs.org/software/gnusound

22 years, 8 months

[linux-audio-dev] 2.4.20-rc1 + lowlat + preempt + alsa + jack = dead computer

by Fernando Pablo Lopez-Lezcano

[sorry for the wide distribution] Is anyone out there trying out this combination?: kernel 2.4.20-rc1 capabilities patch low latency patch preemptible kernel patch almost current alsa cvs [20021028.170432 usa pacific time] If I start jackd and then use the freqtweak jack client I get a completely dead machine in a very short time (from a few seconds to 10 or 20 seconds). Same alsa driver, but running on 2.4.19 (up to 20-pre4) seems to be fine and I can play around with freqtweak for as long as I want :-) No clues are left behind... something in the kernel is deadlocking, I guess. I tried removing first the preemptible kernel patch with the same result. Just a moment ago I tried again after removing the low latency patch and I still get the same result... that pretty much leaves alsa and the kernel. Got the same result on a laptop intel810 and an ice1712 card. Interestingly enough just the jack server running is not enough to kill the machine. Adding a jack client (just tried alsaplayer, same problem as freqtweak) kills the machine really fast. Maybe there is a problem with the scheduler when there are several SCHED_FIFO tasks competing for the processor? -- Fernando

22 years, 8 months

[linux-audio-dev] API for playing wav file samples

by Vandana

Hi, I am building a sound editor and need an API for playing 'wav' file samples. I tried the SOX API but the quality is very bad. Is there some other API, I can try. Kindly advice.

22 years, 8 months

Re: [Jackit-devel] Re: [linux-audio-dev] 2.4.20 + lowlat +preempt + alsa + jack = dead computer

by Fernando Pablo Lopez-Lezcano

> >I browsed the Kernel Source and there is only one mark_inode_dirty in > >pipe_write (in fs/pipe.c). So we know where it is hanging... > > > >And in __mark_inode_dirty (in fs/inode.c) there is one > > spin_lock(&inode_lock) > >call, and I guess that is where the whole thing is hanging. So something > >is holding that lock... how do I find out who is doing that? Apparently > >the handling of inode_lock is confined to inode.c. I'll keep reading. > > > >Maybe the pipe in question is one of the pipes that jack uses for ipc? > > seems *damn* likely ... sorry to just be chiming in with a useless comment! Do you think the problem might be jack? Some race condition that only happens (or is much more likely to happen) in 2.4.20? It does sound more like a kernel bug, but I have not seen a hung machine without having jack and clients running... -- Fernando

22 years, 8 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-dev