Re: [LAD] A question for power HW experts
Fons Adriaensen wrote: Hello all, I'm looking for a high performance (e.g. quad core) machine to be used for audio processing (and running Linux of course). Rack mount is preferred but not essential. What would you recommend to look at ? if noise is not a problem, no problem. if it is, check the silent boxes from thomas-krenn.com (not silent at all, but only obnoxious, not earth-shattering). they are stand-alone towers, but rack-mount kits are available. if heat is a problem (and i think it always is), pay special attention to which cpu core you are getting - generally, the smaller the process, the better, but they don't always tell you. don't use the fastest one you can get (bad price/performace and also probably on the edge of its thermal design power). best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] How well do thinkpad notebooks work for audio?
hollun...@gmx.at wrote: It feels like my several year old PC will crap out soon for one reason or another, so I need a replacement, better sooner than later. This time it should be a laptop and I heard that formerly IBM and now Lenovo thinkpads are of good build quality, even if they only come with intel CPUs and cost an arm and a leg. So, do you have any experience with those for audio work? I'd be most interested in the T and R series and more recent models. Also helpful would be some data that's impossible to find on websites: - What chipsets are built in? - do the usb buses and the like share interrupts with something nasty like graphics? the x61s, while otherwise a very nice notebook, shares an interrupt between the 1394 and sata controller, which is kind of nasty when you want to do hd recording over a ffado device. i ended up adding a cardbus adaptor to obtain decent latencies. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Fwd: Fw: Re: At the hands of Professor Keller and Raymond
keller wrote: On Aug 2, 2009, at 3:16 PM, Patrick Shirkey wrote: As it's not particularly difficult to include the build scripts in the public repo it does appear that Bob is playing a game of cat and mouse in this case. That seems rather callous to me, Patrick. I am trying my best, in the face of people constantly yelling at me. You seem to take the claims that others make directly, without asking me first for clarification. A little calmness and courtesy would contribute immensely to the situation. There are no other scripts. The only thing missing is the nbproject directory, which I am trying to force in, as I said. can we please bury this urban myth that anybody who releases software under the gpl is legally bound to include makefiles and such? surely everybody has read this statement?: THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. (the yelling is not mine, but i think i would have added it if the original were lowercase) listening to some gpl zealots here, every project with broken makefiles is in violation of the gpl. that is most certainly not the case. if i decide to toss out a bunch of files under the gpl, it's not my responsibility to make them usable to you. it's a best effort thing - how would you react if someone got on your nerves because your pet project doesn't build on their sparc32/solaris because of some autotools problem? you would tell them, go fixit yourself. and rightfully so. so please, if you miss an ant file for a gift horse, write yourself one! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Fwd: Fw: Re: At the hands of Professor Keller and Raymond
Christian Ohm wrote: On Sunday, 2 August 2009 at 21:36, Jörn Nettingsmeier wrote: can we please bury this urban myth that anybody who releases software under the gpl is legally bound to include makefiles and such? The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, PLUS THE SCRIPTS USED TO CONTROL COMPILATION AND INSTALLATION OF THE EXECUTABLE. sigh. this is the license for you, the person who is redistributing the software. you must not remove any of those build and install scripts that you received when redistributing the software. it is not binding to the original author for his/her original work. what bob can't do is include third-party software licensed under the gpl *without* including its build and install scripts. how he compiles his own code is technically nobody's business. i could write gpl'd original code and sell you a proprietary makefile for $100,000.00 that you can't legally redistribute. if i feel like it. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Fwd: Fw: Re: At the hands of Professor Keller and Raymond
keller wrote: On Aug 2, 2009, at 12:50 PM, Raymond Martin wrote: I am referring to the Launch4J scripts to build an executable and others. For example, you have an .exe for windows, isn't Launch4J what was used? If so, there is a script for it, as indicated in the build.xml. As stated before, launch4j is a commercial product that I was using on a trial version. There is no way that I can provide that. I was considering buying it if worked well, but even then, I cannot provide it. All it does is wrap the .jar file and other dirs to make it convenient for the users to install and launch. So I guess you're saying it's not allowed? as stated in another mail, this is hogwash. you are perfectly entitled to chose whatever build tool you want, without having to redistribute it. just be careful that all the third-party software you include has the original build files included. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Fwd: Fw: Re: At the hands of Professor Keller and Raymond
keller wrote: On Aug 2, 2009, at 1:53 PM, Jörn Nettingsmeier wrote: keller wrote: On Aug 2, 2009, at 12:50 PM, Raymond Martin wrote: I am referring to the Launch4J scripts to build an executable and others. For example, you have an .exe for windows, isn't Launch4J what was used? If so, there is a script for it, as indicated in the build.xml. As stated before, launch4j is a commercial product that I was using on a trial version. There is no way that I can provide that. I was considering buying it if worked well, but even then, I cannot provide it. All it does is wrap the .jar file and other dirs to make it convenient for the users to install and launch. So I guess you're saying it's not allowed? as stated in another mail, this is hogwash. you are perfectly entitled to chose whatever build tool you want, without having to redistribute it. just be careful that all the third-party software you include has the original build files included. As I am hearing now then, I can use install4j as long as I provide the install4j script (but not install4j itself) in the source repository. i'm pretty sure you can use anything you want (or nothing at all). reasoning: 1. you are distributing third-party gpl code. make sure that it's installable on its own, don't remove its build and install scripts. 2. you are distributing your own software, as-is, with a license of your choice. nobody can force you to add installation or build scripts. what if you aren't using any and compiling and linking by hand? i'm not a lawyer (and also not interested in arguing the case). further discussions and inquiries are probably best directed at the FSF. my point was that it's totally misguided to accuse somebody who is opening their original software under the gpl of non-compliance on the grounds of not also providing build and install scripts for this original software. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] trolls and filtering...
hi everybody! just a passing remark: it is very easy to filter out a troll. it is however close to impossible to filter responses to trolling by people whose mail i appreciate in general. best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] At the hands of Professor Keller and Raymond
hi bob! welcome to the linux audio developers' community, thanks for joining this list. i'm sorry that you are joining for rather unfortunate reasons, but licensing issues are always controversial and have a way of attracting hot-heads... so please don't be offended. i'll try to refrain from taking sides, as you and raymond seem to have some history togesther... the way i see it (and i may be mistaken, all my facts come from this and previous threads), your code is including other code which is licensed under the gpl. you can only legally do this if your code is also put under the gpl. which means that the moment you distribute your application, its source code must be made available, as it is now a derivative work of the other code you included (no matter how small), and its license demands that. no way around this. (strictly speaking, not even a busy travelling schedule, because you are not under obligation to some random strangers, but to the license of part of your software). which means that raymond has a point. and he is also entitled to forking your project any way he sees fit. so much for the legal part. as to communication skills, raymond, i think you should go get a nice cup of coffee, tone down a bit, see what happens. this bears all the hallmarks of a excuse my french pissing contest, which might be explained by the history of your mutual correspondence, but from the outside, it looks like no big deal at all, and should sort itself out nicely. bob, i'm not a lawyer, but the way i see it, your options are: * comply with the gpl, which means your code is gpl also, and the source has to be available the moment a binary version comes out (even previews, betas, whatever). and then you have the risk that somebody takes control away from you. (not really a problem, see below.) * take your code proprietary, which means replacing all gpl code by self-developed or more leniently licensed code. that doesn't change the fact that all your code written up to *now* is covered by the gpl, but you could then relicense it and all future development any way you see fit. obviously, as a lover of (and believer in) open-source, i would warmly recommend option #1, although i've been with universities long enough to know about the difficulties involved in fund-raising for open source projects. as for control, well, of course there is always the possibility of a fork, but then it's a fair free market for users and mindshare. if you decide to go proprietary, any gpl fork will likely see considerable uplift, and more than one company have made themselves obsolete by such a move - that's always the risk. on the other hand, if you decide to open up your stuff and encourage participation, your application will profit from an enlarged user and contributor base, while you still maintain control. as for taking patches: if people want to contribute and you can incorporate their work, great, it will make your project stronger. sometimes, your idea of software architecture might differ from that of a contributor, so you will reject patches. perfectly ok. of course, once many people have found their patches been turned down for reasons not entirely transparent or logical to them, there is new potential for a fork. or there may just be personality clashes, leading to a fork eventually. that's how it is. but market forces have a way of eliminating weak branches of a project rather speedily. i hope i was able to contribute some clarifying remarks. please take everything you read here with a metric grain of salt, and be aware that licensing issues happen to be very important to the open source crowd. it would be great to have you and your team join the open source community at large and see you on this list in the future - you will find there is quite some knowledge here that might be worth tapping into. best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] At the hands of Professor Keller and Raymond
lase...@gmail.com wrote: On Monday 27 July 2009 14:33:30 Jörn Nettingsmeier wrote: as to communication skills, raymond, i think you should go get a nice cup of coffee, tone down a bit, see what happens. this bears all the hallmarks of a excuse my french pissing contest, which might be explained by the history of your mutual correspondence, but from the outside, it looks like no big deal at all, and should sort itself out nicely. I can agree with almost everything else written in this post, but get off the attitude train people. It is not necessary to be nice all the time. no, but it helps. particularly if/when you assume the role of a project leader. i have no idea what makes you so irritable n- just kick back and relax. for us, a fork is something natural and no big deal at all. i guess you are just trying to make a point. perfectly valid reason for forking. for somebody who is not accultured to the open source ways and customs (as in, look, it's free, let's use it), a fork must feel like a threat. it's easy to clarify that misconception, and will lead to an altogether more productive outcome. being accused of license violation (no matter how valid) is certainly something that will drive most people into a defensive position. you have a point, but i think with a little more ease the whole thing wouldn't have escalated to tell X he's violating the gpl-style discussions, which, frankly, is ridiculous. And you are right. this is really not that big of a deal. Others are blowing it out of proportion to reality. Nothing illegal, immoral, or unethical is happening by the existence of a fork. In fact, a fork does not exist yet, only the same packages as on the Yahoo group, minus the GPL violations. It would have been very easy to do the right thing from the start. But that is the responsibility of others. why not just quietly smile to yourself with the warm fuzzy feeling of being right? without snide remarks for a week or so, everybody will beget a hundred projects and live happily ever after. and now grandfather must retire to bed. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!
Lennart Poettering wrote: On Mon, 22.06.09 23:46, Jörn Nettingsmeier (netti...@folkwang-hochschule.de) wrote: What is so difficult to understand that rtkit is not intended to be a solution for hardcore rt users? rtkit is not for you! Let me repeat this: RTKIT IS NOT FOR YOU! this is getting childish. my claim is: if you give rt to a user, you enable him to fuck the machine up. that's a law of nature. you can do all kinds of very clever things and try to have a very fast watchdog, but it doesn't prevent abuse. That is simply bogus. With the reset-on-fork kernel patch in place you can perfectly supervise an RT process and it cannot evade you. If the system becomes unresponsive (which is all that we try to detect), then we can demote/kill everyone who's misbehaving. you don't need to fork in order to do wreak havoc. how do you make sure you know which processes (i.e. which executables) deserve rt rights? hash them? and whatever you do, the moment the user loads a user-defined plugin from a user-controlled location (such as a privately installed LADSPA plugin), you are utterly hosed. or am i missing something fundamental here? in which case please enlighten me. btw, i'm not quite sure what RTLIMIT_RTTIME is supposed to do. you define a maximum amount of time that can be spent in rt mode, per user? or per process? or per group? if per user, how is scheduling fairness accomplished? does the first rt process grab as much as it wants, and then another rt process gets demoted by rtkit because the user used up their rt slice? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!
Lennart Poettering wrote: On Sun, 21.06.09 16:42, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote: As a user doing critical audio, say, in a concert situation, I'd require that my computer's realtime audio tasks can use 99.9% of the cpu for short amounts of time. I don't care if the rest of the user processes are momentarily slowed down (up to a point, of course). I would very much care if my computer, due to a temporary overload, decides to a) glitch the audio and b) demote the rt process to SCHED_OTHER permanently. It looks like the RealtimeKit is designed to do exactly that by default. By default the watchdog will only become active after 10s of complete lockup. This should be enough. We can raise it if this turns out to be necessary, but let's wait for a request based on real-world data before we do something like that. this demonstrates nicely that there is no solution to the problem (or that i don't understand what problem you are trying to solve). any user that gets rt privileges can DoS the machine. actually, one person's creative act is another person's DoS :) if you try to guard against forkbombs, you are obviously under the illusionary impression that you can guide against malicious users. you can't. with your new bit of policy, i just write a bomb that eats up 100% for 9.9s, then yields for as long as your daemon needs to be pacified, then hog the machine again. so what is this about? rt users want absolute control over their machine. anybody who can tolerate some arbitrary bits of policy thrown at them during work is by definition not an rt user. rt users must be trustable with root access, at least in terms of cpu governance, which is what rtlimits achivev just fine. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!
Lennart Poettering wrote: On Mon, 22.06.09 09:33, Arnold Krille (arn...@arnoldarts.de) wrote: You practically cannot take group membership away from a user after you gave it to him, and also adding a seperate group for every tiny bit you need to authorize access to doesn't scale. security is a matter of good design, not of oh, look, he has become evil, let's revoke his privileges ad-hockery. it should never be necessary to automatically revoke rights from users. if i have to get rid of a misbehaving creature fast, passwd -l villain in combination with mv ~villain/.ssh /tmp and a quick pkill fixes things for me. and the very good part is that this decision is made by a human, not by some imperial shitload of policy that caters to the needs of some mythical desktop user. your rtkit cannot protect against anything, you can just play policy catch-up with evildoers forever. that's about the same level of security that outgoing firewalls in windows provide - you depend on process names and whatnot, and if i rename Internet Explorer.exe to Windows Update.exe, i'm free to do as i please (not quite, but you get the idea). this is *not security*. this is theater. proper security sometimes includes the wisdom that certain threats cannot be met without throwing out the child with the bathwater. some daemon fiddling with rt privs at runtime in my book qualifies as drowning the child first, then throwing it out. maybe eating it afterwards, but i'm not sure. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!
Lennart Poettering wrote: On Mon, 22.06.09 23:19, Jörn Nettingsmeier (netti...@folkwang-hochschule.de) wrote: so what is this about? rt users want absolute control over their machine. anybody who can tolerate some arbitrary bits of policy thrown at them during work is by definition not an rt user. rt users must be trustable with root access, at least in terms of cpu governance, which is what rtlimits achivev just fine. What is so difficult to understand that rtkit is not intended to be a solution for hardcore rt users? rtkit is not for you! Let me repeat this: RTKIT IS NOT FOR YOU! this is getting childish. my claim is: if you give rt to a user, you enable him to fuck the machine up. that's a law of nature. you can do all kinds of very clever things and try to have a very fast watchdog, but it doesn't prevent abuse. my point is: since the rt user is locally trusted, you can just as well grant static rt rights using the rtlimits approach. if the user is not to be trusted with static rt rights, s/he is not to be trusted with any kind of rt rights, no matter how clever the daemon that grants them. so what is the problem you are trying to solve? this is really akin to handing out root rights and watching the filesystem, and as soon as the user starts reading other people's mail some script yells at him. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANN] lv2fil version 2.0 New hope released
Nedko Arnaudov wrote: Jörn Nettingsmeier netti...@folkwang-hochschule.de writes: hi nedko! Nedko Arnaudov wrote: James Warden warj...@yahoo.com writes: Where's the ardour patch ? Thanks :) http://nedko.arnaudov.name/soft/ardour2-r5126-lv2_external_ui.patch thanks for the lv2 port. since i've read some of fons' code and have a rough idea how it works, i hope this will give me the chance of learning lv2 by example - i'm pretty excited about this... haven't tested the lv2 version yet due to lack of time, but since this patch looks pretty self-contained, do you think it might make sense to push it into the upcoming ardour 2.8.1 release? It is not that clean, but I can clean it more if such cleanup is required for incusion in ardour 2.x. i don't know if this is still in time for 2.8.1, but yes, i would welcome this patch to go into the queue for 2.0-svn. haven't got a chance to test it yet (had some spurious ardour problems that i need to pinpoint before adding an out-of-tree patch), but hope to do so today. best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [SUMMARY] LADSPA extension for periodic control values?
hi everybody! thanks for sharing your thoughts! Jörn Nettingsmeier wrote: consider the case of periodic control values of LADSPA plugins, for instance the azimuth in a horizontal panner or the phase shift in a phaser. currently, they are usually marked as BOUNDED_BELOW and BOUNDED_ABOVE, but the host has no way of knowing that the upper bound is next to the lower bound, so that it can chose the shortest path to the next value when interpolating automation control points. take ardour, for example: if i want to spin a source 360 degrees, i have to start at 0, set a control point at 180, set another control point at the exact next sample to -180 and then onwards. if there is even a single sample between the control points, the interpolation will cause the image to jump in weird ways, because it doesn't know that 180 == -180. does it make sense to add a new hint to LADSPA, something like LADSPA_HINT_PERIODIC? it would mandate LADSPA_HINT_BOUNDED_BELOW and LADSPA_HINT_BOUNDED_ABOVE as well as the respective port range hints, *and* imply that LowerBound is equivalent to UpperBound in the port range hint structure. this would enable hosts to do the Right Thing(tm). to summarize: there seem to be no objections to adding such a hint (stefano's initial critique was about just using it without adding it to the standard LADSPA header, iiuc, which has never been intended). some people opined that it could as well be done in LV2 using an extension. there is no consensus yet about whether this belongs in the existing units extension, but this is orthogonal to the LADSPA issue. during the discussion, fons brought up the issue of adding an enum type to integer ports, to enable hosts to display meaningful string values for radio-button-type controls. the general usefulness of this was undebated. an RFC for a LADSPA 1.2 revision including both the periodic and the enum hints will be posted in a new thread. best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [RFC] LADSPA 1.2
hi everybody! as discussed in another thread, i would like to propose a new LADSPA release 1.2, which should include the following changes: 1. addition of a port range hint flag LADSPA_HINT_PERIODIC to denote periodic behaviour of a control port to be added to the LADSPA_PortRangeHintDescriptor bit field. if present, both LADSPA_HINT_BOUNDED_BELOW and LADSPA_HINT_BOUNDED_ABOVE must be specified as well. moreover, both LowerBound and UpperBound must be present in the corresponding LADSPA_PortRangeHint struct. the presence of LADSPA_HINT_PERIODIC implies that LowerBound is equivalent to UpperBound. hosts should consider displaying a widget that reflects the periodic nature of the corresponding control value, such as a rotary control. hosts that interpolate between control values defined by the user (such as automation points in a DAW) should take into account that the shortest path between two given values might cross the boundary defined by LowerBound resp. UpperBound and behave accordingly. usage example: soundfield rotators, circular panners 2. addition of a port range hint flag LADSPA_HINT_ENUMERATED to inform hosts that an integer-type port (as denoted by LADSPA_HINT_INTEGER) should be annotated with a set of labels rather than numbers. LADSPA_HINT_ENUMERATED mandates the following: LADSPA_HINT_INTEGER is set. LADSPA_HINT_BOUNDED_BELOW and LADSPA_HINT_BOUNDED_ABOVE must be set. in LADSPA_PortRangeHint, LowerBound must be 0, UpperBound must be 0. the number of labels provided must be equal to (UpperBound - 1). some of these mandatory settings are redundant and could be handled as being implicit. however, for the sake of backwards compatibility and to to allow older hosts to display a meaningful UI even if they don't implement the new flag yet, all these items MUST be set. as to the location of the actual enum of labels: fons adriaensen suggests adding them to the end of the PortNames array. this implies that for multiple enum-labelled controls, the labels would have to be concatenated and the host would have to tell them apart by keeping track of the corresponding UpperBound offsets, which might become a little messy. your comments are welcome. best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [RFC] LADSPA 1.2
Fons Adriaensen wrote: On Thu, Jun 18, 2009 at 06:28:32PM +0200, Jörn Nettingsmeier wrote: 2. addition of a port range hint flag LADSPA_HINT_ENUMERATED to inform hosts that an integer-type port (as denoted by LADSPA_HINT_INTEGER) should be annotated with a set of labels rather than numbers. LADSPA_HINT_ENUMERATED mandates the following: LADSPA_HINT_INTEGER is set. LADSPA_HINT_BOUNDED_BELOW and LADSPA_HINT_BOUNDED_ABOVE must be set. in LADSPA_PortRangeHint, LowerBound must be 0, UpperBound must be 0. the number of labels provided must be equal to (UpperBound - 1). ??? This should be (UpperBound + 1) AFAICS obviously, sorry for the confusion. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] LADSPA extension for periodic control values?
hi everyone! sorry if this has been discussed before, but i didn't find anything in the archives... consider the case of periodic control values of LADSPA plugins, for instance the azimuth in a horizontal panner or the phase shift in a phaser. currently, they are usually marked as BOUNDED_BELOW and BOUNDED_ABOVE, but the host has no way of knowing that the upper bound is next to the lower bound, so that it can chose the shortest path to the next value when interpolating automation control points. take ardour, for example: if i want to spin a source 360 degrees, i have to start at 0, set a control point at 180, set another control point at the exact next sample to -180 and then onwards. if there is even a single sample between the control points, the interpolation will cause the image to jump in weird ways, because it doesn't know that 180 == -180. does it make sense to add a new hint to LADSPA, something like LADSPA_HINT_PERIODIC? it would mandate LADSPA_HINT_BOUNDED_BELOW and LADSPA_HINT_BOUNDED_ABOVE as well as the respective port range hints, *and* imply that LowerBound is equivalent to UpperBound in the port range hint structure. this would enable hosts to do the Right Thing(tm). best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ANN] lv2fil version 2.0 New hope released
hi nedko! Nedko Arnaudov wrote: James Warden warj...@yahoo.com writes: Where's the ardour patch ? Thanks :) http://nedko.arnaudov.name/soft/ardour2-r5126-lv2_external_ui.patch thanks for the lv2 port. since i've read some of fons' code and have a rough idea how it works, i hope this will give me the chance of learning lv2 by example - i'm pretty excited about this... haven't tested the lv2 version yet due to lack of time, but since this patch looks pretty self-contained, do you think it might make sense to push it into the upcoming ardour 2.8.1 release? best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Can't load firmware on RME HammerFall DigiFace
Natanael Olaiz wrote: El 04/27/2009 07:44 AM, Florian Faber escribió: Natanael, Did the card work before or is this your first try? It works on Windows, and it worked on Ub. Intrepid (hdsploader just complained about the .bin place, and I copied from the alsa source package...). It sounds like a problem with the cardbus driver. I've seen these strange phenomena a dozen times, and it was always a problem with the cardbus chipset/driver. If it worked with Intrepid (whatever that is), then please find out what has changed since then. It is obviously not a problem with the hdsp driver. Intrepid Ibex is the code name of Ubuntu 8.10 (hardy is 8.04). One of the major differences is the kernel (2.6.27, I think), but the problem is that is not RT patched, reason to use 8.10 (hardy) or 9.04 (jaunty) :( does ubuntu have the /proc kernel config option enabled? if so, you will find a file /proc/config.gz which contains the kernel configuration of the ubuntu kernel. now grab a recent kernel plus rt patches, unpack it, unzip that config.gz into the kernel build directory and rename it to .config. then make gconfig, select fully preemptible kernel (real time), then make bzImage modules, then (as root) make modules_install install. there you go. unless ubuntu has lots of patches in their kernel, you should be able to drop the new one in without major hassles. the only thing that doesn't work for me when replacing the kernel (on suse systems) is suspend-to-ram, ymmv. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Current state of lash
Christian wrote: Hi there, I'm currently thinking about using lash for my project. But their website is down, when I used it a year ago it was worked like crap with crashing etc. Therefore I'm wondering how the actual state of this project is(is it stable?) and if you recommend using it for developing. Christian juuso did an interesting presentation on LAC. you can find the slides at http://lad.linuxaudio.org/events/2009_cdm/slides/ . the video is not up yet, but should be rsn. if nobody else follows up on this thread, you might try jack-devel instead, or get a quick round of opinions on #jack at irc.freenode.net. best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] LAC 2009 videos available
hi everyone! the videos from lac 2009 are being made available at http://lad.linuxaudio.org/events/2009_cdm/videos/ . most of the footage is there - the missing stuff will follow in a few days as florian (aka faberman) gets home from a production in italy and finds time to encode the rest. the video quality this year is quite stunning - thanks to the theora team for huge improvements in efficiency and quality. if you are a video person and haven't upgraded to the thusnelda branch encoder, do it NOW (before even going for a coffee). then hit #theora on freenode.net and sign hymns of praise until they kick you out. you will note that the videos are raw - they could use trimming some talks consist of several fragments that need concatenating, but due to some stream problems they caused oggCat to barf, even though every single fragment plays ok. your help is appreciated - get in touch with me off-list or via l-a-d if you have worked on the stuff and would like to upload your improved version. best regards, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [LAC2009] stream team volunteers wanted!
hi everyone! for those among you who will make it to LAC 2009 in parma: we are looking for 1-2 more people to help with the streaming. your job would be to watch the paper sessions, hang out on IRC and relay the questions of remote participants to the local audience. if you're interested, you also get to play with some interesting video gear and the blazing new thusnelda encoder :) please get in touch! volunteers will be fed and watered as required, according to the Marije Baalman StreamTeam Sustenance Plan(tm). unfortunately, stream overlord eric rzewnicki can't be with us this year - i'd like to take the opportunity to offer HUGE (and i mean, like, HUMONGOUS) kudos to edrz for many years (and many more hours) of volunteer work for this community (not to mention shouldering frightening travel expenses year after year to haul himself to old europe). edrz: thanks! i hope we'll see you on IRC. best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] New release of jconv
Steve Fosdick wrote: On Tue, 2009-03-10 at 23:28 +0100, Fons Adriaensen wrote: Hello all, Jconv-0.8.0 is now available at the usual place Fons, This appears to use a version of libsndfile that has ambisonic functionality. Is this in the mainstream libsndfile or is there a forked or patched version somewhere? you can edit the makefile to make it work without. you could also get a pre-release from eric's website: http://www.mega-nerd.com/tmp/ but unless i'm very much mistaken, the current release does include .amb support already. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] New release of jconv
Fons Adriaensen wrote: On Wed, Mar 11, 2009 at 01:44:45AM +0300, alex stone wrote: What am i doing wrong here? Nothing, I forgot you need an update of zita-convolver. It's uploaded now. Make sure to check the makefile for zita-convolver and add the best optimisation flags for your CPU. thanks, that one fixed the problem for me. there's a spurios makeald in the Makefile that prevents the install target from working. i deleted it without apparent ill effects. best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] New release of jconv
wow. thanks for the new example configurations and the extensive comments! very helpful. the convolver itself is a bit of a marketing disaster, though. i mean, uh, it just convolves. No fancy new features, such as UltraLowJitter, or at least TrueMultiplyAndAdd (for purists, as opposed to FFT-based, for that extra dash of depth and clarity). And TubeMode would be cool as well. but one cannot have it all, i assume. ;) in the reverb configs, you mention that you cut off the direct sound by setting an offset, which will then make the convolutions suitable to use in a classic aux send setup, so that the reverb return will be 100% wet. but why do you remove the first 5 ms of the room response? i seem to recall it is about control of low frequency energy, but i forgot the details. are those 5ms a natural constant, a matter of taste, or maybe a function of the room's rt60? pointers to TFM would be R with great interest. best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Re : Saving plugin presets
Stefan Kost wrote: Just wanna say thanks! GStreamers ladspa bridge now has initil lrdf support. Classification works, presets next. I wish Fons's ladspa packages would have rdfs. Fons, would you accept them if I try making them? last time i looked, fons was distributing a global rdf file for all his plugins as a separate download. fons, is there any particular reason not to split it up and ship the appropriate parts with each of your ladspa packages? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ot] - NEED some security advise PLEASE! + new question
Luis Garrido wrote: I need to set up a machine as a router. One side is a fixed public IP address, the other side is a local net using 192.168.1.x. I want to give internet access to the machines on the local net, so this requires (AFAIK) NAT. Anyone has a pointer to a good tutorial about how to do this ? Google the words 'iptables' and 'masquerade', piece of cake. masquerade only works from the inside to the world. for remote access to inside hosts, you need port forwarding (or DNAT, destination nat, in iptables lingo). problem is, when you have, say, 16 hosts for which you want to open ssh access, you need 16 ports on the router. gets nasty real quick. what i usually did was to say port 22000 is the base port for ssh, add the last quad of the internal ip address of the host you want to reach and forward accordingly. same for any other services you might want. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [LAU] Request for open source solution to spectrograms and phase measurement
Ismael Valladolid Torres wrote: On Thu, Feb 5, 2009 at 4:38 PM, Raphaël Doursenaud rdoursen...@free.fr wrote: meterbridge does phase plots in its jellyfish mode. Thanks a lot for your kind answers. Any of your suggestions work realtime? japa and jkmeter are realtime tools. sonic visualizer is an off-line tool, at least those parts i've used yet. phase response is not too important to have in realtime imho (unless you are talking about relative phase and coherency, in which case raphael's recommendation, meterbridge, works just fine). ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] sound dissipation in air - formulas and filters? (Maitland)
Maitland Vaughan-Turner wrote: J?rn Nettingsmeier netti...@folkwang-hochschule.de sez: true, for this particular case it would do (and that's what i'm using atm). but i have this idea for a plugin that takes actual mic distance, temperature, humidity and desired distance as parameters and will do something that is reasonably correct (not taking into account sound diffraction or reflection at temperature boundary layers, obviously). would be kind of cool, but i need to get a deeper understanding of the physics involved... especially the dependance on humidity is a very tricky and quite non-linear issue. fons is probably right that it doesn't make all that much of a difference, but since such a plugin could be a nice learning tool for sound engineers, i'd want it to be as precise as reasonably possible. This sounds like a really interesting project to me, and I wish you all the best in completing it! Aside from being a nice learning tool, I'm sure it will be a *very* nice creative tool, as well. I can't wait to hear what it sounds like to modulate humidity with a sine wave! :-D the effect will be very subtle indeed. gives a whole new ring to the term vaporware. while we're at it, the in and out ports should probably simulate corrosion after prolonged exposure to humidities .8 ... patches welcome. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] sound dissipation in air - formulas and filters?
victor, fons, thanks for your replies. Fons Adriaensen wrote: This will show you that a simple 2nd order lowpass will do the job - it's not a perfect match but good enough. It's not critical at all - for small distances you can even use a standard shelf or parametric. true, for this particular case it would do (and that's what i'm using atm). but i have this idea for a plugin that takes actual mic distance, temperature, humidity and desired distance as parameters and will do something that is reasonably correct (not taking into account sound diffraction or reflection at temperature boundary layers, obviously). would be kind of cool, but i need to get a deeper understanding of the physics involved... especially the dependance on humidity is a very tricky and quite non-linear issue. fons is probably right that it doesn't make all that much of a difference, but since such a plugin could be a nice learning tool for sound engineers, i'd want it to be as precise as reasonably possible. google books has one interesting paper, but it's part of a rather expensive book: http://books.google.de/books?hl=delr=id=1x_RvffW-hcCoi=fndpg=PA305dq=Sutherland+Atmospheric+sound+propagation+ots=-_5OK7SyHSsig=XvBWOH8X-1W-CTszwGpkfeomO8Y#PPA306,M1 there is a graph on page 307 that is quite frightening (and that's for a constant temperature :) i think i'll go digging in the library first. best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Accommodation in Parma
Juuso Alasuutari wrote: Good news. I found out last week that I'll receive sponsorship for my LAC trip. That means there will be a LASH presentation, and I think a LASH workshop is also in order. The amount I'm getting isn't all that much but it will cover my travel costs. That means I'm on the lookout for _cheap_ accommodation near the conference site during 15.-20. April. Is there some place there specifically for LAC visitors? fons, i have heard from a number of people who have to cut accommodation costs as much as possible to be able to attend. imho, it would be very unfortunate to lose many prospective attendants for lack of money... :( if the weather is as promised, i've heard from several people who would like to camp. is there a cheap campsite within easy walking distance of the LAC venues (or, even better, a patch of lawn on campus combined with a gym for sanitary facilities?) if so, some info on the lac page would be helpful. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] wfs streaming project report
Fons Adriaensen wrote: On Sun, Jan 18, 2009 at 01:00:06PM +0100, Jörn Nettingsmeier wrote: Earlier today in Rome there was a performance of Stockhausen's Helicopter Quartet (the third ever worldwide) in which the four members of a string quartet perform in as many helicopter hovering above the concert hall, with the resulting music being reproduced for the audience inside. I've not seen any engineering reports on it so far, but it must have been a nice challenge as well. wow. somebody finally did it? i know there have been at least two attempts before, and both were cancelled as the expenses were skyrocketing :) the tricky part of the heli quartet is that not only do you need 4 bi-directional wireless audio links (the quality of which is pretty secondary, given the available s/n inside a helicopter - i guess you could do it with standard uhf audio gear and pimped antennae), but you also need 4 very high quality video links for the musicians to be shown on screens in the auditorium. and i would imagine a helicopter cockpit to be a quite emr-unfriendly environment, and the available power to be rather noisy... even greater than the engineering challenge will be the challenge of getting anybody to pay for that bs^H^Hthe realisation of such a visionary piece of art. which seems to have succeeded :) flamebaitwhile i do have a soft spot for the old geezer from sirius, i think the money would have been better spent on a whole bunch of other works less heavy on artistic hubris and a bit better equipped in the taste department./flamebait jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LAC2009
David Robillard wrote: On Wed, 2009-01-14 at 18:40 +0100, Jörn Nettingsmeier wrote: David Robillard wrote: I'd like to do an LV2 presentation this year, but I don't think I can swing attendance :/ Dah well please with sugar on top? we should really have more infrastructure meetings. it would be great to have a dbus/lash and a lv2 session at lac09... and i'd love to hear your lv2 presentation :) jörn (who has never ever complained to you about drobilla.net svn not compiling :-D) http://dev.drobilla.net/newticket ;) http://dev.drobilla.net/ticket/321 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LAC2009
David Robillard wrote: On Tue, 2009-01-13 at 01:33 +0200, Juuso Alasuutari wrote: On Monday 12 January 2009 23:52:04 Fons Adriaensen wrote: Hello all, Many thanks to all who have responded to yesterday's message ! There is still room for more, so start writing the paper you always wanted to write, or preparing the workshop you always wanted to do... The paper deadline will be extended to the 29th of this month. ... Earlier some of you expressed the desire for developer meetings, brainstorms or working sessions. I'd ask any specific groups who want to meet in Parma to get organised and keep me informed. I'm thinking hard about whether to offer a presentation about LASH's recent changes and future. I'd at least like to host a LASH brainstorming session, like we had for JACK last year. And I trust there will be a JACK meeting again this year too, no? Dooo it :) Though, both LASH and JACK talks/session/whatever converge at the D-Bus stuff... maybe they could be tackled as a single concept (LASH pretty much exists to solve a problem caused by the use of JACK anyway) I'd like to do an LV2 presentation this year, but I don't think I can swing attendance :/ Dah well please with sugar on top? we should really have more infrastructure meetings. it would be great to have a dbus/lash and a lv2 session at lac09... and i'd love to hear your lv2 presentation :) jörn (who has never ever complained to you about drobilla.net svn not compiling :-D) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] wfs streaming project report
hi guys! today i felt a little bored and needed to do something to avoid finishing my lac paper, so i brushed up the documentation about the wave field synthesis live streaming project that i did for tu berlin last year. if you need to kill some time and enjoy reading war stories with linux audio, really loud music and infrared lasers in them, have a go at http://stackingdwarves.net/public_stuff/event_documentation/wfs_live_transmission_2008/WFS-Report-web.pdf best regards, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LAC2009
Fons Adriaensen wrote: On Wed, Jan 14, 2009 at 06:40:17PM +0100, Jörn Nettingsmeier wrote: jörn (who has never ever complained to you about drobilla.net svn not compiling :-D) :-) That makes two of us ! Jörn, just think of all the fu^H^Hmisery you could have with kokkinizita.net svn... :-) fons is referring to the fact that i'm constantly pestering him to go a little more bazaar-style with his software, grumpy old perfectionist that he is ;) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
