Linux-audio-dev January 2008

linux-audio-dev@lists.linuxaudio.org

74 participants
60 discussions

Re: [LAD] Prototyping algorithms and ideas

by Kjetil S. Matheussen

Le 29 janv. 08 à 23:36, Yann Orlarey a écrit : > Hi Fons, > > Here is a quick solution using Faust : > > import("filter.lib"); > > line(i) = vgroup("line %i", *(g) : fdelay2(1024, d)) > with { g = vslider("gain (dB)", -60, -60, 4, 0.1) : > db2linear : > smooth(0.995); > d = nentry("delay (samp)", 0, 0, 1000, 0.1) : > smooth(0.995); }; > > process = hgroup("", par(i, 10, line(i)) ); > > The first line imports a library of filters (written in Faust by > Julius > Smith) that includes several fractional delays based on Lagrange > interpolation. > > Then we define a 'line' that combines in sequence (':' operator) a > gain > and a fractional delay encapsulated in a vertical layout. Here we use > fdelay2 a fractional delay with a second order Lagrange interpolation. > It can be replaced by fdelay3 or fdelay4 if better interpolations are > needed. > > The gain value g is defined by a vertical slider (in dB) which is > converted in a linear value and then filtered to avoid clicks during > rapid movements. The delay value d is defined by a numerical entry box > also filtered to avoid clicks. The parameter m is the maximum size of > the delay and should be a power of 2. > Wow, that is cool. I wonder about making some faust inspired macros for snd-rt to make user interfaces more integrated. I think the snd-rt program below should do the same as the faust version now, although I'm not too sure about the correctnes of the delay interpolation and filtering. They both sounds the same though, I think: (set! (rt-safety) 0) (definstrument (line n dialog) (let ((del (make-delay 1 :type mus-interp-lagrange :max-size 20000)) (length (make-glide-var 0 100)) (gain (make-glide-var 0 0.005))) (<slider> dialog (<-> "gain " n) 0 0 2 (lambda (val) (write-glide-var gain val)) 100) (<slider> dialog (<-> "delay " n) 1 1 20000 (lambda (val) (write-glide-var length val)) 1) (<rt-play> (lambda () (set! (mus-length del) (read-glide-var length)) (out 0 (* (read-glide-var gain) (delay del (in 0)))))))) (letrec* ((exit (lambda () (rte-silence!) (-> dialog hide))) (dialog (<dialog> "Delay line stuff" exit " exit " exit "Stop" rte-pause "Start" rte-continue))) (for-each (lambda (n) (line n dialog)) (map number->string (iota 10))) (-> dialog show)) The faust program uses 2.1% percent cpu on my xp2800, while the snd-rt program now uses 3.8% percent cpu. The reason for the speed increase for the snd-rt program is because the scheme list traversals and vector accesses is removed from the dsp code. Instead the scheduler just runs 10 realtime instances. To run the program, just paste the code above into snd-ls' terminal.

18 years

[LAD] JACK 0.109.2 released

by Paul Davis

