Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

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…

17 years, 7 months

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 >

17 years, 7 months

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>

17 years, 7 months

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…

17 years, 7 months

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))

17 years, 7 months

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

17 years, 7 months

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?

17 years, 7 months

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

by Marek

On Jan 27, 2008 10:44 PM, Daniel Schmitt <myloginislongerthanyours(a)gmail.com> wrote: > > On Jan 27, 2008 9:59 PM, Marek <mlf.conv(a)gmail.com> wrote: > > > > > > > > > > > But let's have a look at these statements from the GPL: > > > > "...if you distribute copies of such a program, whether gratis or for a fee..." > > "... You may charge a fee for the physical act of transferring a copy..." > > > > 1. Basically "You may charge a fee for the physical act of transferring a copy..." translates to "You may *only* charge a fee for the physical act of transferring a copy..." as the GPL doesn't state that you may charge for the computer program or any other services related to it other than distribution and providing warranty. Otherwise such statement made by the GPL would be *invalid*. > > > This interpretation is at odds with the FSF's own interpretation. Check http://www.fsf.org/licensing/licenses/gpl-faq.html#DoesTheGPLAllowMoney to get it directly from the gnu's mouth, so to speak. Show me one example in GPLv2 which would tell me that i can charge for *a copy*, not for *distributing a copy*(!). The FSF clearly uses wrong wording (see my FedEx example) because they are always talking about encouraging *distribution* http://www.gnu.org/philosophy/selling.html: Quote: "--> Selling <-- Free Software Many people believe that the spirit of the GNU project is that you should not charge *money for distributing copies* of software, or that you should charge as little as possible — just enough to cover the cost. Actually we encourage people who *redistribute free software* to charge as much as they wish or can. If this seems surprising to you, please read on." Please note : Selling software != Distributing for charge and there are *many* ways to sell software (even while not distributing it at all). > > > > > As for the original topic: under the GPLv2, anyone can build hardware around a piece of GPLed software as long as they offer to give the full source, including any modifications they made, to anyone asking for it, at cost. Nope. If the software represents a substantial part of the hw based product, you are not charging for distribution of the software, you are charging for the entire *product * which would be useless without the software. If there are software *alternatives* that are easily installable on your hardware and you chose to prefer one of them, then you're only distributing the sw along with the hw you are selling. > > > > > The restrictions desired by the LS crew therefore do require additional terms beyond the GPL, and the resulting license is not compatible with the GPL. These are undisputed facts. Undisputed facts? :) Search for "we believe" in -> http://www.fsf.org/licensing/licenses/gpl-faq.html > > > The one mildly interesting question is whether this state of affairs makes LS non-free; reinterpreting a license it doesn't even use is not going to clarify that. It's free for users to study, modify the code and run the code for any purpose, to distribute it to others, whether modified or not. And see the coincidence, these rules apply to LinuxSampler whether with or without exception. GPL is not public domain, it's not charity for midsize or big companies. In general, the GPL enforces third parties to *give back*. If you can't give back code, you can give back money(the only exception being, you're encouraged to distribute, for that sake you can earn a few bucks if you're able to). Marek

17 years, 7 months

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

by Daniel Schmitt

On Jan 27, 2008 9:59 PM, Marek <mlf.conv(a)gmail.com> wrote: > > But let's have a look at these statements from the GPL: > "...if you distribute copies of such a program, whether gratis or for a > fee..." > "... You may charge a fee for the physical act of transferring a copy..." > > 1. Basically "You may charge a fee for the physical act of transferring a > copy..." translates to "You may *only* charge a fee for the physical act of > transferring a copy..." as the GPL doesn't state that you may charge for > the computer program or any other services related to it other than > distribution and providing warranty. Otherwise such statement made by the > GPL would be *invalid*. > This interpretation is at odds with the FSF's own interpretation. Check http://www.fsf.org/licensing/licenses/gpl-faq.html#DoesTheGPLAllowMoney to get it directly from the gnu's mouth, so to speak. As for the original topic: under the GPLv2, anyone can build hardware around a piece of GPLed software as long as they offer to give the full source, including any modifications they made, to anyone asking for it, at cost. Under the GPLv3 the same thing holds, with the additional stipulation that if the hardware is field-upgradeable, anyone must be able to do it (e.g. if the device checks for a cryptographic signature before executing the code, the seller must provide the required key along with the source). The restrictions desired by the LS crew therefore do require additional terms beyond the GPL, and the resulting license is not compatible with the GPL. These are undisputed facts. The one mildly interesting question is whether this state of affairs makes LS non-free; reinterpreting a license it doesn't even use is not going to clarify that. Daniel.

17 years, 7 months

JACK Synthesizer Manager Proposal

by Thorsten Wilms

Hi! Audun Halland and I have been thinking about a set of related problems. The first result is the following proposal, meant to gather feedback from the community. I'm posting about this to both LAD and LAU, but separately. Hopefully we can keep it technical here and have the user POV on LAU :) Please feel encouraged to come up with additional use cases and implementation ideas. You can read the following with a little bit of markup on http://thorwil.wordpress.com/2008/01/26/jack-synthesizer-manager-proposal/ or the same text right here: JSM, the JACK Synthesizer Manager We propose a programm that acts as a proxy between sequencing software and both software and hardware sythesizers. Among the goals are unified patch selection and making projects more portable. If we get the impression that the JSM is something that both developers and users will find handy and use, then development might start real soon. In this text, we avoid going into technical details to foster free thought and discussion. Use Cases 1. Patch selection Goal: Choose patches from all available hardware and software synthesizers. Giorgio uses a single means to select a patch among all patches of all of his software and hardware synthesizers. He uses meta-data to find the right patch. The right connections are made automatically. 2. Computer as syntheszier Goal: Use the computer as a compound synthesizer in a live performance. Hiromi has her keyboard connected to her laptop live on stage. She uses several soft-synths via keyboard-split and layering. A few selected parameters are bound to the wheels of the keyboard. After each song, she switches from one setup to the next with least effort. 3. Collaboration Goal: Exchange projects without having to change settings back and forth. Alice and Bob take turns on working on a project. They use different hardware but don't have to manually change connections and choose patches on each turn because of an abstraction layer. MIDI Interface Ports The problem with MIDI interface ports is that the hardware on the other side and its setup might change. Or be entirely different if people exchange projects. An abstraction layer can make this more comfortable to handle. The JSM takes care of the mapping between software ports and MIDI interface ports. It can work on a per MIDI channel level. Patches and Instrument Definitions Patches and controllers are chosen by name; the user doesn't have to deal with cryptic numbers. For kit-programms, name mappings are given (e.g. bass drum on C1). Patch selection happens by a single means, offering all available patches (JACK apps, plugins, hardware). Making the required MIDI and audio connections is automated as far as possible. Categorization Categories help to find the right patch among many. When exchanging projects, they help to replace unavailable patches with similar ones. Virtual/Compound Synthesizers >From the outside, the computer can be dealt with like a single compound synthesizer. Different synthesizers can be triggered from ranges on a single keyboard (key splits). Synthesizers can be layered. The whole setup can be switched with programm changes. JACK to ALSA Bridge JSM could be the de facto JACK MIDI to ALSA MIDI bridge. No Jack "SYSTEM" midi ports, the jack world only sees the devices offered by JSM. -- Audun Halland and Thorsten Wilms

17 years, 7 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