Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 months

Summercode 2008: LASH as a D-Bus service

by Juuso Alasuutari

Now that the list traffic seems to have calmed down a bit I'd like to draw attention to another, less controversial (hah!) subject... LASH. Please bear with me the mandatory introduction: The Finnish Centre for Open Source Solutions [0] along with a number of Finnish companies (yes, Nokia's in) is hosting an annual event called Summercode [1] this year for the third time. As you probably guessed it's a lot like Google's Summer of Code, but I've understood that it's meant solely for university students. The students file applications detailing the project they wish to work on and the goals they aim to reach. The winning applicants are granted three months of paid (about 1800 euros/month) development time beginning from June. For me, this represents an opportunity to get the mostest perfectest summer job I can possibly imagine. I'm planning on submitting an application for re-implementing LASH as a D-Bus service (it's Hip, Cool and Popular), and I'm hoping I'll get lots and lots of feedback from the lot of you for carving out my application. Below are the goals in descending order which I believe matter the most. (I'm in debt to Dave Robillard for sorting out the priorities to me.) - Turn LASH into a D-Bus service daemon. - Unify the client and server APIs - New features, API changes, etc. The last one is bound to be flammable, and I'm hoping that the feedback I get will help me concentrate my efforts on what the developers and users think is most important. Can't do everything in 3 months' time anyway. The deadline for applications is February 20th, and I want mine to capture the essence of creative cross-functional combinations of community synergies and foresight for stimulating innovation. Thanks, Juuso [0] http://www.coss.fi/web/coss/about [1] http://www.coss.fi/web/coss/developers/summercode/faq

17 years, 11 months

Re: [LAD] Prototyping algorithms and ideas

by Kjetil S. Matheussen

Fons Adriaensen: > I've been searching for real-time audio processing tool that would > permit rapid prototyping, for at least two years now, and I haven't > found anything that up to the requirements. > That is interesting. Which requirements do you miss from snd-rt? (I have a list myself, but it may not contain the same as the one you have...)

17 years, 11 months

[ANN] FAUST 0.9.9.3 released

by Orlarey Yann

Grame - Centre National de Creation Musicale - is pleased to announce the release of Faust 0.9.9.3. Faust AUdio STreams is a powerful and expressive functional programming language for realtime audio signal processing. The Faust compiler translates DSP specifications into efficient C++ code. A variety of platforms and plugin formats are supported. A single Faust specification can be used to easily generate JACK and ALSA applications, as well as LADSPA, MAX/MSP, PD, Q, SC and VST plugins. In addition to C++ code, the Faust compiler can also generate SVG block-diagram representations as well as XML descriptions. To easily test the compiler before installing it, please refer to http://faust.grame.fr. The Faust distribution can be downloaded at http://sourceforge.net/projects/faudiostream ------------ What's new : ------------ - New architecture files : . vst2p4.cpp (VST-2.4 architecture file), . vsti-mono.cpp (mono VSTi synth architecture file), . matlabplot.cpp (architecture file to plot data in Matlab or Octave format). - New scripts for a very easy generation of executable applications : . faust2alsa (call the faust compiler and g++ to produce an Alsa application), . faust2jack (call the faust compiler and g++ to produce a Jack application), . faust2plot (call the faust compiler and g++ to produce an plot application), . faust2svg (call the faust compiler to produce SVG block-diagrams), . faust2firefox,(faust2svg + display with firefox) . faust2octave (faust2plot + display with octave) - New libraries : . filter.lib (Faust filters library) . effect.lib (Faust effects library) - faust2pd updated to Q 7.8, - Improved metadata management : tags are no more limited to a predifined set, metadata are now reported as comments in the generated C++ code - Support for new --simple-names option when drawing block-diagrams . ------------ Bugs fixed : ------------ - out-of-order generation of complex mutual recursions corrected - Lexer modified to support multiplateform end of line - Erroneous code sharing corrected --------------- Acknowledgments --------------- We are grateful to all the contributors of this new release, with special mentions to Albert Graef and Julius O. Smith. Keep sending us remarks, suggestions, bug reports and contributions.

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