This is a maintainance release of JACK. Three important issues are fixed: * the old ALSA PCM port names are available, so that applications that either hardcode or have existing patching information containing these names will function. * the use of popen(3) to invoke jackd to determine the server directory has been fixed so that it works on systems that have closed a security risk with popen(). This was preventing correct startup on OS X, in particular. * USX2Y driver updates to enable JACK MIDI devices to show up in raw-usb mode (previously, raw-usb mode didn't initialize or call MIDI drivers properly). Download from either jackaudio.org or sourceforge: http://jackaudio.org/downloads/jack-audio-connection-kit-0.109.2.tar.gz http://prdownloads.sourceforge.net/jackit/jack-audio-connection-kit-0.109.2…

18 years

Re: [LAD] [OT] LinuxSampler and GPL - some clarifications

by Marek

On Jan 30, 2008 5:15 PM, Gordon JC Pearce <gordonjcp(a)gjcp.net> wrote: > On Wednesday 30 January 2008 16:10:31 you wrote: > > > Would be so kind and write thorough analysis which would show the > > *all* of my claims as untrue or unjustified? Please GO AHEAD. > > Just shut up and go away, please. Maybe you can come back and join the fun > when you've actually read and understood the GPL. > Give me the facts that i don't understand the GPL. Otherwise you shut up and let the others discuss it, the thread will die if nobody is interested in replying. It is marked as [OT] so you're free to filter it out if you don't like it. Thank you.

18 years

Re: [LAD] LS licensing (was: LV2 & quot; isn't well thought out ?& quot; LV2 in the Reaper sequencer)

by t_w_＠freenet.de

Gesendet: Mi 30 Jan 2008 03:25:17 CET Von: "pete shorthose"<zenadsl6252(a)zen.co.uk> > i even said "virtually no one welcomes drobilla" > when you joined #lad on freenode. > it was TEH FUNNEZ! Ah, so that what was funny. But nothing from Dave or me was funny. So apparently you have humour, but we don't. Now you are explaining your oh so clever argument again an again. That's just sad. Just missed another good opportunity to stop this crap. Is it so hard to accept that Dave and you have different opinions on the term "open source", especially regarding its historical use? I don't get why you think he _has_ to answer you in a straight way. Are you the inquisation? > running roughshod over any dissenting voices safe in the ken that your > position in the community affords you special privilege. Good thing you are guarding us from this berserker while being a saint! > now, the reason i'm rather more uhm.. "energised" than usual is due to that > lovely > little chat on irc that we had in the interim. where you so generously > implied that, > whilst it's presumably ok for you to fill up the lists with views on the > validity of > software licenses, us low folk better shut the hell up and not bother you > with their > silly views else you'll up and leave the community. This is a very mean misrepresentation of what was said there. It wasn't just Dave and me who found your behaviour there very silly and overly agressive. > well you know, if you're that sensitive, don't discuss it in the first > place. Good thing you are not sensitive at all, but take it all with good humour. > i'm probably as arrogant and aggressive as you but at least i try to keep > it > under wraps eh? No, you don't, obviously. Let's just assume you are right and Dave was wrong. Now what? Did this whole endevour lead to anything good, any insight, change of mind? I would ask to stop with this again, but I bet you have to have the last word ;p -- Thorsten Wilms Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

18 years

[LAD] Fwd: LS licensing (was: LV2 " isn't well thought out ?" LV2 in the Reaper sequencer)

by alex stone

Hehe, succinctly put Christian. Just doing a quick count of all the lines that have been written about this, and the sometime belligerent enthusiasm attacking LS and questioning their integrity because they're perceived as not being 'pure' by interpretation, by some of you, and just since i've been here, there seems to be a lot of code, sorry i mean text, written. Makes me wonder just what the incentive is, to batter this to death over and over again, instead of being admired for the quality and skill of coding most of you have already proved you are capable of. To offer a counterweight to this, have all you craftsmen considered getting together in a concentrated team effort, free of politics, and indulge in an intense push to expand Jack and Jackdmp (for example) to incorporate kernel level audio, with modules, and do away with alsa altogether? Now that WOULD be something to talk about, and a wonderful incentive for developers to come together as one, with a common goal for the greater good. Jack is already 'king of the empire', in my humble opinion, and would expand it's grip on the planet even further with this final step towards ONE complete linux audio and midi solution. I live in hope that you chaps will take a deep breath, and use those obviously competent typing skills you're exercising at the moment, in writing more excellent code that i can use, and continue to admire and respect you for. Alex. On Jan 29, 2008 1:42 PM, Christian Schoenebeck <cuse(a)users.sourceforge.net> wrote: > Am Dienstag, 29. Januar 2008 06:25:31 schrieben Sie: > > On Sat, 2008-01-26 at 03:16 +0000, Christian Schoenebeck wrote: > > > So get it: there is NOT only one definition of the term "open source" > > > when standing alone. Like with many unspecific short terms, different > > > people have different opinions of those short terms. > > > > Yours just coincidentally is shared by virtually nobody and it just so > > happens that this arbitrary definiton matches exactly your software > > which you wish to call 'open source' for PR reasons. > > Right, just by the majority of e.g. all Windows and OS X users, hmm who > reflect the majority of all users anyway. And right, I forgot I'm > promoting a > product. Thanks Dave for enlighten us about the truth! Now I clearly see > there is only white and nothing else than white! Well, maybe black, but > the > black ones are evil by definition and don't count. > > Thanks my Pope! How could I ever have doubts in your holy inerrable words. > > CU > Christian > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev >

18 years

[LAD] Abstraction for JACK control API

by Nedko Arnaudov

After some discussion on IRC with Stéphane Letz, I created abstract description of the API that is needed to implement current jackdbus functionality (i.e. without the coming patchbay and transport control interfaces). I've decided to describe it in C++ just because it will be more clear to general public than plain C OO abstraction, or UML diagram. jackdbus code itself is in plain C. Hope is that such abstraction will help to have same D-Bus interface implemented (and much of related code - shared) for both jackd and jackdmp. // -*- Mode: C++ ; c-basic-offset: 2 -*- /////////////////////////////////////////////////////////////////////////////// // // DESCRIPTION: // Abstraction of the API needed to implement jackdbus // /////////////////////////////////////////////////////////////////////////////// #ifndef JACKSERVER_H__775F79BA_DDE0_4FEA_AC4B_7BE05638499C__INCLUDED #define JACKSERVER_H__775F79BA_DDE0_4FEA_AC4B_7BE05638499C__INCLUDED /** Parameter types, intentionally similar to jack_driver_param_type_t */ typedef enum { JackParamInt = 1, JackParamUInt, JackParamChar, JackParamString, JackParamBool, } jack_param_type_t; class ImmutableString; class ImmutableVariant; template<class T> class ImmutableSet; class JackConfigurationParameter { public: ImmutableString& GetName() const; ImmutableString& GetShortDescription() const; ImmutableString& GetLongDescription() const; jack_param_type_t GetType() const; ImmutableVariant& GetValue() const; void SetValue(ImmutableVariant& value); }; class JackConfigurationDriverParameter: public JackConfigurationParameter { public: bool IsSet() const; ImmutableVariant GetDefault() const; }; class JackConfigurableObject { public: virtual ImmutableSet<JackConfigurationParameter>& GetParameters() const = 0; // helpers JackConfigurationParameter& FindParameter(ImmutableString& parameter_name); }; class JackDriver: public JackConfigurableObject { }; class JackEngine: public JackConfigurableObject { }; class JackServerInterface: public JackEngine { public: ImmutableSet<JackDriver> GetAvailableDrivers(); void StartServer(JackDriver& driver); // next ones are called only on started server void StopServer(); double GetLoad() const; // In percent unsigned int GetSampleRate() const; // in Hz double GetLatency() const; // in milliseconds bool IsRealtime() const; // whether engine is running unsigned int GetXruns() const; void ResetXruns(); // reset value being returned by GetXruns() to 0 }; #endif // #ifndef JACKSERVER_H__775F79BA_DDE0_4FEA_AC4B_7BE05638499C__INCLUDED -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

18 years

Re: [LAD] LV2 " isn't well thought out ?" LV2 in the Reaper sequencer

by t_w_＠freenet.de

Dave Phillips wrote: > So responding with sarcasm, "We'll do it my way or not at all" > conditions, and a confrontive attitude qualifies as "the spirit of > collaboration" ? Geez, you guys are really winning me over. It's the good right of Dave and Lars to not care or even outright reject closed software. They could have said it more diplomatic terms ... but now you make a drama of it. It could even be that both never claimed to be open minded ;) Dave puts an incredibly amount of effort into several open projects. Why would he go out of his way to help adding capabilities to closed software that kinda competes with what he works on? Producers of closed software gotta love competition and doing it all by themselves. > No fear, no-one's going to ask you or DR for help in this matter. There are very few others who could help in this matter, so what do you think you gain with this confrontative behaviour? Now you could say going to that forum and correcting misconceptions regarding LV2 should be easy enough and worth it, but even that eats time of which there is so little in a day. Plus to me it sounds like that guy doesn't want to get it. -- Thorsten Wilms Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

18 years

Re: [LAD] Prototyping algorithms and ideas

by Kjetil S. Matheussen

Fons Adriaensen: > > On Fri, Jan 25, 2008 at 12:57:19PM -0500, Stephen Sinclair wrote: > >>>> Also, nice in the fact that you can do per-sample computations easily, >>> >>> How ? I seem to have missed something... >> >> Because you can wait in a 1-sample loop? >> >> Yes, it will use your whole CPU for a loop like that, but this thread >> is about prototyping. Obviously you'd rewrite in C for a real >> application. >> I never claimed chuck is perfect, but I've been liking it a lot >> lately. Sure, it can have performance issues depending on how you use >> it, but the nice thing is having the option to abuse it that way when >> necessary. > > This is one of the things I wanted to create a 'rapid prototype' > for recently. I needed a jack client implementing: > > - a delay line, > - allowing high-quality fractional-sample delays, > - at least 12 outputs, for each two controls: delay, gain, > - smooth 'crossfading' between two control sets, both delay > and gain, controlled by a GUI or by OSC. > > It should not take more than 20% CPU on a 2G P4 > (other things have to run at the same time). > If you know how to get this faster than by actually > writing it in C++, please let me know ! > Quick version for snd-rt below. It use about 10% on my xp2800, but its easy to optimize so that it use a lot less by making the dsp function call "out" and "in" only one time. (that optimization requires two more lines of code, but the version below is the straight forward one) I'm not quite sure what you mean by "smooth 'crossfading'" though, but at least the gain values are interpolated to avoid clicks when changing values. I'm not sure if that was what you ment. Guess its time to learn scheme now Fons? ;-) Oh well, hopefully someone will find this interesting. To run it, just paste the text below into the terminal snd-ls was started from. (define-rt-vector-struct das-delay :delay (make-delay 20000) :gain (make-glide-var 0 0.001)) (definstrument (mdelay num-delays) (letrec* ((das-delays (map make-das-delay (iota num-delays))) (instrument (<rt-play> (lambda () (for-each (lambda (das-delay) (out (* (read-glide-var (=> das-delay :gain)) (delay (=> das-delay :delay) (in))))) das-delays)))) (exit (lambda () (-> instrument stop) (-> d hide))) (d (<dialog> "multi delay" exit "Close" exit "Stop" (<- instrument stop) "Start" (<- instrument play)))) (for-each (lambda (n das-delay) (set! (mus-length (=> das-delay :delay)) 1) (<slider> d (<-> "gain " n) 0 0 2 (lambda (val) (write-glide-var (=> das-delay :gain) val)) 100) (<slider> d (<-> "delay " n) 1 1 20000 (lambda (val) (set! (mus-length (=> das-delay :delay)) val)) 1)) (map number->string (iota num-delays)) das-delays) (-> d show))) (define mdel (mdelay))

18 years

[LAD] Summercode 2008: LASH, pt. 2

by Juuso Alasuutari

Here's a list of all LASH suggestions expressed so far, as well as some new ones. It's quite a bunch, and it goes without saying that this is NOT A PLAN; no sane person would actually try to cram all of these into an application. If my application gets chosen for Summercode I'll only be concentrating on a few key things (to be announced later, maybe after another brainstorm). So, please take this as a memo, and please do comment. The internet doesn't contain enough ASCII yet. Suggested changes to internal structure: * Interact with JACK using the JACK D-Bus interface. Lashd no longer required to be a libjack client. - Jackdbus needs a port settings interface. * Interact with LASH clients using D-Bus (change liblash's transport to use D-Bus). - What if the client has its own D-Bus event loop and wants to manually handle the LASH protocol? We need an option to also allow this. * Replace liblash's server interface with a LASH D-Bus interface. LASH control applications no longer required to be liblash clients. - Requires API change. * Certificates and encryption for communication protocol. - What the "communication protocol" refers to is another question... * OSC (?) * Server rewrite in C++. * Client lib rewrite in GObject. API change suggestions: * Break it? How? When? - Probably unavoidable eventually. * Remove the server interface from liblash. Controlling LASH will happen through a D-Bus interface. - Dave Robillard has expressed that the current interface separation makes it difficult to write a LASH control application which is at the same time a LASH client (Patchage). * Mandate that LASH clients shall not modify any external port connections. - Actually enforce this using JACK ACL? (A partial solution, doesn't help with ALSA and others.) * Make the save directory "static" to clients unless a change notification is sent. * More generic patch system API. * Use callbacks instead of current event framework. * Add "test disk operation" function; the server can ask the client to test if it can actually read from and write to the specified directory. Feature addition suggestions: * Lashd should capture clients' stdout and stderr and keep log(s) in the project dir. - One common log file or per-client ones? * Preserve/restore JACK settings other than port connections. - Make this optional; the user must be able to tell LASH to not touch any JACK settings. - Should this be the responsibility of a JACK controller app? * Export/import session; create or unpack a tarball of the session directory. * Light save functionality; clients can reference files outside the session directory. * Managing of non-LASH apps. * Preserve clients' X11 properties, such as window position, screen, workspace, etc. * Ability to merge sessions. * Support for multi-host sessions. - Should the LASH<->client protocol support this directly (socket-based connections), or - should LASH daemons on different machines be able to connect with one another (master session & slave sessions)? * Save the client data in $client_dir under a sub-dir to prevent the client from overwriting config files. * Support for dictating client loading order, and which other clients need to be loaded before a client can load. - Alternative solution/scheme: client priorities. * Track naming * Guaranteed save directory availability * Graded saves. (Different kinds of saves? How many different kinds?) * Networked audio (audio/MIDI ports over network). * User interface standard recommendation (documentation). * Automatic client installation/in-built package manager. Juuso

18 years

Re: [LAD] Prototyping algorithms and ideas

by Kjetil S. Matheussen

Frank Barknecht: > > The second problem (besides its lack of interactivity) I have about faust > > is that is purely functional. I have programmed lots of code in purely > > functional style, and I like it very much, so thats not the issue. But, I > > feel that being forced to work in one paradigm gives me less > > possibilities. > > I think, Lua (with Vessel, see my other post) may be a good compromise > of both worlds. Vessel/Lua seems very nice, but it doesn't seem to offer sample by sample processing. And even if it did, it would be terrible slow. Faust or snd-rt are better options for doing those kind of tasks. > (It may have not enough parenthesis for your taste. ;) > Yeah. :-) It amazes me, though, that people use s-expression as an argument against languages. Even people with phd in computer science seems to think that s-expression is a valid argument against using a language. If they have spent 30 years of programming, how hard can it be then to use a couple of weeks getting used to s-expressions? Doesn't make sense to me. > Actually as I recently had a quick look at Rick Taube's SAL language > syntax for working with Common Music, I was amazed at how similar SAL > looks and feels to straight Lua code. I even wondered, if inventing a > new domain specifc language like SAL was necessary. I didn't know SAL was a domain specific language? I thought SAL was just a synactical frontend for scheme and common lisp?

18 years

2026

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 January 2008