Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Wednesday 05 February 2003 05.21, Josh Haberman wrote: [...] > What platforms are not supported that you would like to see? There > is a list of currently supported platforms at > Well, that covers it, basically. I bet a few users of PDAs, consoles, vari

Re: [linux-audio-dev] PTAF link and comments

On Wednesday 05 February 2003 04.54, Tim Hockin wrote: > > Oh, there's one thing to keep in mind: You need one gain control > > (or pair of them) per output, or it won't be all that cool in > > real life... > > really? I don't know. I still don't even really see where it will > be used at all exc

Re: [linux-audio-dev] PTAF link and comments

On Wednesday 05 February 2003 04.38, Tim Hockin wrote: > > Any suggestions for scripting language? Python, Lua, Java...? > > (Though > > TCL? easy, cross platform.. Maybe Perl? Dunno... Both seem to be rather "messy" for non-programmers to get into - and by all means, I expect most serious GUI

Re: [linux-audio-dev] newest audio server for Linux (yep, yetanother)

On Tue, 2003-02-04 at 18:03, David Olofson wrote: > Would be cool if even more platforms were supported, but OTOH, in the > case of Audiality, that's mostly for games that use it as a sound > engine - and SDL works fine for that. What platforms are not supported that you would like to see? Ther

[linux-audio-dev] XAP spec - early scribbles

All - here are some early scribbles of a XAP spec. I took the doc that I wrote as an overview and started formalizing it. Please read it over and pooint out the places where it is missing stuff? The Table of Contents needs a lot more meat. Once I have that, I can write a lot or a little on each

Re: [linux-audio-dev] PTAF link and comments

> Oh, there's one thing to keep in mind: You need one gain control (or > pair of them) per output, or it won't be all that cool in real > life... really? I don't know. I still don't even really see where it will be used at all except on returns from sends.

Re: [linux-audio-dev] PTAF link and comments

> Any suggestions for scripting language? Python, Lua, Java...? (Though TCL? easy, cross platform.. Maybe Perl? But this goes beyond what I was suggesting. I meant to suggest something like: CUT RES And it would draw the tim_bg.xpm, with two knobs on it. Knob.

Re: [linux-audio-dev] PTAF link and comments

On Wednesday 05 February 2003 02.06, Tim Hockin wrote: [...wrappers; transforming plugins...] > It's not pretty, but it is useful. LADSPA plugins in a > XAP<->LADPSA wrapper. VST plugins in a XAP<->LADSPA wrapper. XAP > subnets in a XAP<->XAP wrapper. Yeah, I can't deny that - but I can't think

Re: [linux-audio-dev] PTAF link and comments

On Wednesday 05 February 2003 01.58, Tim Hockin wrote: > > What I'm saying is basically that it's not a goal in itself to > > create our own "standard" here. If we can get along with the GMPI > > group and something useful gets out of it, things will be better > > for everyone. What this would mean

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Tuesday 04 February 2003 21.47, Josh Haberman wrote: [...] > Right now the only ways to choose a callback model in Linux audio > applications are: > > * use JACK. Using JACK directly only makes sense for: >1. applications whose only possible use in in a JACK graph > (jackrack) 2. applicatio

Re: [linux-audio-dev] PTAF link and comments

> > Add a flag that says they are a wrapper, and a flag on the control > > that changes the universe? What if it is multiple controls? > > *Now* I actually get what you're talking about. ;-) > > Audiality running as a XAP plugin would be a typical example, as it > > Anyway, it's even more hair

Re: [linux-audio-dev] PTAF link and comments

> What I'm saying is basically that it's not a goal in itself to create > our own "standard" here. If we can get along with the GMPI group and > something useful gets out of it, things will be better for everyone. > What this would mean to XAP as such is uncertain, of course - but I > think we

Re: [linux-audio-dev] PTAF Specs

On Tuesday 04 February 2003 21.17, Tim Hockin wrote: > > Overall PTAF is supprisingly similar to XAP (which is > > encouraging), there are just some differences in emphasis. Us LAD > > people tend to be simplecity freaks. I think its one of the > > really good things about LADSPA. > > I think that

Re: [linux-audio-dev] PTAF link and comments

On Tuesday 04 February 2003 21.12, Tim Hockin wrote: [...] > > > > Well, there also needs to be a way for a plugin to wrap other > > > > formats, and change all it's metadata. I imagined that a > > > > plugin couls tell the host that it needs to be re-examined - > > > > XAP_EV_GESTALT - or somethi

Re: [linux-audio-dev] newest audio server for Linux (yep, yetanother)

On Tue, 2003-02-04 at 13:41, Bob Ham wrote: > On Tue, 2003-02-04 at 20:47, Josh Haberman wrote: > > > Imagine being able to write to an API as simple and well-designed as > > this: > > Just out of interest, why are paNoDevice, paFloat

Re: [linux-audio-dev] PTAF link and comments

On Tuesday 04 February 2003 20.56, Tim Hockin wrote: > > Hello everybody, > > > > I'm one of the PTAF authors and I've just subscribed to > > this list, seeing the standard is discussed here. I will > > try to answer your questions and to collect feedback. > > I apologize for this long mail. > > WE

Re: [linux-audio-dev] [ANN] Bandlimited LADSPA Oscillator Plugins ('BLOP') v0.2.6

On Tue, 4 Feb 2003 14:51:41 -0800 (PST) Tim Hockin <[EMAIL PROTECTED]> wrote: > > The code snippet looks okay to my eyes: > > > > loop_index = loop_index == 0 ? 1 : loop_index; > > loop_index = loop_index > 64 ? 64 : loop_index; > > int rst = f_round_i(reset); > > int i; > > > >

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

Steve Harris wrote: On Tue, Feb 04, 2003 at 07:10:39 -0500, Taybin Rutkin wrote: On Tue, 4 Feb 2003, Abramo Bagnara wrote: Despite that I strongly think that an audio server that not permit in native way the traditional approach (what you call blocking approach) will never achieve the dr

Re: [linux-audio-dev] watchdog timeout on realtime operation

Probably you need to be running as root. I don't know about Muse myself, since I don't use it, but most apps that have a -R or -rt option require you to be root for real-time scheduling. hth, dgm Son of Zev wrote: Hi On loading MusE with the -R option I get this error after a few seconds

Re: [linux-audio-dev] [ANN] Bandlimited LADSPA Oscillator Plugins('BLOP') v0.2.6

On Tue, 2003-02-04 at 22:22, Frank Barknecht wrote: > src/sequencer64_1675.so.c > loop_index = loop_index == 0 ? 1 : loop_index; > loop_index = loop_index > 64 ? 64 : loop_index; > int rst = f_round_i(reset); > int i; > > Where's the error? With C, you can only (or at least yo

Re: [linux-audio-dev] [ANN] Bandlimited LADSPA Oscillator Plugins ('BLOP') v0.2.6

> The code snippet looks okay to my eyes: > > loop_index = loop_index == 0 ? 1 : loop_index; > loop_index = loop_index > 64 ? 64 : loop_index; > int rst = f_round_i(reset); > int i; > > Where's the error? you can't declare a variable except at the top of a block. Newer compile

Re: [linux-audio-dev] [ANN] Bandlimited LADSPA Oscillator Plugins ('BLOP') v0.2.6

Hallo, Mike Rawes hat gesagt: // Mike Rawes wrote: > BLOP is a set of LADSPA plugins - after way too long, it's up to v0.2.6 I get a strange error: || gcc -DPACKAGE=\"blop\" -DVERSION=\"0.2.6\" -DSTDC_HEADERS=1 -DHAVE_STRDUP=1 |-DHAVE_LIBM=1 -I. -I. -I/usr/include -Iinclude -I.-pipe -Wal

Re: [linux-audio-dev] newest audio server for Linux (yep, yet

> I am interested to hear responses to this. Once PortAudio v19 is > released, would you all as application authors be willing to adopt it in > your programs? If so, why not? In my opinion, the only group of PortAudio is the only solution I was looking at for output. It just seems right.

Re: [linux-audio-dev] newest audio server for Linux (yep, yetanother)

On Tue, 2003-02-04 at 20:47, Josh Haberman wrote: > Imagine being able to write to an API as simple and well-designed as > this: Just out of interest, why are paNoDevice, paFloat32, etc, defines instead of const values? Bob -- If y

[linux-audio-dev] New Tkeca website!

Hi, I've uploaded the tkeca website. Take a look of this: http://tkeca.sourceforge.net I know, I know ... I'm not a graphic designer. Regards, Luis Pablo Gasparotto Ahora podés usar Yahoo! Messenger desde tu celular. Aprendé cómo hacerlo en Yahoo! Móvil: http://ar.mobile.yahoo.com/sms.html

Re: [linux-audio-dev] PTAF link and comments

On Tuesday 04 February 2003 20.12, Paul Davis wrote: > >However, namespaces don't really solve this; they just give it a > >different syntax and some type checking. The latter is nice, of > >course, but writing SomeNamespace::SomeSymbol instead of > >SomeNamespace_SomeSymbol... well, what's the poi

Re: [linux-audio-dev] newest audio server for Linux (yep, yetanother)

On Tue, 2003-02-04 at 06:03, Paul Davis wrote: > >Despite that I strongly think that an audio server that not permit in > >native way the traditional approach (what you call blocking approach) > >will never achieve the driving role we'd need. > > if linux developers continue to work with this trad

Re: [linux-audio-dev] PTAF Specs

> Overall PTAF is supprisingly similar to XAP (which is encouraging), there > are just some differences in emphasis. Us LAD people tend to be simplecity > freaks. I think its one of the really good things about LADSPA. I think that if we can reach common ground, we can all benefit. I'd love to co

Re: [linux-audio-dev] PTAF link and comments

> > Yeah, but is it really that useful? Ok, VST seems to survive with the > > same restriction, but I'm not sure if it actually solves more > > problems than it creates. > > Agreed, in practice you can connect things together if you allow arbitrary > ranges. Well, at some point we talked about

[linux-audio-dev] [ANN] JACK Rack 1.2.0

Hi all, No response to the beta testing request, so I'll have to subject you all to a likely hairy release :) Arbitrary channels are the biggest thing. Also, previous save files will no longer work as the save files use XML now. Sorry, but it's better to change it now instead of later as changi

[linux-audio-dev] [ANN] Bandlimited LADSPA Oscillator Plugins ('BLOP') v0.2.6

BLOP is a set of LADSPA plugins - after way too long, it's up to v0.2.6 Website: http://blop.sf.net This release includes: * Full RDF metadata, for use with liblrdf * Bandlimited oscillators (no aliasing noise) Sawtooth Square Variable width pulse Variable slope triangle

Re: [linux-audio-dev] PTAF link and comments

> Hello everybody, > > I'm one of the PTAF authors and I've just subscribed to > this list, seeing the standard is discussed here. I will > try to answer your questions and to collect feedback. > I apologize for this long mail. WELCOME! I'm excited to see one of the more well-known plugin compan

Re: [linux-audio-dev] PTAF link and comments

>However, namespaces don't really solve this; they just give it a >different syntax and some type checking. The latter is nice, of >course, but writing SomeNamespace::SomeSymbol instead of >SomeNamespace_SomeSymbol... well, what's the point, really? because ... using namespace SomeName

RE: [linux-audio-dev] Question regarding Usb-midi and Midisport 2x2

> After that, the device should be reset, which should result in disconnect > and "new device connected" messages. In theory, fxload does this > automatically. > This is exactly what happens but only when using ezusb2131. I am not sure if I am running latest version of fxload, furthermore if I tr

Re: [linux-audio-dev] PTAF link and comments

[Oops. Now I've done it all - this one was originally slightly over the 40 kB limit. *hehe*] On Tuesday 04 February 2003 03.04, Laurent de Soras [Ohm Force] wrote: > Hello everybody, > > I'm one of the PTAF authors and I've just subscribed to > this list, seeing the standard is discussed here. I

RE: [linux-audio-dev] newest audio server for Linux (yep, yet another)

> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Mike > Andrews > Sent: Tuesday, February 04, 2003 8:50 AM > To: [EMAIL PROTECTED] > Subject: Re: [linux-audio-dev] newest audio server for Linux (yep, yet > another) > > I'm the lead developer on the

Re: [linux-audio-dev] PTAF link and comments

David Olofson wrote: > > As long as you connect ins and outs of the same type, they'll > generally have compatible ranges. If not (say, your filter can't > handle more than Nyqvist/4, but the PITCH output that controls it has > no absolute limits), you most probably want *clamping* rather than >

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Mon, 3 Feb 2003, Paul Davis wrote: > no sign of that. this is the same old design. sigh. no sample sync, > the whole thing is still based on the idea of applications deciding > what and when to do their stuff. sigh, sigh, sigh. it looks like a > decent thing for network-based apps, but nothing

Re: [linux-audio-dev] PTAF link and comments

On Tuesday 04 February 2003 08.54, Steve Harris wrote: > On Tue, Feb 04, 2003 at 02:11:22 +0100, David Olofson wrote: > > PTAF uses float, subdivided in four ranges; [0,.25], [.25,.5], > > [.5,.75] and [.75,1], where the lower two ranges are for real > > time use, and the higher two are for off-lin

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

>Despite that I strongly think that an audio server that not permit in >native way the traditional approach (what you call blocking approach) >will never achieve the driving role we'd need. if linux developers continue to work with this traditional model, then yes, i think you are right and its a

[linux-audio-dev] PTAF Specs

OK, I've read the more thoroughly now. On page 23 you have a list of properties (ie. metadata), some of these should be per-port, and the generic ones (name, authors etc.) should probably follow the qualified dublin core standard. http://dublincore.org/ It makes sense to me that versions should f

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Tue, Feb 04, 2003 at 07:10:39 -0500, Taybin Rutkin wrote: > On Tue, 4 Feb 2003, Abramo Bagnara wrote: > > > Despite that I strongly think that an audio server that not permit in > > native way the traditional approach (what you call blocking approach) > > will never achieve the driving role we'

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Tue, Feb 04, 2003 at 07:15:07 -0500, Taybin Rutkin wrote: > On Tue, 4 Feb 2003, Steve Harris wrote: > > > MAS itsself its not suitable for RT audio*, but I suggested that we might > > want some MAS<->JACK interfaces for network transparent audio, and left a > > bussiness card, they seemed enthu

[linux-audio-dev] watchdog timeout on realtime operation

Hi On loading MusE with the -R option I get this error after a few seconds allan@littlewolf2 allan]$ muse -R Loading required GL library /usr/X11R6/lib/libGL.so.1.2 no locale / ALSA port add: , 64:0 flags 3 0x7f Track: unknown tag at line 236 ReadEvent: warning: event not in part: 0 - 12288 -

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Tue, 4 Feb 2003, Steve Harris wrote: > MAS itsself its not suitable for RT audio*, but I suggested that we might > want some MAS<->JACK interfaces for network transparent audio, and left a > bussiness card, they seemed enthusiastic, but I never heard back from the > MAS guys. Yes, I spoke to t

Re: [linux-audio-dev] Question regarding Usb-midi and Midisport 2x2

Ivica Bukvic wrote: > I am running MDK 9.0 and am trying to get Midisport 2x2 to hotplug. The > problem is that if I use the ezusbmidi script (obviously coupled with > the right firmware and hotplug stuff) the /var/log/messages definitely > notes its successful recognition of the device and announc

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Tue, 4 Feb 2003, Abramo Bagnara wrote: > Despite that I strongly think that an audio server that not permit in > native way the traditional approach (what you call blocking approach) > will never achieve the driving role we'd need. Well, given that Ardour, amsynth, alsaplayer, and freqtweak al

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

On Mon, Feb 03, 2003 at 06:22:26 -0500, Ivica Bukvic wrote: > Kidding aside, this may prove to be so ubiquitous that it will quickly > overshadow all other implementations. It's the MAS audio server that is > going to be implemented into the X server itself and will be > network-transparent. I spo

Re: [linux-audio-dev] PTAF link and comments

On Tue, Feb 04, 2003 at 03:04:09 +0100, Laurent de Soras [Ohm Force] wrote: > > * GUI code in the same binaries is not even possible on > > some platforms. (At least not with standard toolkits.) > > I'm presonally not familiar with Linux GUI toolkits (I'm > confused with Gnome, KDE, X, Berlin, etc

Re: [linux-audio-dev] PTAF link and comments

On Tue, Feb 04, 2003 at 11:55:10 +0100, Laurent de Soras [Ohm Force] wrote: > > Steve Harris wrote: > > > > > PTAF uses float, subdivided in four ranges; [0,.25], [.25,.5], > > > [.5,.75] and [.75,1], where the lower two ranges are for real time > > > use, and the higher two are for off-line use.

Re: [linux-audio-dev] PTAF link and comments

Steve Harris wrote: > > > PTAF uses float, subdivided in four ranges; [0,.25], [.25,.5], > > [.5,.75] and [.75,1], where the lower two ranges are for real time > > use, and the higher two are for off-line use. > > This doesn't make snese to me, off-line and wuality should be independent. > Plugi

[linux-audio-dev] Addition to the Usb-midi problem (Midisport 2x2)

Forgot to mention that I blacklisted usb-midi and audio drivers in the /etc/hotplug/blacklist. The computer tried also to load snd-usb-audio (why?), so I blacklisted that one as well. Btw, using Alsa 9.0.rc5. Finally, even though the /var/log/messages mentions creating two pairs I/O ports (since

Re: [linux-audio-dev] newest audio server for Linux (yep, yet another)

Paul Davis wrote: > > >Kidding aside, this may prove to be so ubiquitous that it will quickly > >overshadow all other implementations. It's the MAS audio server that is > >going to be implemented into the X server itself and will be > >network-transparent. > > > >Slashdot just posted a news blurb