Re: [linux-audio-dev] Re: [linux-audio-user] denormals or ... ?

[Dave Phillips] > Tim Goetze wrote: > >> I have a patch ready that should take care of this problem. Anyone willing >> to >> give it a try in real life? (Dave got it per mail but it seems he's too busy >> ...) >> > Ach, I didn't send a report

Re: [linux-audio-dev] Re: [linux-audio-user] denormals or ... ?

[Esben Stien] >Dave Phillips <[EMAIL PROTECTED]> writes: > >> that fixed it > >I've added a note about this to: > >http://apps.linuxaudio.org/apps/all/caps I have a patch ready that should take care of this problem. Anyone willing to give it a try in real life? (Dave got it per mail but it s

Re: [linux-audio-dev] Re: [linux-audio-user] denormals or ... ?

[Leonard Ritter] >On Tue, 2007-03-13 at 10:08 -0500, Dave Phillips wrote: >> So, if anyone has anything to add to Chris's assessment, I'd like to >> know about it. If the problem is indeed related to denormals, is there >> a >> way to fix it ? Comments and suggestions are most welcome. > >i made

Re: [linux-audio-dev] scaling audio signal

[Silver Rock] > The signal scaling is just beyond my understandings, and I can´t find > any explanation on the web about it. What is the role of that in the > programm? Anyway, I will write here what it does to the audio signal > that I don´t understand. By catching code lines in functions it looks

Re: [linux-audio-dev] best option for audiovisual synchrony

[Paul Davis] >On Fri, 2006-10-20 at 22:44 +0200, Tim Goetze wrote: >> Back in the 80s, the humble Commodore 64 could be readily programmed >> to fire an interrupt on vertical sync. Have 20 years of progress >> really deprived us of this fine feature, or is it just miss

Re: [linux-audio-dev] best option for audiovisual synchrony

[Fons Adriaensen] >Input the vertical video sync signal via the audio card and analyse >its timing in terms of audio samples (e.g. using a DLL). This will >enable you to predict where the next sync will be in the audio input. Back in the 80s, the humble Commodore 64 could be readily programmed to

Re: [linux-audio-dev] Are people still writing LADSPA plug-ins?

[Jono Bacon] [...] > and announcing new plug-ins. Are people writing new plug-ins, and are > existing plug-ins getting refined and released? Yes and yes. Slowly but surely. http://quitte.de/dsp/caps.html Cheers, Tim

Re: [linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write

[Paul Davis] >On Wed, 2006-06-07 at 11:12 +0300, Jussi Laako wrote: >> Paul Davis wrote: >> > writing to a pipe is not 100% RT safe, but if the pipe is created in a >> > shm filesystem, its as close to it as you will get without ... >> >> Nowadays, there's also available a very good interface fr

Re: [linux-audio-dev] RDF for CAPS plugins

[Steve Harris] >On Thu, Apr 20, 2006 at 11:26:27 -0400, Taybin Rutkin wrote: >> I wonder why people include the protocol though? Using a java style >> reverse DNS would have worked just fine: >> >> org.ladspa.ontology would have made sense too. > >Heh, that's a whole long argument. In brief: I

Re: [linux-audio-dev] RDF for CAPS plugins

[Paul Winkler] >On Thu, Apr 20, 2006 at 10:51:20PM +0200, Tim Goetze wrote: >> The 0.3.0 CAPS release actually comes with an rdf file supposed to >> label the enumerated int ports (the Cabinet model switches and the >> SweepVF filter modes). > >Argh! I already ha

Re: [linux-audio-dev] RDF for CAPS plugins

[Paul Winkler] >On Thu, Apr 20, 2006 at 06:10:35PM +0100, Steve Harris wrote: >> On Thu, Apr 20, 2006 at 12:07:38 -0400, Paul Winkler wrote: >> > I also haven't bothered to figure out what to do with all the stuff >> > about ports, and ardour doesn't seem to need it anyway, so this version >> > o

Re: [linux-audio-dev] Free Software vs. Open Source: Where do *you* stand?

[Pete Bessman] >the salient point is that Chris stipulated that proprietary software >producers *aren't* evil! The only way they can be evil is if you >stipulate a moral code which dictates as much. I keep a good 150 or so .arr files around, stemming from the late 80s, early 90s, back when I use

Re: [linux-audio-dev] detune

[Hans Fugal] >I'm about to write a DSSI/LADSPA plugin that among other things, detunes >the signal by up to 15 cents. My understanding is that detuning is >accomplished by resampling. If that's the case, what do you do >with the time difference? Do you pad/truncate to get the same number of >sampl

Re: [linux-audio-dev] [ann] caps-0.3.0

[Giuseppe Zompatori] >Speaking about the compile flags you use for caps -O6 does nothing >more than -O3 and from -O2 upwards there's no need to specify >"-funroll-loops", also -O3 often bloats the generated code >unecessairly making it slower than -O2 AFAIK. To tell the truth, I've never evaluated

Re: [linux-audio-dev] [ann] caps-0.3.0

[Esben Stien] >Tim Goetze <[EMAIL PROTECTED]> writes: > >> Please enlighten me! > >RDF, so it's possible to categorize it and look it up quickly;). > >OT: I think it's wrong to write the type names as plurals. A formal >categorization should not use pl

Re: [linux-audio-dev] [ann] caps-0.3.0

[Esben Stien] >Tim Goetze <[EMAIL PROTECTED]> writes: > >> CAPS Audio Plugin Suite [..] 0.3.0 > >It would be great if you filled in the TYPE field;). It might just be my pre-coffee slowness but I'm afraid I can't figure out which TYPE field you mean ..

[linux-audio-dev] [ann] caps-0.3.0

The ever popular CAPS Audio Plugin Suite reincarnates as v0.3.0, a major augmentation release. CAPS is a LADSPA library that enjoys worldwide favour for its high-quality instrument amplifier emulation facilities. In addition it provides a sizeable assortment of no less sophisticated classic DSP

Re: [linux-audio-dev] 2.4.x patches?

[Lee Revell] >You seem to be stuck in 2001. Try a 2.6 kernel, it's great! OK, one more try later, 2.6.13-rt14 does it ... and it's great indeed! jackd does 64/44.1 without xrunning even while I switch to text mode and back to X. Quite impressive -- I think I'll be stuck in 2005 for the next fe

[linux-audio-dev] 2.4.x patches?

http://www.zip.com.au/~akpm/ (and schedlat.html below it) seems to have gone 404. Is anyone out there mirroring it? Thanks, Tim

Re: [linux-audio-dev] Fixed vs. floating point

[Hannu Savolainen] >This is the main reason why many audio applications use floating point >internally. However many (or most) applications do just simple >computations which are easy to do in fixed point too. > >Hint: Scale the input samples to the -1.0..1.0 range regardless of the >input prec

Re: [linux-audio-dev] linux audio apps on OSX: successes and failures

[Nicolas Pouillon] >I think the fix is even easier: your sources should be corrected in >order to include stdlib.h and not malloc.h, the latter is not stardard. Works well. Thank you! Cheers, Tim

Re: [linux-audio-dev] linux audio apps on OSX: successes and failures

[Derek Holzer] >* CAPS Plugins 0.2.3 >No ./configure at all, I had to symlink a malloc.h to a place where it could >find it [...] If you can tell me where malloc.h is on your system and how cpp can tell it's on OSX I can fix the latter. The former needs a patch, as I'm unwilling to even touch GN

Re: [linux-audio-dev] libcui - design-question

[Simon Jenkins] >On Fri, 2005-09-23 at 13:04 +0200, Tim Goetze wrote: >> >> I know of no language that fits this bill better than python. >> >Lua perhaps? >http://www.lua.org/ > >There's a somewhat Lua-oriented comparison here: >http://lua-user

Re: [linux-audio-dev] libcui - design-question

[Kjetil Svalastog Matheussen] >>breathe deeply. think of snakes. say "python". > >Are you serious? Do you know python? I hope not... > >I don`t want to start a flame-war over programming languages, >but I know both scheme and python very well, and would >never consider python as an extension langu

Re: [linux-audio-dev] ALSA features.

[James Courtier-Dutton] > Tim Goetze wrote: >> A provision for reliably identifying the mixer control(s) belonging to a >> given >> open PCM channel would be very nice to have. >> >> Cheers, Tim >> >> > > Yes, that's certainly nice to have.

Re: [linux-audio-dev] ALSA features.

[James Courtier-Dutton] > Any other suggestions? A provision for reliably identifying the mixer control(s) belonging to a given open PCM channel would be very nice to have. Cheers, Tim

Re: [linux-audio-dev] TAP EQ problems

[Tim Blechmann] >> Similar approach works fine here, too (flipping the sign of the >> addition constant at every sample or every block, depending on the >> algorithm in question). >> >> Inaudible (in fact barely measurable), code is branchless and simple. >> Perfect solution for a stupid litt

Re: [linux-audio-dev] TAP EQ problems

[Alfons Adriaensen] >Interesting. So again I'm inclined to think that the reported problem is >due to denormals. > >I usually do a very blunt ... + 1e-20 at strategic places. So far, nobody >has complained about the DC offset :-) Similar approach works fine here, too (flipping the sign of the ad

Re: [linux-audio-dev] LADSPA plugin IDs needed

[Steve Harris] >Mayube theres soneone out there with some spare space who can give you a >range? [...] >On Sun, Jul 03, 2005 at 11:31:54 +0300, Artemio wrote: >> I already created four plugins, each with mono and stereo variants, so >> I need 8 IDs to publish the plugins. And I already know that t

Re: [linux-audio-dev] All things LADSPA, your input please

[Christoph Eckert] I enjoy jack-rack with some EQ, chorus and reverb really a great fun when plugging in my acoustic guitar. LADSPAS in ardour are really cool as well as using LADSPAS in synths like ams or om directly (and om does use them excessively). I agree that the GUI interfaces for LADS

Re: [linux-audio-dev] All things LADSPA, your input please

[Thorsten Wilms] I use the great modular synth Om (http://www.nongnu.org/om-synth/) that comes with a small numer of internal modules for i/o, but realies on ladspa and dssi plugins for everything else. Currentyl it's all about sound synthesis for me, but later on I might try doing modular effec

[linux-audio-dev] All things LADSPA, your input please

Greetings, you may have seen the recent mail on this list looking for an author doing a LADSPA article in a german Linux magazine; I've decided to step in. Now, while I do have some knowledge of the technical nature of LADSPA I can't truthfully say I know all the plugins and hosts out there

Re: [linux-audio-dev] Re: What Parts of Linux Audio Simply Work Great?

[fons adriaensen] On Sat, Jun 18, 2005 at 07:24:26PM +0200, Tim Goetze wrote: Dividing computed audio into a 'professional' and an 'amateur' camp only serves to defend obsolete categories and the arbitrary borders inbetween. I can assure you that from a POV of a

Re: [linux-audio-dev] Re: What Parts of Linux Audio Simply Work Great?

[fons adriaensen] On Sat, Jun 18, 2005 at 04:04:11PM +0200, Jay Vaughan wrote: there should just be 'working audio', whether your app is a desktop app, a sound-synth, or a DAW. why should there be a difference? Why are the terms 'consumer' and 'professional' used to denote two different wor

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

[Simon Jenkins] ...which your Descriptor template can pick up without using any specialisation like this: template class Descriptor : public DescriptorStub { public: Descriptor() { UniqueID = T::UniqueID; } ... }; Just a thought. And a good one, thanks. Set me thinking and I think I

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

[Paul Winkler] I was wondering what the reason was for dropping midithing. I played with it briefly and quite liked it. Sad indeed. My ambitions at that time were surpassing the concept; I was also not satisfied with the general code quality. Leading me to wonder, how long before Milk is s

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

[Clemens Ladisch] You mean you want to omit \n and the quotes? That was always invalid in both C and C++. Makes me wonder how come it used to compile cleanly then. Now please don't tell me "it's a gcc extension so it is evil" because __asm__ is already kissing portability goodbye. You co

Re: [linux-audio-dev] Objective-C (was: gcc, you let me down...)

[Toby] I've recently been looking for an alternative *compiled* object-oriented language, because let's face it, Python is on average 10 times slower than C. Sometimes you just can't afford it. When speed becomes a crucial criterion, I usually switch to C++ extensions for Python. Easy to code

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

[Clemens Ladisch] Tim Goetze wrote: Enter gcc version 3, which drops multi-line inline assembly support. The following compiles fine with gcc 3.3.3: void f() { __asm__ ("nop\n" "nop\n"); } May compile fine, but like this a 100-line __asm__ goes

[linux-audio-dev] [ann] caps-0.2.3

The ever popular CAPS Audio Plugin Suite reincarnates as v0.2.3, a maintenance release that rectifies the last remaining denormal problems and restores the intermittently nonfunctional AmpIV gain control to its usual fine form. CAPS is a LADSPA library that enjoys worldwide favour for its hig

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

[Jussi Laako] On Sun, 2005-06-05 at 15:08 +0200, fons adriaensen wrote: My aproach to C++ is very simple: I use it as 'C with classes'. No streams, no STL, no other nonsense. Gives me the best of both worlds - clean objects and low level. Same here, except; - exceptions make error handling

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

[Erik de Castro Lopo] Tim Goetze wrote: To be honest, I don't know if it's undefined behaviour; I don't read ISO compiler ABI standards (if they exist in the first place). I was simply trusting that common sense would always allow this cross-language subclassing, apparen

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

[Erik de Castro Lopo] Tim Goetze wrote: Enter gcc version 3, moving the vtable member to memory offset 0 of a derived type even if the base type is in C which doesn't know about vtables. Relying on undefined behaviour will, sooner or later, result in tears. To be honest, I don'

Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

[Jack O'Quin] Anticlimax: ;-) Our hero sees the error of his ways. Eschewing the grotesque compromises imposed on C++ by its quixotic quest (??) for "Object Oriented Programming Without Garbage Collection" (OOPWGC), he returns to sanity, living happily ever after, writing robust, portable pr

[linux-audio-dev] [ot] [rant] gcc, you let me down one time too many

Frailty, thy name is GCC A Modern Drama in Three Scenes. Dramatis Personae: An ardent programmer and a popular C++ compiler -*- Prologue: Appalled by the rat race commonly known as the proprietary software business, our young and gifted hero joins the light side, deeply inspired by the mani

Re: Minimum reasonable latency Was: Re: ZynAddSubFX was: Re: [linux-audio-dev] some new soundfiles on-line

[Jens M Andreasen] A "synthesist" (that's my scenario), who can't hear *anything* before the end of the pipe, would be very sensitive to jitter (the deviation, or "sloppyness", between triggers and actual sound) and would therefore require the smallest of small buffers. Trading jitter for constant

Re: [linux-audio-dev] pyseq - MIDI routing with Python and ALSA

[me] >Ah, an interesting little piece of code. There seems to be a memory >leak in startMidiLoop() -- the pfds are never free()'d. My bad. All this c++ made me forget what alloca() does. Sorry. Cheers, Tim

Re: [linux-audio-dev] pyseq - MIDI routing with Python and ALSA

Hi Peter, >I remember that I looked at nam a while ago, but I must admit that I >didn't get very far with it. When I looked at your page again just now, >I noticed that the tar ball nam*.tgz has disappeared. Sorry, my fault. It's up now FWIW. >In the meantime, I've put together a little MIDI rou

Re: [linux-audio-dev] Re: [ann] caps 0.2.0

[Jens M Andreasen] >P: That thunder rumble turned into a tin-can when I watched the show > at my mother-in-laws, how is that? A lovely story. However ... >E: (mumble, mumble) Ehrmm ... I started the widening you wanted with a > chorus/flanger, but before I had time to finish the job, we went

Re: [linux-audio-dev] MIDI routing with Python and ALSA?

Hi Peter, >Does anything like this exist? If not, does some part of it exist? >For instance, it would be extremely helpful to have a Python wrapper >for ALSA structs such as snd_seq_event_t. Any thoughts would be >appreciated. I've worked on something that has many parts of what you are looking f

Re: [linux-audio-dev] Re: [ann] caps 0.2.0

[Juhana Sadeharju] >>From: Tim Goetze <[EMAIL PROTECTED]> >> >> m = l + r; >> l = dry * l + wet * reverb_l (m); >> r = dry * r + wet * reverb_r (m); >[ ... ] >>'True stereo' is, of course, marketing BS. You may argue that I suffer >

Re: [linux-audio-dev] [ann] caps 0.2.0

[Jens M Andreasen] >On tis, 2004-11-30 at 01:31 +0100, Tim Goetze wrote: >> The CAPS Audio Plugin Suite reincarnates as caps 0.2.0. >> >> * By popular demand, a 'true stereo' version of the Plate reverb >> plugin makes its appearance in this edition, so the nu

[linux-audio-dev] [ann] caps 0.2.0

The CAPS Audio Plugin Suite reincarnates as caps 0.2.0. * By popular demand, a 'true stereo' version of the Plate reverb plugin makes its appearance in this edition, so the numerous original Plate fans can get their favourite thing to play nice with hosts having trouble dealing with mono-in, stere

Re: Behringer [was Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more]

[Marek Peteraj] >> RME has provided >> "Pro" grade audio hardware when Linux Audio needed it >> in order to become a legitimate alternative to >> proprietary solutions. > >Not really. It was Paul, Thomas, and one other guy(don't remember the >name) who did. Remember it was almost no investment from

[ot] Re: [linux-audio-dev] Russian synths ?!

>http://ruskeys.net/eng/synths.php > > > Thanks Alex ! Thanks Dave!

Re: [linux-audio-dev] Roland and GPL

[Paul Davis] >>Hello. >>When this happened?? What a great move. >> >> http://www.roland.com/support/gpl/ > >it looks good, but ... > >paul[124]>unzip -l DV7-GPL-src.zip >Archive: DV7-GPL-src.zip > Length Date TimeName > >0 05-18-04 20:00 GNU-

Re: [linux-audio-dev] Utility for recording audio track with midiclock

[Gerrit Niestijl] >"Tim Goetze" <[EMAIL PROTECTED]> writes: >> fwiw, i'm achieving quite satisfying results driving MIDI out from a >> 1024 Hz RTC thread, with external hardware locking steadily onto the >> output MIDI clock stream, even at tempi up to

Re: [linux-audio-dev] Utility for recording audio track with midi clock

[Paul Davis] >until the high resolution clock timers patch is solid enough to be >used by any system, there is no way to schedule MIDI output with this >kind of resolution, and if you can't schedule it, then the receiver of >your MIDI clock signal will see a lot of jitter and may refuse to lock >t

Re: [linux-audio-dev] Traps in floating point code

[Ruben van Royen] >please note that SSE2 has support for 64bit floats (doubles) and contains an >instruction that truncates to int, irregardless of controlwords. A new enough >gcc with (-march=pentium4 or -msse2) and -mfpmath=sse will use sse instead of >the old fp unit. This has more advantages, s

Re: [linux-audio-dev] Traps in floating point code

[Ruben van Royen] >The problem is that the rounding mode affects all floating point operations, >such as multiply and divide. And normally you must do rounding and not >truncation. Thus changing the mode will change the results, and a compiler is >not allowed to do that. yes, and it is wise to ch

Re: [linux-audio-dev] Traps in floating point code

[Jens M Andreasen] >On tis, 2004-06-29 at 17:15, Steve Harris wrote: >> >integer = lrintf(fullindex); >> >fractional = fullindex - integer; >> >> I dont think this is right, fractional will be [-0.5, 0.5], rather than >> [0,1] which is more noirmal as lrintf() rounds to the nearest. >> >>

Re: [linux-audio-dev] swh plugins and fixing undenormalize

[Simon Jenkins] >Tim Goetze wrote: >>8-bit exponent and no assumption about its value made, 8 binary >>'shift', 7 'or' and 1 'and' statement if i'm not badly mistaken. and >>if i'm not, a branch will probably hurt less. >> >Th

Re: [linux-audio-dev] swh plugins and fixing undenormalize

[Tim Blechmann] >On Fri, 25 Jun 2004 17:38:24 -0500 >Jan Depner <[EMAIL PROTECTED]> wrote: > >> On Fri, 2004-06-25 at 13:49, Tim Blechmann wrote: >> > > I have a denormal fix without a branch but you probably don't want >> > > to see it ;-) >> > > It's pretty simple, just OR the bits of the expone

Re: [linux-audio-dev] Multithreaded programming for a poll model?

[Paul Davis] >>pipe()s here too. last time i benchmarked on an early 2.4 kernel, pipe >>and socketpair gave about the same timing figures, quicker than >>msgsnd/rcv. i don't remember the exact numbers but i remember being >>positively surprised. > >from the whitepapers that IBM did, the linux FIFO

Re: [linux-audio-dev] Multithreaded programming for a poll model?

[Paul Davis] [...] >currently, i use FIFO's, and i plan to switch to futexes when >they become available. NPTL uses futexes to implement condition >variables, but linuxthreads uses signals. pipe()s here too. last time i benchmarked on an early 2.4 kernel, pipe and socketpair gave about the same ti

Re: [linux-audio-dev] lock-free data structures

[Joshua Haberman] >> works just like the scheme i am using, with the exception that the >> graph management code is always run in the audio thread. lots of >> lock-free fifos for everything and their cousin, but glitch-free >> performance with absolutely no locks in the realtime code path is >> wo

Re: [linux-audio-dev] lock-free data structures

[Joshua Haberman] >1. signal graph is constructed in main thread >2. once audio starts, the audio thread runs the graph once for every >callback >3. if the main thread wants to change the graph while it's running, it >does any heavy lifting (memory allocation, etc), then sends a message >to the aud

Re: [linux-audio-dev] [OT] marketing hype

[Paul Davis] >the fact that some systems can do live repatching without xruns is >either good luck, or a function of them using very lightweight objects >that don't directly reference expensive resources. it can be done no matter the weight of the resources involved if the resource handling (alloc

[ot] Re: [linux-audio-dev] Syncronizing Sample Clocks [WAS: A bit of goodnews--paper now available for your viewing pleasure and/or comments]

[Fred Gleason] >This issue affects many more applications than just audio. *Any* system that >requires precise replication of clock (as, for example, most any digital >telecommunication scheme does) faces this dilemma. In the end, some form >*locking*, slave clock to master, is needed. A variety

[linux-audio-dev] Re: [fluid-dev] question - soundfont editing

[David McNab] >Sorry to bother you again, but there's a slight problem with your SF2 >python module. > >If the soundfont file I write out contains one or more drum presets, >'asfxload' spits an error 'loop size is too short: 0' when I try to load >the font into my sblive card. However, fluidsynth l

[linux-audio-dev] Re: [fluid-dev] question - soundfont editing

[David McNab] >Can someone please recommend a program for Linux which can easily take >presets from one or more existing soundfont files, and compile them into >a new soundfont file? with about 10 lines of python (plus a few to name the presets you're after) you can do such tricks with this littl

Re: [linux-audio-dev] LADSPA proposal ...

[Steve Harris] >On Tue, May 18, 2004 at 10:29:56 -0500, Jack O'Quin wrote: >> I've been reading up on Steve's N-triples suggestion... [...] >> (1) It is a W3C standard. >> (2) It is mathematically deep and well thought out. >> (3) It is specifically intended for adding property lists to the w

Re: [linux-audio-dev] [ANN] FIL-plugins-0.0.1

[Fons Adriaensen] >With the smoothing in place, the section bypass switches come more or >less for free, and it seemed a pity to have noise-free controls only >to have to spoiled by a noisy external bypass switch. So... OK, then that makes sense. btw, can you give some literature pointers regardi

Re: [linux-audio-dev] [ANN] FIL-plugins-0.0.1

[Fons Adriaensen] >The first release of FIL-plugins is now available at > > first impression: sounds real good, nice to have smoothened controls too. could do without the global and section bypass though. cpu is ~ 3.5 % @ 64/44.1 on this 1.7G athlon, quit

Re: [linux-audio-dev] RFC: Disposable Soft Synth Interface

[Steve Harris] >On Sat, May 01, 2004 at 03:33:14 +0200, Tim Goetze wrote: >> i'm inclined to think that free-form docs are sufficient. it would be >> nice to have a complete conf language but the effort implementing that >> is likely to be huge or require yet another

Re: [linux-audio-dev] Re: RFC: Disposable Soft Synth Interface

[Jens M Andreasen] >I should have included some kind of man page: > >> msg[0] = midi_status; >> msg[1] = midi_data_1; >> msg[2] = midi_data_2; >> msg[3] = sample_offset; // counting from most recent rendering. > >> Personally I can ignore sample_offset, but to others it is a >> prerequisite. >

Re: [linux-audio-dev] RFC: Disposable Soft Synth Interface

[Jack O'Quin] >Tim Goetze <[EMAIL PROTECTED]> writes: > >> sounds fair enough, but still requires you to install X and the >> toolkit of the plugin's choice. > >I must have missed something. I thought you could send the >configuration parameters fro

Re: [linux-audio-dev] RFC: Disposable Soft Synth Interface

[Steve Harris] >Everything that goes over configure() is/can be prietary to the plugin, it >would be up to the plugin author wether they documented or not. > >The only requirement is that data is passed that way do that the host can >restore the state reliably. so gui-less application is eventual

Re: [linux-audio-dev] Re: RFC: Disposable Soft Synth Interface

[Jens M Andreasen] >On tor, 2004-04-29 at 16:11, Chris Cannam wrote: >> On Thursday 29 Apr 2004 2:19 pm, Jens M Andreasen wrote: >> > I think I will not be really, totally happy before I see something >> > like: >> > >> > void (*midi_msg)(LADSPA_Handle instance, >> >unsigned b

Re: [linux-audio-dev] RFC: Disposable Soft Synth Interface

[Steve Harris] >On Thu, Apr 29, 2004 at 12:32:14 +0200, Tim Goetze wrote: >> i'm not too intimate with liblo/OSC, so sorry for asking an RTFM >> question: does OSC provide some sort of alternative, textual >> representation of configuration options? > >I dont thin

Re: [linux-audio-dev] RFC: Disposable Soft Synth Interface

[Chris Cannam] >The assumption is that the host just passes on whatever the GUI >selects, and it's up to the GUI (which of course is provided by the >plugin author, or at least built to match the plugin) to understand >the key value pairs. Of course that means if you have no GUI you >can't use con

Re: [linux-audio-dev] RFC: Disposable Soft Synth Interface

[Chris Cannam] >The header file is here: > > http://dssi.sourceforge.net/dssi.h.txt the header looks OK to me, reusing ALSA and LADSPA is a nice idea indeed. however i'm a bit uneasy about the configure() method of the plugin and its implications. a couple of points: * how does the host know val

Re: [linux-audio-dev] how about a LADSPA BOF session at LAConf#2 ?

[Alfons Adriaensen] >On Wed, Apr 14, 2004 at 02:17:07PM +0200, Tim Goetze wrote: > >> (latest revision is +GROUP, -RANDOMIZED.) > >Tim, am I correct in assuming that when you mean e.g. [A B C] D E [F G] H >where [] indicates the grouping, then A, C, F, G will have the GROU

Re: [linux-audio-dev] how about a LADSPA BOF session at LAConf#2 ?

[Matthias Nagorni] >On Sun, 11 Apr 2004, Joern Nettingsmeier wrote: > >> frank, matthias, could you perhaps just decide on a date, and announce it on >> the zkm website as a non-public (i.e. not for casual passers-by, but of course >> free for all interested developers)? > >OK, we will schedule it

Re: [linux-audio-dev] Pitchshift/Timestretch project..

[Florian Schmidt] >On Tue, 6 Apr 2004 10:36:51 +0100 >Steve Harris <[EMAIL PROTECTED]> wrote: > >> Theres info about this on Stephan's website: >> http://www.dspdimension.com/start.html >> >> Its not that simple - but thats the basic idea. > >Thanks! I'll have a look.. please let me throw in that

Re: [linux-audio-dev] [simon@arrowtheory.com: [Portaudio] ANN: dsptools-0.4.0]

[Andrew (Andy) W. Schmeder] >On Sat, 2004-03-27 at 05:24, Tim Goetze wrote: >> all this is possible without acquiring any locks. > >For what its worth, I have written a python module for jack which works >almost exactly in this manner. (GPL; online at >http://www.a2hd.com/s

Re: [linux-audio-dev] [simon@arrowtheory.com: [Portaudio] ANN: dsptools-0.4.0]

[Simon Burton] >I stopped coding when I could play/process arrays of sound from >within the portaudio callback. Yes, PA calls back into python, >acquires the Big Bad Lock, and all that. ah, thanks for drawing the curtains. may i suggest a solution? (background: i'm working on a similar project, wh

Re: [linux-audio-dev] [simon@arrowtheory.com: [Portaudio] ANN: dsptools-0.4.0]

[Eric Dantan Rzewnicki] >Here be Python wrappers for portaudio, ladspa and libsndfile. >There are three modules: ladspa, sndfile, and portaudio. >They are independant of each other, ie. they should compile/run individualy. interesting. i'd like to ask you how you work around Python's inherently re

[linux-audio-dev] [ann] pvoc-0.1.7

the pvoc package is at 0.1.7, with piped I/O in the stretch utility rewritten for buffered operation, for a factor 2-3+ performance gain. (sic, stupid me called write() and read() for every sample. ah, don't you just love proof-of-concept code :) if you use the the stretch utility with piped I/O y

Re: [linux-audio-dev] Generic audio file handling

[Steve Harris] >Theres nothing critically wrong with the current "everyone links to a >dozen file handling libraries" situation, its just a bit anoying as a user >that such-and-such an app can't load oggs, and such-and-such can't load >FLACs, and as a deveoper because you have to write seperate cod

Re: [linux-audio-dev] [ann] pvoc-0.1.0, caps-0.1.11

[Jesse Chappell] >Erik de Castro Lopo wrote on Thu, 25-Mar-2004: > > > > >I just realized that you may not want to clamp if your output > > > >is a 32 bit float or double, as it is fully capable of handling > > > >the value as produced. For instance, if (well, when) we suck this > > > >algorithm

Re: [linux-audio-dev] [ann] pvoc-0.1.0, caps-0.1.11

[Jesse Chappell] >Tim Goetze wrote on Wed, 24-Mar-2004: > > > [Jesse Chappell] > > > >The stretch program was not properly clamping the output from > > >-1.0 -> 1.0 yielding to terrible cracks upon writing as 16bit > > >wave files when the output is c

Re: [linux-audio-dev] [ann] pvoc-0.1.0, caps-0.1.11

[Jesse Chappell] >Tim Goetze wrote on Wed, 24-Mar-2004: > > > the algorithm 'accumulates' energy from the pvoc frame bins into a > > 'static' pvoc frame, thus the basic effect sounds a bit like an echo > > or reverberation. (in fact i think it could be

Re: [linux-audio-dev] [ann] pvoc-0.1.0, caps-0.1.11

[Jesse Chappell] >Tim Goetze wrote on Tue, 23-Mar-2004: > > > pleased to announce the new DSP package 'pvoc'. at its core, it > > features the CARL phase vocoder. [...] >The stretch program was not properly clamping the output from >-1.0 -> 1.0 yielding to

Re: [linux-audio-dev] [ann] pvoc-0.1.0, caps-0.1.11

[Jens M Andreasen] >On ons, 2004-03-24 at 11:41, Tim Goetze wrote: >... >... >> Accumulate can also move the stored frequency >> coefficients around, resulting in constant glissando of the 'sound >> tail'. > >Mmmm ... A bit like having a reverb, feed

Re: [linux-audio-dev] [ann] pvoc-0.1.0, caps-0.1.11

[Jens M Andreasen] >On tis, 2004-03-23 at 23:31, Tim Goetze wrote: >> pleased to announce the new ... [vocoder] >> >> there are three LADSPA units in this package (Exaggerate, Transpose, >> Accumulate) plus a commandline utility for time compression and >>

[linux-audio-dev] [ann] pvoc-0.1.0, caps-0.1.11

pleased to announce the new DSP package 'pvoc'. at its core, it features the CARL phase vocoder. there are three LADSPA units in this package (Exaggerate, Transpose, Accumulate) plus a commandline utility for time compression and expansion of n-channel audio data streams. compilation of this pack

[linux-audio-dev] ++cleanup -0.8 (ladspa.h.diff)

as the subject indicates, i have reworked my ladspa.h patch proposal, cleaning up comments and dropping the version tag to v1.2. the accompanying example host and plugin code has also been revised, in particular 'host.c' for better readability. no attachment to clutter your inbox this time. you c

Re: [linux-audio-dev] +well-known-ports -Latency (ladspa.h.diff)

[Paul Davis] >this is not an accurate description of the purpose of the port. > > Plugin authors should assume that hosts that care about plugin > latency will read the latency value as often as they deem > necessary. However, host authors should assume that the port > value is only

[linux-audio-dev] +well-known-ports -Latency (ladspa.h.diff)

04 Steve Harris, Matthias Nagorni, Fons Adriaensen, + Tom Szilagyi, Taybin Rutkin, Paul Davis, Tim Goetze. + This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either

  1   2   3   4   5   >