Re: [linux-audio-dev] Re: Pitchshift/Timestretch project..
On Mon, Apr 05, 2004 at 04:15:05PM +, J_Zar wrote: Mmmm... Could be a very improvement for the sound streching. I've some problem with SoundTouch (compiling and latency issues)... So I'm interested... but from what I can see from the project page, there is a donate form but no CVS or code package! This is quite strange IMHO... The project is still in research stage, that's why. That also takes time (and money for someone who programs for a living). I hope in the future. I don't think there is anything to worry about. v
Re: [linux-audio-dev] Pitchshift/Timestretch project..
On Tue, Apr 06, 2004 at 12:07:08AM +0200, Christian Schoenebeck wrote: Es geschah am Montag, 5. April 2004 23:33 als Erik de Castro Lopo schrieb: Well me. I've been working on this since the start of the year, but been thinking about the problem for over 10 years. Which brings me to the question: how old are you? :P Just kidding, But I also planned to do some research on pitchshifting in conjunction with formant correction. If anybody has good material about that, don't hide it! Seems this field screams for getting elaborated. CU Christian Be sure to ask Stephan for references too :) v
Re: [linux-audio-dev] Major problem with RME HDSP/Multiface and a 64-bit AMD laptop
I see this machine has an ENE cardbus controller, for which problems have been reported in the RME support newsgroup @ nntp://news.x-networks.de/rme-audio I do not know the full details of the problem, and I don't know if your particular setup is affected, but there were at least some cases reported where the ENE cardbus controllers were not able to perform bus mastering, which is essential for doing high throughput over the bus (lots of tracks). A single track should play nicely imho. Anyway, check the newsgroup, RME support is great and there are lots of posts about this subject already. This is a page I found about your particular laptop, though there is not much info on it yet: http://people.debian.org/~ccheney/arima-w720-k8.html best regards, Vincent
[linux-audio-dev] mail loop
Anyone else experiencing a mail loop with the latest cross posted messages to LAD and LAU by Steve and Chris ? regards, v
[linux-audio-dev] mail loop - headers
Re: [linux-audio-dev] DRI + Jack conflict?
On Fri, Feb 13, 2004 at 12:14:53PM +, Steve Harris wrote: Hear hear. I think that GL accelration is a (potentially) important optimisation for audio apps - it saves a lot of cache and memory bandwidth that can be better used number-crunching audio. Right. Paul is right that its a kludge, but detecting the QT library and unlocking it doesnt actually look that hard. - Steve Cool, only right now I don't have the time to chase it down myself, at least not fast enough without help. v
Re: [linux-audio-dev] DRI + Jack conflict?
On Fri, Feb 13, 2004 at 03:24:05PM +, Steve Harris wrote: Matrox have just release a card designed for audio that has no fans (due to downclocked 3d processor) and lots of acceleration on all heads. Which one ? :) Right, well in the meantime im doing it as optional - eg. I have an alpha version of meterbridge which can use GL - if you have it, it's massivly more efficient, it looks better and you can resize the windows. - Steve Nice ! v
Re: [linux-audio-dev] DRI + Jack conflict?
Do you use the Radeon binary driver ? v On Mon, Feb 09, 2004 at 06:26:20PM -0500, Dave Robillard wrote: Through a painful process I'd rather not go into, I discovered that Jack will not run in realtime mode with my Radeon's 3d drivers loaded.. I get the error cannot lock down memory for RT thread My idea-for-the-day was visualisation of realtime jack audio (from live performance); needless to say my day ended up far less interesting than I had hoped. :) Is this a known problem, or screwy system configuration on my part? (XFree-4.3.0, Radeon9000 Pro, Linux 2.4.24 lowlat) -Dave
Re: [linux-audio-dev] DRI + Jack conflict?
On Mon, Feb 09, 2004 at 08:19:55PM -0500, Dave Robillard wrote: Now that ATI has gone the way of Nvidia I don't know who to pledge allegiance to. :) Is Matrox still friendly? I would say that there is still hope as far as ATI is concerned. They are delivering specs to the Linuxbios people, so they can get VGA working through LinuxBIOS :) regards, v
Re: [linux-audio-dev] DRI + Jack conflict?
On Mon, Feb 09, 2004 at 07:32:35PM -0500, Paul Davis wrote: the implementation of DRI by certain video interface drivers means that we end up trying to lock the video memory as well, and this tends to fail for various reasons. Hm, that sounds bad. Does this problem also happen with the open source drivers from dri.sf.net ? I was just thinking of getting an IBM thinkpad and I might want to change the model I want based on this. its not what to do about this. the most obvious answer is don't try to run real-time software on systems with these video drivers installed. i know its not very satisfactory, but its all we have for now. Too bad :/ v
Re: [linux-audio-dev] DRI + Jack conflict?
On Mon, Feb 09, 2004 at 06:58:49PM -0500, Dave Robillard wrote: I remember seeing that page a little while back, I'll definately look into it.. looks pretty crazy! It definitely looks great. I want to test it too. (If it's based on portaudio can I still connect it to my jack graph somehow? Never used portaudio..) Sure, portaudio is a generic layer which you can code for. It has support for jack in the new development series (v19): http://www.portaudio.com/status.html v
Re: [linux-audio-dev] DRI + Jack conflict?
On Mon, Feb 09, 2004 at 07:32:35PM -0500, Paul Davis wrote: its a basic problem with real time software, the POSIX API etc. JACK tries to lock *all* the process memory. This is to ensure that nothing gets swapped out, right ? Else it is very hard to ensure real time performance ? (sorry for being somewhat ignorant in this matter). POSIX doesn't offer any APIs that would allow us to lock only the parts we need locked without a lot of impossibly ugly, non-portable kludgery. the part that needs locking consists of any memory that will be touched by the code run in the JACK-managed audio thread. the implementation of DRI by certain video interface drivers means that we end up trying to lock the video memory as well, and this tends to fail for various reasons. Is this faillure due to the nature of the memory that we are trying to lock ? Or is the problem that we try to lock the same part of memory multiple times ? its not what to do about this. the most obvious answer is don't try to run real-time software on systems with these video drivers installed. i know its not very satisfactory, but its all we have for now. Would the less obvious answer consist of one of the following ?: - change the video drivers (at least the ones that are source based) - do something at the API level, so we can lock selectively From what I can gather the optimal solution would be an API that can give us what we want (only locking the memory that gets touched by the audio thread and nothing else), but obviously this goes beyond the scope of jack alone ? Would you consider implementing a work around (aka non portable kludgery) a waste of time ? regards, v
Re: [linux-audio-dev] DRI + Jack conflict?
On Tue, Feb 10, 2004 at 01:45:49PM +0100, Robert Jonsson wrote: I'm running quite happily with DRI enabled on my ATI card now, the problem was definitely that it was trying to lock too much memory. Ok. I assume that you have a Firegl T2 with 128Mb Ram (using the ATI 3.7.0 drivers) ? Since shrinking the amount of vidmem that X utilizes I haven't run into this problem again (see other message for the actual remedy). Yep, I read that message. I wasn't so sure if that was a complete solution though, as Paul talked about faillure to lock memory for _various_ reasons :) So another solution would be to add more RAM to the machine you're working on ? :) best regards, Vincent
Re: [linux-audio-dev] DRI + Jack conflict?
On Tue, Feb 10, 2004 at 08:31:10AM -0500, Dave Phillips wrote: Machine is an 800 MHz AMD w. 512 MB RAM, system is Planet CCRMA RH 9. Any help on this matter would be greatly appreciated. I haven't had this kind of noise problem before now, I'd certainly like to get rid of it, and I'm willing to try about anything at this point (as long as it doesn't cost much ;). Personally, if I would have to buy a new video card, I'd rather give the money to a knowledgeable hacker for a workaround :) I'm not yet sure if the problem will affect me (I think it will though, I want to use jack in realtime mode together with accelerated 3D on a laptop, which I will get in a few weeks time), but if it does, I'll certainly consider forking over some cash to pour in a GPLed solution. v
Re: [linux-audio-dev] DRI + Jack conflict?
On Tue, Feb 10, 2004 at 01:57:17PM -0500, Jesse Chappell wrote: BTW, i just ran JACK realtime on a T41p with the firegl T2 128MB, using the ati 3.7.0 drivers on a 2.4.22 PE/LL kernel with no problems. Alsa 0.9.8 using the builtin audio (snd-intel8x0). the machine itself has 512MB of RAM. Great ! Thanks for testing :) Which distribution are you running ? I tested with alsaplayer, jack-rack and freqtweak together loading the system to 80% cpu utilization and no xruns at 256 period size (and possibly less) and 48k. Cool. That's about 5.3 ms, which is good :) And yes, ATI's drivers have DRI enabled note that i didn't try to run any opengl accelerated apps at the same time as jack yet. but i don't see any of the problems with regard to memory locking. maybe 512 is too much RAM to notice the problem. jlc I'm aiming to get more memory, so the memory locking should really be no problem :) I hope I can test fluxus once I get the laptop :) v
Re: [linux-audio-dev] Software with source code?
On Tue, Feb 03, 2004 at 03:32:36PM +, Steve Harris wrote: Er, yes. I think this can be left up to the submitters discression. eg. http://freshmeat.net/projects/sweep/ looking at that I guess you would want required-package and recommended-package being sub-properties of depends-on I know the Debian system handles recommended/suggested/needed etc. dependencies pretty well, we could have a peek at whats happening there :) v
Re: [linux-audio-dev] [OT] linux audio on PPCi
On Mon, Dec 01, 2003 at 10:12:24AM +, Steve Harris wrote: I guess the more of us who buy them the quicker the endianness problems will be fixed, ppc-linux-audio-user? :) :) I was thinking along the same lines ;) v
Re: [linux-audio-dev] modular synth GUI status?
On Wed, Nov 19, 2003 at 08:03:06PM +0200, Juhana Sadeharju wrote: Hello. Who of us are working on a modular synth GUI where user grabdrag modules and connects them with cables? I'm myself interested in the editor GUI development --- there already are many modular audio engines, but not particularly good GUIs (Quasimodo might be an exception if I remember correctly). (cut) Cable GUIs are an anachronism to me, but it is hard to come up with new versatile alternatives :) v
[linux-audio-dev] Linux on TI DSP boards
http://www.linuxdevices.com/news/NS3468265897.html Looks cool. A little proprietary, but it seems to have an SDK. vini
Re: [linux-audio-dev] Linux VERSUS OSS ???
On Tue, Oct 14, 2003 at 09:44:32AM -0700, Love Bucket wrote: You should not be writing apps with OSS. If you want portability use PortAudio. LOL! PortAudio uses... OSS! Read http://www.portaudio.com/docs/proposals/status.html Find alsa, oss and jack. Note that way more functionality is available on top of alsa. Then try to remember that portaudio does not run on top of OSS. What good would a portable API be if it wasn't portable ? v
Re: [linux-audio-dev] Re: Linux VERSUS OSS ???
On Tue, Oct 14, 2003 at 09:41:14AM -0700, Love Bucket wrote: Where is the equivalent for ALSA? Until it exists, we will continue using OSS! http://www.alsa-project.org/documentation.php3 Or do you really want *.pdf ? There are tools for that. v
Re: [linux-audio-dev] lowlatency test at linuxdevices
On Fri, Sep 19, 2003 at 07:23:47AM -0400, Paul Davis wrote: Open source is a bit slower to move, but at least it sticks around! So true. Anyway, at least there will be a patch; the most recent one for 2.4.20 just came out. You mean: http://sourceforge.net/projects/high-res-timers/ ? I just stumbled on this while searching for high resolution timers on google: http://www.cs.wisc.edu/paradyn/libhrtime/ It seems old though (and probably unmaintained ?), latest patch was for 2.4.0, so I don't know if it is of more interest than the high-res-timers patches (probably not). vini
Re: [linux-audio-dev] kernel 2.6
On Thu, Jul 24, 2003 at 06:03:33AM -0700, Tim Hockin wrote: I haven't used kernel 2.5/2.6 for any audio stuff yet. I'm at the Linux Symposium this week - do we have any requests or gripes with 2.6 that I can relay to the core kernel guys? Audio is a workload they don't really test. I'm not an expert at all, but I guess with the pre-empt patches in and Andrew Morton's low latency patches, we are ok in the latency department ? We should (*should* cause we didn't test it yet) be ok wrt. latency, as I hope that there are no more long held locks and most of the big kernel lock is gone. Any other things we can come up with ? v
Re: [linux-audio-dev] Digital Room Correction (DRC) 2.2.0
Dual licensing might be an option too ? I'm not really an expert on it though :) Anyone know the ins and outs of dual licensing ? v
Re: [linux-audio-dev] New form of GPL licence that protects Linux from proprietary world [was: New powermacs?]
On Sat, Jun 21, 2003 at 08:22:37PM -0400, Ivica Bukvic wrote: However this brings up one interesting point/problem. Due to GPL nature of Linux software, many of our efforts will seamlessly bleed into OS X world since there are no restrictions as to which platform this software is run on, and Apple made an explicit move to target open-source developers and/or users by implementing Darwin and underlying almost-Unix system. Yep especially since Gentoo/Fink/... announced they would be cooperating. To me this is a problem. Since, all our efforts and time will not lure more people to Linux. Rather, our software will (perhaps) become popular (pro-tools killer or whatever), but not necessarily on a Linux platform. In the end, we will not reap what we have sown. Users on the OS X will be theoretically able to run Ardour as much as we will, especially now that jackd has been ported to OS X. To me, this does not seem right. A port is a port. We have the capability to pinpoint bottlenecks in the kernel, and if its a bug, it will get fixed, provided we yell loud enough. Try that on Mac OS X. Not everything is open in the OS X world. Perhaps we should make a mended version of GPL that would have exact permissions like the original GPL license, but in addition would ask that the software cannot be run on top of proprietary OS. That's not very Free is it ? (cut) What do you think? Unnecessary. Would take time off from writing these great apps to politics. Let's not get into that. We are free, and so are our users. They should respect the GPL, so we can develop in all freedom. We needn't restrict them to a platform. Remember how angry we would be when forced to use a common platform (even a common *nix distro or even kernel ;). v
Re: [linux-audio-dev] New powermacs?
On Sat, Jun 21, 2003 at 07:53:38PM -0400, Ivica Bukvic wrote: (cut) -- a unified and powerful underlying framework. Yet, that is not what we're working on right now... I noted a lot of Mac OS X projects making use of libsndfile already. The common Unix base is a huge step forward. Now there are 2 mainstream OSs with more or less the same semantics. Oh well, never mind. I am rambling away... Maybe I am simply impatient... I'll try to get some RR this summer, then maybe my outlook on the whole enchilada will not look so grim :-)... :-) v
Re: [linux-audio-dev] New form of GPL licence that protects Linuxfrom proprietary world [was: New powermacs?]t
On Sat, Jun 21, 2003 at 10:19:21PM -0400, Ivica Bukvic wrote: My point exactly :-). Just to add a bit onto this issue is that we could still support non-opensource systems, but they would need to purchase the software (see my other e-mail with the Trolltech as an example). Dual licensing is a better option. But don't change the GPL, please. v
Re: [linux-audio-dev] [OT] Question about some definition..
On Sat, Jun 14, 2003 at 12:12:37AM -0300, Juan Linietsky wrote: Hi! i'm doing some studying on dsp, and one thing I could never properly understand is the term of excitation signal I seem to find it associated to environment or natural sources, but I cant really find a definition. Could someone with enough knowledge on this subject please give me a brief on this? Thanks in advance! To me, an excitation signal is like a pulse, or a step function, which you can use as an input to your system. What comes from the output, you can then use to derive the transfer function of your system, which completely determines the sound of it. Eg. if you manage to record how a cavity reacts to a pulse, you can simulate that environment for other sounds too. This more or less assumes linear characteristics though. Non linear systems are more difficult to identify (to create a model of), and unfortunately most interesting things happen when non linearities are involved (tube amps, analog Moog synths). hope that more or less clears some things up v
Re: [linux-audio-dev] GPL and VST.
What I do know about this, is that it is illegal from the VST SDK license point of view to redistribute their headers with some GPL sources, so the end user has to download the SDK with the headers included, to be able to compile your plugin with VST support, if you license it GPL. I don't think that is a showstopper, it is only a nuisance. regards, Vincent PS: please consider creating a ladspa plugin from your sources: http://www.ladspa.org/ , information about its API can be found at http://www.linuxdj.com/audio/lad/resourcesapi.php3 There you can also find info about JACK, which is a great low latency audio connection toolkit (that way you can test your plugin by linking it to the audio stream of say a soft synth or some stuff you recorded). On Sat, Jun 07, 2003 at 01:48:35PM +0200, Torgeir Strand Henriksen wrote: Hello A friend and I have made a VST plugin as a college project, and would like to open source it, and possibly port it to other plugin APIs. We are considering the GNU GPL for our licence, which has lead to this question: Does VST count as a special exception of being anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable, or should we follow the suggestion about [1]controlled interfaces in the GPL FAQ? [1] http://www.gnu.org/licenses/gpl-faq.html#TOCLinkingOverControlledInterface -- Torgeir Strand Henriksen [EMAIL PROTECTED]
[linux-audio-dev] Hartman Neuron
http://www.sequencer.de/neuron/neuronal.html This synth has a mainboard running Linux inside :) Seems like not only Stanton (Final Scratch) is relying on Linux in the pro audio world these days .. regards, Vincent
Re: [linux-audio-dev] Hartman Neuron
On Tue, Jun 03, 2003 at 10:19:02AM +0200, Jay Vaughan wrote: (cut) Linux has all the right ingredients for a good general-purpose audio i/o processing platform. The API's are fresh and well thought out, and expanding rapidly to accomodate the needs of performance app writers. Knowing that you know the APIs of Mac OS X too, do you still see some things lacking in the current Linux APIs ? I must say I really like the jack api and ladspa. One thing that is unfortunate (others would call it a strength), is the lack of a unified set of widgets we could use to build plugin guis from (or any application for that matter). When I look at OS X I see consistency all the way (besides the high price which is also hard to ignore ;). It should come as no surprise... in fact, I would say stand back and watch: just as embedded Linux systems have revolutionized the networking appliance realm, so too will it happen with the 'musical instrument appliance' market. Yes. I was amazed with Stanton pioneering their Final Scratch on Linux, but coming to think of it, it is all about total control. Using some sort of live cd distro, you can avoid a tech support hell supporting operating system bugs, while you should only be giving support for your own bugs. Here at Access we only use Linux as a lab tool for testing purposes, but it is feasible that a synth manufacturer could base a product around the Linux platform. Hartmann have done it, a few other known synth brands are doing it too. What I really crave for, is a affordable general purpose DSP card, with a decent driver for Linux, to experiment with. There is little doubt that Linux has a firm hold in the embedded world, these days... and in that realm, it has a lot to offer. I would also note the use of live cds (cfr. Knoppix, Gentoo, ...). Imagine popping in a cd in a tray of a machine, and having an instant audio workstation/synth/... Combine it with LinuxBIOS booting in a few seconds and you have a very powerful platform :) regards, v
Re: [linux-audio-dev] Hartman Neuron
On Tue, Jun 03, 2003 at 10:30:52AM +0100, Steve Harris wrote: Agreed. There are a number of ways to solve this, but sadly they all require a significant ammount of effort, and there are always some importnat things to be done... A laso kinda like the UI melange effect you get on VST systems, though some of hte UIs are truely awful. Luckily the correlation between musical quality and visual quality isn't always that big :) Well, theres the chameleon (sp?), but that isn;t a card, so wont lett you accelerate just inner loops. Its very nice, and it's rack mountable, which is a big plus. It would be a nice thing but its hard for DSP card manufacturers to compete with CPU+mothboard guys in the price/performance stakes, because the volume is so low. Yeah, hence the phenomenal prices. I keep seeing hints that th next generation of motherboards might include some sort of DSP capability, and theres always graphics cards, which have pretty meaty DSP capabilities. That would be nice. They can throw out all the stupid tubes and put in DSPs instead. (who had the idea to put a tube onto a mainboard ???) + suspend to ram for a standby mode. Linux recoveres from S2R very quickly. nice :) haven't tried it yet, but will do. I hope the upcoming kernel release will be good to us, though I think Paul recently raised some issues which still had to be addressed ? If we need to start lobbying, now is certainly the time to get fixes in till 2.6 ... (of course nothing really big, but maybe there is small stuff which needs to be fixed too ?). Don't have much time now to test the 2.5.x series though :( regards, v
Re: [linux-audio-dev] LJ article response
On Fri, Apr 04, 2003 at 10:53:05AM -0500, Dave Phillips wrote: Greetings: Just a note to mention that the Karlsruhe report has had 3,871 reads so far, more than any other article listed except for the Ultimate Linux Box on-line project. Seems like maybe people are really interested in what you guys are up to ! :) Check that counter again after the /. effect ;) http://developers.slashdot.org/article.pl?sid=03/04/04/1340204mode=nestedtid=141tid=106 regards, v
Re: [linux-audio-dev] Lock Free Ringbuffer in C ?
On Thu, Apr 03, 2003 at 03:36:32PM +0200, [EMAIL PROTECTED] wrote: i remember i have read a statement about a lock free ringbuffer implemented in C somewhere. Can anybody remeber it ? I think it is in the Ardour sources ? I will try to hunt down the relevant post. regards, v
Re: [linux-audio-dev] Re: Advertising Linux Audio
On Fri, Mar 28, 2003 at 05:36:13PM +0900, Patrick Shirkey wrote: (cut) Apart from that IMO the amount of money spent is useful to know from a business POV. If 6 months of clicking can generate $450 for Google then we must be able to channel that more effectively into LAD projects. I guess you have a point. My initial thought is that setting up a fund which can be used for LAUs to make donations into would be viable based on this rate of income. Good idea. Are there any companies which have merchant facilities that would be interested in hosting/sponsoring this fund? We could set up an award system where the contributors vote for their most used apps and the money in the fund is distributed based on the votes. IMO we need merchant facilities to allow people to use their credit cards to make donations without the overhead which paypal charges. It would also be possible for people to make cash transfer donations if they don't have a credit card. Obviously the former is less hassle and probably more likely to generate income. Paypal charges something extra cause there are real costs involved :). I looked up some prices for online merchant facilities for the company I work for and they are not cheap, you have to pay a monthly fee and some percentage or forfait per transaction. You need a relatively high volume merchant site to go with. (economics of scale). Is Paypal that bad ? I contributed to Ardour through Paypal and in so far I know, it works. I wonder if Paul is happy with their service ? I am willing to do the web based work and host the portal for this if there is someone who can host the bank account. I have some ideas on how to do this efficiently. The technical (web-side) is usually not the problem here. The financial, transaction handling part is a problem though. best regards, Vincent
Re: [linux-audio-dev] Re: why is ...
and the rest ... I get this. Its pathetic. Not only that ... I have no idea how much longer I can keep working on Ardour right now because working on it has come close to exhausting my financial resources. Paul, could you tell me how I can support you financially ? Do you work through Paypal ? best regards, Vincent PS: silent supporters are lurking behind the curtains, silent, but supportive
Re: [linux-audio-dev] Re: why is no-one responding are you all just a bunch of *^%^%^ wits???
On Wed, Feb 12, 2003 at 12:33:24PM -0500, Ivica Bukvic wrote: Do I/we have at least your permission (if we do manage to compile out of CVS) to redistribute my/our compiled version? I think this is covered by section 6 in the GPL: http://www.gnu.org/copyleft/gpl.html 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. So you can distribute your compiled version, if you don't hold back the sources of course (terms and conditions of the GPL). It just boils down to the fact that people who get hold of a binary will find an email address in the about box and complain for any bugs. Personally, I'd respect the wish of the author not to redistribute the binary, till he is confident about it and at the point at which it is _possible_ to support the binary (its sufficiently stable). Yet, we are a free world. The legals are clear, morality is up to ourselves. regards, v
Re: [linux-audio-dev] Re: why is no-one responding are you all just a bunch of *^%^%^ wits???
On Wed, Feb 12, 2003 at 11:49:08AM -0500, Paul Davis wrote: (cut) jazz++ has been around for a long time, and is available as a binary. why isn't it widely loved and used? because it really isn't very good. i know that i tried to use it many times, and found it, well, frankly i found it completely awful. That was sadly my impression too. (cut) when ardour is in a state where i believe (rightly or wrongly) that a reasonably typical target user can sit down and just use it without encountering bugs when recording a typical 12-32 track piece, there will be binaries. I think that is a good policy. Hm, I see these emails get cross-posted all over alsa-dev and ardour-dev too :/ The last thing I want to say is that I hope we can make a mends to this bad vibe mostly based on false expectations, yet good intentions. The last thing is what counts. regards, vincent
Re: [linux-audio-dev] why is no-one responding are you all just a bunch of *^%^%^ wits???
I'm not a real coder either (so one might argue I shouldn't be on linux-audio-dev, but I'm just interested in the discussions), so I think I understand the root cause of your grief. I think if (if) the Ardour developers are _expecting_ quality feedback from normal users (not just programmers) at this stage, they should provide tarballs of the stable CVS snapshots they want to be tested. But maybe they want to wait for 1.0 before letting endusers test it? In that case, maybe you tried to use it too early in its development ? I think they honestly appreciate your effort to participate, there should be no doubt about that, but maybe Ardour is still changing too rapidly for you to be able to track it. I think only the developers of Ardour can clear out this question. best regards, Vincent
Re: [linux-audio-dev] LAD Meeting at ZKM Karlsruhe 14-16 March 2003
On Tue, Jan 28, 2003 at 04:42:35PM +0100, Pieter Palmers wrote: Anyone from Belgium planning to go? I'd like to attend this, maybe we could 'join forces'? (Vincent?) Yep, I was planning to :) I haven't figured out how to survive the weekend in terms of sleep and food, but the motivation is present ;) Maybe the organizers could comment on how to achieve good survival rates ? :) [or I should check up on the site again, maybe accomodation tips are online] v
Re: [linux-audio-dev] Route Stantons Final Scratch to internal sound cards?
On Sun, Jan 26, 2003 at 04:02:59PM +0100, Modnogg wrote: (cut) Do you think it's possible to route the USB sound cards to my internal sound cards? I could use the sound driver library from linux. But my problem is how to link the software to other soundcards? (cut) Here you can find out how to run FS on any Linux distro: http://www.bostonraves.org/story/2002/11/11/162146/33 Apparently FS needs devfs and gets its audio from both /dev/scratchamp/0 and /dev/scratchamp/1. I think if you can make devfs to point /dev/scratchamp/* to the device nodes of other soundcards, you can use these other soundcards instead of the ones provided by Stanton. That depends greatly of course as to what degree the USB hardware by Stanton is a normal audio device. I think there is also a pre-amp in there and possibly other undocumented stuff going on ? But you can always try of course :) v PS: I might try this in some two months [when I have the cash to spare ...]
Re: [linux-audio-dev] Route Stantons Final Scratch to internal sound cards?
On Mon, Jan 27, 2003 at 12:04:40AM +0100, Pieter Palmers wrote: (cut) What I think could be possible is using (writing a driver for) the scratchamp with OSS or ALSA drivers, as they seem to be USB soundcards by creative. Those will have standard chipsets. But that wasn't the question I guess... (cut) I think it should be possible to reverse engineer the system once you have the dubplates and work out their timecode. (cut) BTW: how is it possible that the scratchamp module works on a kernel version other that the one it was built on? According to the link above, the Final Scratch distro is a 2.4.18, but it should work with any kernel 2.4.17. I always thought that new kernel = recompile modules? or is this what they mean by 'versionned kernel'? Might be a stupid question, but I'm not that much of a linux expert. (cut) I think you have to disable explicit versioning in the kernel. That, or the module can say it can be run on any kernel 2.4.17, I'm no kernel module expert either :) v
Re: [linux-audio-dev] MMA membership (rambling reply)
On Thu, Jan 23, 2003 at 04:19:28PM +0100, Vincent Touquet wrote: Interesting reply :) I was going to write a boatload of stuff, but I can put it more concisely (I think I have this from the latest Linux Journal or some other magazine or online article). concisely: only the next paragraph should have been there ;) Linux and the opensource movement in general is a very disruptive technology, its an enabler. People want to depict it as a destructive evolution, but that's not the case. That's the main point (rest is extra rambling for free). v
Re: [linux-audio-dev] RE: MMA memebership [was XAP: Some thoughts on control ramping]
On Thu, Jan 23, 2003 at 11:30:45AM -0500, [EMAIL PROTECTED] wrote: IMO the *worst* possible scenario is that the commercial companies (many of whom are a one man show) decide that they want to join the MMA, while a sizeable group of others decide to persue a parallel effort. That gives us 2 standards, and nobody wins. (cut) True. I don't think anyone in his right mind wants fragmentation. I think the problem with VST for platforms like Linux was the restrictions on the distribution of the header files of the SDK ? That's definitely something that should be avoided. I think it was also Dave (or Paul?) who raised the issue that TDM plugins allow some protection against copying, so they would be unlikely to switch to an API or a 'paradigm' which has no provisions against 'warezing'. A little bit off-topic, I wonder if there is any open project looking into using the TCPA infrastructure that will be available in newer boards to allow eg. time limited use of plugins or copy protection, even in a free OS ? I think its also best to not underestimate the economics which are involved here. I think everyone should at least have the full ability to go for the implementation they want, which means no restrictions on open development, but also no restrictions for corporations who want to make money off it. Which leaves me only to say that I appreciate the open view that Ron is showing in this regard (I hope I may call you Ron) and I welcome his opinionated mails on this list as a fully qualified lurker ;). just my 2 Euro cents, v
[linux-audio-dev] OpenSynth Eko supports Linux ?
Check this out: - http://www.opnlabs.com/ - http://www.opnlabs.com/ekochart.php [comes with XP or LINUX !] Does anyone know more about this synth ? It really strikes me that you can choose between XP or Linux, its just great :) regards v
Re: [linux-audio-dev] XAP/NAMM reminder
On Tue, Jan 14, 2003 at 10:01:44PM -0500, Paul Davis wrote: (cut) also, for folks here who are not on ardour-dev, please critique this: http://www.op.net/~pbd/brochure.pdf Read it and the only thing I could come up with, was an extra hyphen, which is undecided in English anyway :) [twenty first - twenty-first] Also a minor nit: The text under the screenshot on the first page seems somewhat oddly aligned ? But for the rest, perfect, v
Re: [linux-audio-dev] Networking Linux audio folks (was Unified Audio Plugin Architecture (Meeting))
On Wed, Jan 08, 2003 at 04:46:19PM -0800, Josh Green wrote: (cut) I remember something similar being discussed on LAD a while back (but I think it was about networking of Linux Audio prefessionals for contracts and jobs, correct me if I'm wrong), perhaps this idea could be added to that same database.. Anyways.. Just rambling on. (cut) LAG - Linux Audio Group Makes me think of huge latency ;) v
Re: [linux-audio-dev] (fwd) Unified Audio Plugin Architecture
On Wed, Jan 08, 2003 at 05:12:47PM -0800, Mark Knecht wrote: [cut] The way I read Paul's note they are not restricted, therefore they are public. Wouldn't want to drive that far and find out differently. [cut] Not sure whether this fits in here, but I thought it might be interesting. I forwarded the message to someone I know at Access Music (makers of such synths as the Indigo :), who will be joining the meeting before he visits NAMM. He started out hacking on Linux some years ago, now uses Mac OS X too. He has a *huge* knowledge in audio programming and somewhat of a distaste for proprietary lock-ins (M$ anyone ?). He started ampfea, a meeting place for electronic artists, which could be of interest to you (http://www.ampfea.org). Anyway, just to say that there are going to be people who are very like minded there too. I think its a great opportunity for anyone who can go to get their voice heard. Valid technical points always get over, when other technical people are listening. Political speeches will be banned, as it should be :) I think the main topic is audio, a central plugin API and not politics or marketing. have fun, v
Re: [linux-audio-dev] Final Scratch, custom kernel?
Wow, please do :) I'm immensely interested. best regards vincent On Mon, Oct 07, 2002 at 05:34:59PM +0200, CK wrote: I read: How well does it work? Does it truly work just like a standard turntable setup would, or does it have an artificial feel or sound to it? dunno about final scratch but I have built a similar system using dubplates with 440hz rising saw, pd and alsaplayer. (also tested with my own pd stepsequencer and scratching video using gem) works like a charm once calibrated, I'll make this available as soon as I find time to clean it up and make the setup process a bit less painful. regards, x -- [EMAIL PROTECTED] Postmodernism is german romanticism with better http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)
Re: [linux-audio-dev] Evo (was: 'nix Rt sampler)
On Sat, Sep 07, 2002 at 02:01:24PM +0200, Peter Hanappe wrote: We're thinking of adding a .wav loader to iiwusynth. In that case you won't need to convert it to a soundfont before hand. I can't give you a date when this feature will be available, though. Nice :) I'll be looking forward to it. thanks, vincent
Re: [linux-audio-dev] Evo (was: 'nix Rt sampler)
On Thu, Sep 05, 2002 at 10:15:57AM -0700, Brian Redfern wrote: IIwusynth is really nice and performs well, its a soundfont software sampler, and swamii is a soundfont editor that uses it for its engine. I get good realtime playback on my laptop and have access to tons of soundfonts on cdrom. Is it possible to convert a 'normal' (.wav / .aiff) sample to a SoundFont ? regards v
Re: [linux-audio-dev] Evo (was: 'nix Rt sampler)
On Thu, Sep 05, 2002 at 10:39:07AM -0700, Brian Redfern wrote: Soundfonts are based on normal samples, they just give you control over envelope paramters so you can use midi to control extra parameters, like use velocity to alter cut off. I'm working on my own personal library right now with various drum machnines and acousti instrument samples. :) Strange how names can give totally different impressions. It looks very useful. I must give it a try [use my controller box to alter parameters of the soundfonts, sounds like fun] I'll google for some install iiwusynth. Thanks for the info regards vincent
[linux-audio-dev] managing installations from source [CVS]
Hi, I ask this question here because I know a lot of you manage to install lots of applications from a fresh cvs snaphot without troubles (I think ;). How do you manage these from-source installs ? Are there people who use stow ? [cfr. http://www.gnu.org/software/stow/stow.html] Or does make install / make uninstall usually does a good task of (un)installing the software ? I have installed software from sources this way before, most notably alsa eg. I just wonder if there are any tricks of the trade to be mastered. thanks in advance Vincent
Re: [linux-audio-dev] [ANN] Chameleon DSP engine
On Fri, Aug 16, 2002 at 11:18:54AM +0200, Ingo Oeser wrote: (cut) Price: We got them donated, but they cost about half a car, if you get them new, we have been told. That would be a showstopper for me :) 1000$ is one thing, but I cannot afford 2500$+ It seems interesting though. I'll let you know when I get a Chameleon, I could try to work with you to get Linux-DSP to interoperate with the beast. regards v
Re: [linux-audio-dev] What I think about reborn.
On Fri, Aug 16, 2002 at 12:31:22PM +0200, Tobias Ulbricht wrote: Rediculus! where has tolerance, hospitality and an unbiased attitude towards others gone that this list had so far? ACK. I have been upset by some messages on this list too. I didn't want to react as it seemed like *an utter waste of time*. Unfortunately that leaves these stupid flames as the only reactions about this mans work on the list, which is no mirror of the general feeling towards his work. At least I and more people with me respect his work. Instead of blaming anyone, lets rather invite the author into lad if he still wants and let that chapter be history. If lad has to chance to get hold of a coder, why do people scare him away? Politics :) I like Linus' attitude towards this: screw politics in coding ! :D Lets try to be friendly ok. He who is without sin can cast the first stone. Unfortunately I'm such a sinner I don't even have any stones which I would be even remotely allowed to throw ;) cheers, tobias, who is like you - not doing anyting at all... I mostly lurk too. Just give me some time, I'll get there. :) Don't let fscking politics scare you. Learn from the gurus, kill the trolls and chill... regards v
Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
On Fri, Aug 16, 2002 at 02:22:35PM -0400, Paul Davis wrote: (cut) 2) is cheap, the patch exists, and we should consider promoting it as widely as the low latency patches. (cut) Ok, let the lobbying begin :) v
Re: [linux-audio-dev] [ANN] Chameleon DSP engine
On Tue, Aug 13, 2002 at 09:25:45PM +0200, Ingo Oeser wrote: (cut) Ok, I grasp your intent, its a good idea. Letting a DSP idle is not the best idea, so if you can use it for specific computations, that would be nice. Could you tell me exactly what you would do with this board and how that would help me use this DSP for music purposes ? We would write drivers for exactly the 4 modes described above, so the DSP could actually just a kind of plugin to your sound architecture of choice. Doesn't the fact that the Chameleon sits in a rack defeat this purpose ? PS: If you have more questions, don't hesistate to ask. I was just wondering what the price would be of the TI DSP processor board you used for the paper and if it would be remotely useful for audio processing. regards vincent
Re: [linux-audio-dev] [ANN] Chameleon DSP engine
On Tue, Aug 13, 2002 at 12:14:12PM +0100, Steve Harris wrote: (cut) The Chameleon isn't quite as convienent as it can't be applied in-line as part of a LADSPA/JACK chain. (cut) Wait for the digital IO in the next version :) Sure this is possible now too, but with extra D/A - A/D - Chameleon - D/A - A/D overhead... regards v
Re: [linux-audio-dev] [ANN] Chameleon DSP engine
On Tue, Aug 13, 2002 at 09:44:23AM +0200, Ingo Oeser wrote: Give our project a sample board, a data sheet and some time then we'll integrate it into our Linux-DSP-Project. You can find it under http://osg.informatik.tu-chemnitz.de/forschung/linux+dsp/index.html I'm not sure I fully grasp the intent of the project ... From the site: Application Scenarios DSPs in computer systems could be used for many purposes. One example is the acceleration of audio applications, e.g. the ALSA project. Another one are DSP-based software plugins for applications like GIMP. Third, DSPs offer vast computing power, so why not use a DSP for encryption of your IPsec VPN or crypto filesystem? I only want to use the Chameleon for DSP, really. Or do you mean you want to run a Linux kernel on the controller ? That would make some sense to me. But I wouldn't waste any DSP power on IPSec :) This infrastructure is made for that kind of applications and is awaiting it's use. Hm, its made for audio, at least for me :) And it is fully GPL. Thats nice. Could you tell me exactly what you would do with this board and how that would help me use this DSP for music purposes ? Not that I have the money to sponsor you, but you might just be able to try and convince the Soundart people to sponsor you (though its unlikely). regards vincent
Re: [linux-audio-dev] [ANN] Chameleon DSP engine
On Tue, Aug 13, 2002 at 09:44:23AM +0200, Ingo Oeser wrote: (cut) Give our project a sample board, a data sheet and some time then we'll integrate it into our Linux-DSP-Project. (cut) I read your paper and it interests me to say the least. The thing that is driving me to use the Chameleon is its easy to use API and the presence of knobs :) I could live without the knobs certainly, but not without a good API. Are there any TMS320C44 based board which are designed for audio (so good IO neede) available for less than 600$ ? What chance is there of me using the API in your project for exactly the same things as the Chameleon SDK is for ? Note that there is *a lot* of stuff which is taken care of by the Chameleon itself. The controller takes care of midi eg. I could use the alsa sequencer of course for the midi part. best regards vincent
[linux-audio-dev] [ANN] Chameleon DSP engine
http://www.soundart-hot.com/developers1.htm Remembering past threads, i know some of you have wanted to create a fully programmable DSP engine. Well, it has been done. Separate DSP controller, fully programmable display and IO. SDK and everything needed to program the beast are given away for Free ! At 600 Euro, there is a lot to be said for this Chameleon :) The SDK accomodates for multiple DSPs and even more IO than the current Chameleon, so its a sign of things to come :) I want one of these... best regards vincent
Re: [linux-audio-dev] [ANN] Chameleon DSP engine
On Mon, Aug 12, 2002 at 03:52:47PM +0100, Steve Harris wrote: Sadly it can't be programmed form linux (or couldn't last time I checked). Well, it uses a standard motorola dsp. I'm sure you can find a suitable compiler. Then you only need an editor and a way to send your data over in sysex. Shouldn't be hard :) regards v
Re: [linux-audio-dev] [ANN] Chameleon DSP engine
On Mon, Aug 12, 2002 at 05:26:50PM +0200, Tim Goetze wrote: (cut) Anyway, that thing looks usable. (cut) Very much so :) v
Re: [linux-audio-dev] [ANN] Chameleon DSP engine
On Mon, Aug 12, 2002 at 06:44:38PM +0200, Sebastien Metrot wrote: Mine does :-) , but have you listened to the sample soundclips (the opera singer)? It sounds so bad I wonder how they expect to sell anything with such material. Here it sounds good actually :) Also expect loss of quality due to the mp3 compression ... v
Re: [linux-audio-dev] CDDA interface - How to convert to float? Any library?
On Sat, Aug 10, 2002 at 02:07:20PM -0500, Mark Rages wrote: (cut) Well, I've never had any problems with cdparanoia, but the web page is full of Real Soon Now hype for Paranoia IV which will have a library and API for others to use. (cut) :) I guess they forgot then I guess the Xiph boys have other fish to fry. Yep, keeping track of Ogg, Tarkin and the new On3 video stuff should keep them busy ;) v
Re: [linux-audio-dev] analysis/resynthesis environment? -- and scientific-audio-list?
On Thu, Aug 08, 2002 at 03:39:11PM -0700, Andrew W. Schmeder wrote: (cut) features, e.g. cell arrays, better object support, java integration. However these days I recommend Python with Numeric/Scientific/SciPy extensions over Octave (and over Matlab). In addition to Python's unquestionably superior language support and library integration, Numeric offers some extra features such as typed matrices. (IIRC in Matlab/Octave all matrices are of type double). Out of curiosity: do you use some kind of editor with that, or is it just vi/emacs and a shell ? :) regards vincent
Re: [linux-audio-dev] App intercomunication issues, some views.
On Thu, Jul 25, 2002 at 12:24:56AM +0100, Phil Kerr wrote: (cut) It's a very simple protocol to use and it seems to work fine on a LAN. It can also handle the saving and restoring of app config data by broadcasting it's config as XML. (cut) Just thinking out lout :) If you use this on the 127.x.x.x subnets, you have a local MIDI interconnection, at least if your apss are DMIDI clients, right ? regards vincent PS: basicly the same alsa seq can do too, or am i wrong ...
Re: [linux-audio-dev] [OT] Some good news for once
Maybe we should check out if they are seeking to actively sponsore software audio projects ;) vincent
Re: [linux-audio-dev] App metadata intercomunication protocol..
On Tue, Jul 23, 2002 at 02:30:22AM -0300, Juan Linietsky wrote: ok, but the question is, what for? What else do you need other than start/stop/seek ? doesnt midi proovide that already? then why something else? Also using midi you make sure that what you do is synced to external devices... You can use a protocol which hasn't the limitations of midi (7 bit CC data :() and trunk it on the ends that need midi (filter the more dynamic range to the coarser range). Of course this brings issues about the different dynamic ranges used and I think you'll hear it. I just don't think there is any good reason to use the restrictions imposed by midi when you stay inside your computer (it is not as if you need to be able to pass all your data on a 33600 baud cable, is it ?) regards vini
Re: [linux-audio-dev] App metadata intercomunication protocol..
On Tue, Jul 23, 2002 at 08:43:36AM +0200, n++k wrote: Why not use an SQL database for storing session/project metadata? (configuration and such) We have the benefit of having a few quite stable free software SQL databases. (mysql, postgresql, sapdb) so requiring one wouldn't be too much to ask.. The persistence protocol (sql) is already there and tested, the administration is as easy as with plain text files, and (I think) the schema is a lot easier to design than that of a set of interrelated XML files. (hierarchical databases?) (cut) Well you are entering the souvereign entity of a program and asking them to change the format they are very used to and dump it into a database ? To me that sounds like making a big soup of a nice modular system again. Let the programs keep their own settings in their own way, just tell them when to save them. Also: are you going to impose people to install a RDB just because they want their states saved ? Then comes the issue: which RDB, you need choice, so you have to provide a database abstraction layer. Its not worth it in my eyes ... regards vini
Re: [linux-audio-dev] App metadata intercomunication protocol..
On Tue, Jul 23, 2002 at 04:56:06AM -0300, Juan Linietsky wrote: And also you cant do the neat thing of asking all your apps to save all their data to a directory so you can create a targzip with the project :) That point is irrelevant, you can extract everything from the database and tar gzip. vini
Re: [linux-audio-dev] App intercomunication issues, some views.
On Tue, Jul 23, 2002 at 12:07:43AM -0400, Paul Winkler wrote: Does this help? http://developer.gnome.org/arch/sm/extension.html (cut) _GSM_Priority (cut) So their would be a dependency on gnome-session-manager (and what else ?) regards vini
Re: [linux-audio-dev] App intercomunication issues, some views.
On Tue, Jul 23, 2002 at 02:09:32PM +0100, Steve Harris wrote: (cut) Yes, It's terrible. I remeber hearing from someone a year or so ago, who was incharge of cleaning up the source. I never heard any more though. Well he had to clean it up, I guess he just escaped and ran away ;) vini
Re: [linux-audio-dev] App intercomunication issues, some views.
On Tue, Jul 23, 2002 at 07:38:25PM +0200, Martijn Sipkema wrote: (cut) Using UST would also enable syncing to video or some other media stream without it all residing in the same API. (cut) That would certainly make me very happy :) vini
Re: [linux-audio-dev] App metadata intercomunication protocol..
On Tue, Jul 23, 2002 at 02:00:15PM -0300, Juan Linietsky wrote: (cut) Yes, I agree that midi sucks. I'm wondering why dont we have a newer protocol by now, but we dont. So there's nothing else than having to stick to that archaic crap :) (cut) What about Yamaha's mLan ? I thought that was some kind of midi over firewire, but maybe they didn't grab it as an opportunity to improve on midi ... regards vincent
Re: [linux-audio-dev] (no subject)
On Tue, Jul 23, 2002 at 01:14:18PM -0500, Arthur Peters wrote: (cut) I think there might be problems with option 1 when the apps are running on different machines (as was mensioned earlier). Maybe a hybrid would work: provide an API for each app to pass it's data to the project server. This data could be anything, XML, binary of somesort, whatever. The project server could then store that data any way it wanted, the simplest being a group of files in a directory. The apps wouldn't have to change their data format, only replace their file IO with this API, and we would have some choice of backends. (cut) I think this is the only reasonable approach. Have some interface in each program to set and retrieve state information. Programs who implement the interface benifit from the added advantage a user has of using that program with some sort of state daemon. I would vote for this solution if I could :) vini
Re: [linux-audio-dev] App metadata intercomunication protocol..
Yamaha has a large NDA tradition, making lots of things impossible. As another example: the filesystem format of their A series samples storage. It would be so nice if you could mount these disks in Linux too, but yammy refuses without an NDA ... Ask them the question though :) They have to come up with a clean answer. regards vincent
Re: [linux-audio-dev] App intercomunication issues, some views.
On Mon, Jul 22, 2002 at 04:44:00PM -0400, Paul Winkler wrote: On Mon, Jul 22, 2002 at 05:18:46PM -0300, Juan Linietsky wrote: I think this can be solved by developing a metadata protocol between apps, so the can intercommunicate status and other things, and having a master app that manages projects and things like that, by just retrieving/storing status in the other apps. Yes yes yes yes. We *need* something like this. Hm, yes I can see the point of this. I was thinking: isn't it enough that programs can store their own state ? Obviously what is lacking is the relationship between the saved states of _different_ programs, who form a semantic entity, called a 'project' or sth. :) Cut the expensive words, but we sure have a need here i guess which transcends the individual app level ... [couldn't find a cheap substitute for transcends ;)] regards vini
Re: [linux-audio-dev] LADSPA Defaults via RDF
On Fri, Jul 19, 2002 at 05:11:06AM +0200, Torben Hohn wrote: BTW: I consider XML to be bloat. At least it is portable bloat ;) No, seriously, xml has advantages over plain ascii, when you consider xslt, rdf, ... etc etc regards vini
Re: [linux-audio-dev] LADPSA v1.1 SDK Provisional Release
On Fri, Jul 12, 2002 at 02:40:36AM +0300, Kai Vehmanen wrote: On Thu, 11 Jul 2002, Paul Winkler wrote: Without breaking binary compatibility, Can someone explain to me why that's important at this point in time? Well, it's not _that_ important, but there are a few good reasons... 1) The LADSPA API was not designed for ABI changes (most notably the interface version is not exported by plugins). This means that old plugins that you didn't remember to delete/recompile can cause segfaults in hosts. And unfortunately when you get a seg.fault, you probably manage to try at least n+1 other things, send bug reports, drive the host developers insane, etc, etc before you notice that you had an old pluing lying around. ;) So, one vote for adding the version to the API ? Incompatible changes should bounce that version number. Maybe that version number needn't be the same as the version of the entire SDK, as it would be only used to avoid these segfaults / ... due to binary incompatibility. 2) Marketing. Only way to make developers believe that your ABI is truly stable and will not change all the time is to keep it stable. Just saying that after this change there won't be any modifications every six months just doesn't cut it. Whether this is a problem for LADSPA is another issue. You're right, on the other hand, if we still want to do big changes now is the moment. Don't overrate the acceptance of LADSPA outside of the people who read this list, and they are participating in the process anyway. Doing It Right should prevail imho. Anyway, isn't LADSPA 1.x a development version, with LADSPA 2.x being a stable series ? Or is such a scheme stupid for the LADSPA SDK ? regards vincent
Re: [linux-audio-dev] 1000HZ ticks for x86 in the 2.5-tree
Yum, can't wait till 2.6 hits the streets :) vincent RTC is still more accurate, but on the other hand, you don't need root privileges to take advantage of the 1kHz ticks! -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Poll about linux music audio app usability
On Sat, Jun 22, 2002 at 07:13:43AM +0200, David Olofson wrote: Well, I'll try to get started before you get bored... ;-) ;-) Well, I read all the stuff you wrote and I agree. Especially the idea of logical vertices and lines is a good one and most of the time, though not always beautiful ideas can lead to nice code. (didn't say always :) I don't have more time to elaborate as of now (exams :), they will be finished the 26nd though). I'll make sure I'll get back to you about this :) regards Vincent
Re: [linux-audio-dev] the gibson patent
On Sat, Jun 22, 2002 at 02:39:18PM +0100, Bob Ham wrote: (cut) And by the by, what on earth is going on with this? What's going on to do something about this situation? It seems many people are aware of the USPTO's idiocy, yet they are still allowed to carry on being idiots. Why are people letting them? Cause they are even more ignorant ? :( That's why besides codes the Free Software Movement (and Open Source, so I'm politically correct :) needs good advocates who can explain the perils of such idiocy. I like the idea of a group of lawyers in Germany who are specialised in the GPL and related concepts, cause we need some empowerment in that department too. Only empowerment in the coding department will lead us into the abyss IMHO. vincent
Re: [linux-audio-dev] IRC
Nope, not yet, I'm on my way though to join you :) Not everyone likes irc though, and that's ok :) regards Vini On Sat, Jun 22, 2002 at 02:59:30PM +0100, Bob Ham wrote: I've been looking around for IRC channels populated by lad people but to no avail. Have I missed a place, or is there none? Assuming the latter is the case, I've taken the liberty of registering #lad on irc.openprojects.net. Bob -- Bob Ham: [EMAIL PROTECTED] http://pkl.net/~node/ My music: http://mp3.com/obelisk_uk GNU Hurd: http://hurd.gnu.org/
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wed, Jun 19, 2002 at 11:28:14PM +0200, David Olofson wrote: That said, the XMMS/WinAmp model *is* in fact of the first kind I mention above; GUIs with custom graphics. A skin for such an application is basically just a set of images that replace the original custom graphics. It's like replacing the graphics of a game; drawing a bunch of images for each object, whereas normal (GTK+ style themes consist of generic textures and images used by all widgets. Thats exactly what I'm aiming at :) I didn't mean themeability in the themes.org sense of the word. Just an abstraction of functionality: - sliderbars - rotational knobs from 1-10 - rotational knobs without beginning and end ... Just how far you can go, I don't know. Someone mentioned that the xmms coding style was to be avoided. I was thinking about some callback model: you provide the callback to redraw your knob after you changed the parameters. This way you could plug the functionality of the knobs etc. in your program, just by providing the graphics and using the toolkit you want... Obviously I must have missed all the difficult parts ;) regards Vincent
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wed, Jun 19, 2002 at 11:20:20PM +0200, David Olofson wrote: (cut) of programming. It looks like it would be a fast and easy hack, as everything's so visually obvious and intuitive, but that's just an illusion... I think I agree, though my GUI programming experience is quite nonexistant :) (or: :() I think an effort should be undertaken to get a group of people to write these damn things :) Yes, but how about motivation, and getting the right people to do their best? I'm motivated :) Now only to find time and someone who can tell the bad code from the good. I fear model-view-controller separation doesn't apply here, as we are entirely in the view realm. I don't agree there. The major difference is probably that there's much more logic inside the GUI part - not that there all of a sudden is a good reason to mix things that don't belong together. :-) Actually, I wrote this to stir some reaction. I don't agree with it myself. I believe there is stuff that can be abstracted about this GUI thing. In fact, the separation between engine and UI is an absolute *requirement* for real time audio/MIDI applications, as you simply cannot make them work reliably if there are too many places where the UI may interfere with the timing of the engine. True, writing anything inside the GUI event loop is wrong (at least when you want low latency). (cut) The design I have in mind could be implemented inside any toolkit that provides access to the underlying drawing toolkit - or directly on top of the rendering target or API (SDL, X, fbdev, svgalib, GDI, DirectDraw, Direct3D/Graphics, OpenGL...), for that matter. Lets put this on the table then :) Could you draw a class diagram or something to show us your model ? The only truly required feature is a way of rendering rectangular images into windows. All higher level stuff is just to allow certain targets to use hardware acceleration for specific features - ie performance hacks. (That is, stuff that optimization freaks can play around with after the toolkit is implemented and working. :-) Well, we could just skip this at first as premature optimization is the root of all evil :) Either way, the major issue here is not *how* we should go about getting proper GUIs for more and larger Linux music application, but how we should get anyone to do any serious GUI hacking *at all*. There are a few exceptions, but the fact remains: The LAD community consists mostly of *audio* hackers. (Makes sense, sorta'... ;-) :) you have a point. We have here a large based of knowledgeable coders though and a potential userbase. So involving LAD in this seems sensible enough. And hey, I'm interested. I hang around here, for the same reason as I hang around on other lists, to learn. I like to read the code. And I like to make code, even though I need some project that will tickle my mind. Such as this :) regards Vincent
Re: [linux-audio-dev] Poll about linux music audio app usability
Cool, they must be lucky I didn't think of patenting it when I just thought of it now ;) vincent On Fri, Jun 21, 2002 at 11:05:10AM -0400, Paul Davis wrote: Sounds quite a lot like the way almost every GUI toolkit I've looked at works (see XForms, GTK+, Qt, Gtkmm for examples) :) --p
Re: [linux-audio-dev] Poll about linux music audio app usability
On Fri, Jun 21, 2002 at 12:36:49PM -0700, STEFFL, ERIK *Internet* (SBCSI) wrote: freeamp allows you to specify bitmaps of arbitrary size/shape for gui elements and place them where you want (there's an xml file that specifies the GUI), you can omit the GUI elements you don't need/want in particular skin etc. - that makes it possible to really make a difference - e.g. you can create a skin that would make it easy to dock/swallow it in some launch pad/task bar/whatever (e.g. small play/stop and volume controls) or you can create a big full screen art work that also serves as mp3 player etc... That's the functionality I would be aiming at. Maybe I should have a look at their code :) regards vincent
Re: [linux-audio-dev] Poll about linux music audio app usability
Continuing in the thinking out loud department, so I don't have to study ;): Seems a waste to hardcode all the GUI stuff though. How do they get about theming their controls in Xmms / mplayer ... ? Slider bars get different sizes and sometimes shapes in such programs, yet they retain their basic functionality. Guess we should try to do something similar, instead of hardcoding the actual appearance of a knob / slider. regards Vincent
Re: [linux-audio-dev] Poll about linux music audio app usability
On Wed, Jun 12, 2002 at 11:19:56AM +0100, nick wrote: (cut) Theyre not *that* difficult really, it's just the initial learning which already (this is from my experience writing amSynth http://amsynthe.sf.net). The problem is that everyone likes a different toolkit.. for example, I used GTK--, and so I wasnt able to just use an existing GTK bit of code, it was easier to write one from scratch in GTK--.. Hm, nice project by the way :) But yes, a library of these would be damn sweet. in the style of gtkext (extra widgets for gtk) we could make one, but then the problem is the user must have this extra library installed, and us developers hate extra dependencies to worry about (at least *i* do). Well, at least they are not forced to use them. They are Free to do what they want :-) It's just that such a thing is not available yet IMHO, but it should be otherwise I think lots of good audio developers start wasting their time on the same thing: writing (sometimes ugly) widgets (hey its not ok to expect audio programmers to be masters in GUI too :) Paul: didn't you write some sort of a GUI widget for Ardour ? What do you think about this ? Perhaps making a static library would be best.. Or maybe just writing them and giving out the code so others can incorporate it and/or modify it for thier needs? Yup, code code code :) Once the code is there the rest is easy I think. So we are stuck basicly to implement these things for *all* the major toolkits, GTK, QT, etc. Now theres the problem ;-) Well, we can start with one :) Rome wasn't built in a day ? regards Vincent
Re: [linux-audio-dev] Poll about linux music audio app usability
Keep this idea on hold for a while (but keep on discussing :). I'm going offlist for a while (won't read it till end of June), cause exames are up and I always find a good excuse inhere not to study ;) so see you later ! regards Vini
Re: [linux-audio-dev] Poll about linux music audio app usability
My exams are over in just over a week, and I intend on getting my pc running linux full time with alsa and stuff. I really want to help do /something/ in the linux sound area - at the moment I'm very definetly on the needing help stage. Great, more power to you !! If you need help, post on the lists, we are here. Not all people must be coders though :) I really agree with Maddog Hall when he says that in the Free Software Community everyone is important. If you don't know how ALSA works, but you maintain a wiki, more power to you. If you get frustrated with obsolete or not existing documentation and you write some, the hours you have put in it will be saved many more times. Is there an open source careers advisor somewhere that can give you a questionnaire, find out what you're capable of, and find something for you to do? Even if it's designing chromy skins for audio apps or writing a complete dumb-ass's (TM) guide on alsa and jack for beginners? Anything :) I like the way mozilla says 'Hey, you don't need to know nothing to join in, just do this, testcase that, submit bugs, etc.' Not a bad idea. Something like a todo list. Or where people can vote for 'janitor tasks', though I find this term a bit on the negative side ... (cut) Sorry... I'm sure that isn't the case, but it feels that way to me sometimes - :) Spill your guts. We are human, we make mistaks, we want to learn from anyone who has a grudge and can explain it in a sensible way even when coding is our second nature (well not me, but consider Paul ;) and we are ninja Uebergeeks. But yeah, could something like agnula or the lad site have a 'so you want to help but you can't compile alsa' or 'things for people with little skill but enthusiasm'? If you have an itch, scratch it. Yours, intimidated Don't be, consider yourself welcome ! Minor point: this is a list for developers, maybe your points are more on topic on linux-audio-user. This is not intended to scare you off :) Just the bare facts of Internet life. respect, Vincent
Re: [linux-audio-dev] Broadcast 2000 successor, Cinelerra available.
There is some bad news lurking too, let's hope this posting: http://sourceforge.net/forum/forum.php?thread_id=687636forum_id=164360 doesn't reflect the authors real intentions for the future ... :( regards Vincent On Tue, Jun 11, 2002 at 04:02:16PM +0100, Phil Kerr wrote: Hi List, Slashdot has a story about Cinelerra, the successor to Broadcast 2000, being available. http://heroinewarrior.com/cinelerra.php3 -P
Re: [linux-audio-dev] Re: [linux-audio-user] Audio routing issues for linux..
On Mon, Jun 10, 2002 at 09:30:36AM -0400, Paul Davis wrote: (cut) Read the archives. We've been through this before. I'm not going through it again. (cut) ACK ! Every once in a while people bring up the same questions people in this list thought long and hard about and solved. Before you start asking the same questions over again, read the archives and then come back. If you still have any valid points after that, I'm sure all of us will listen (even me, though I currently lack the time to do anything with it :() best regards Vincent
Re: [linux-audio-dev] Audio routing issues for linux..
(cut) I'm afraid i didnt make myself clear. I tried to expain this in previous mails, but I think i'm failing so far. I perfectly understand what JACK is, but as I said before, it's primarily meant for low latency stuff. So my proposal consisted in two things. 1-The first one is to proovide transparent audio routing using _existing apis_, this does work since most apps do proovide standard buffersizes (100/200) ms latency. (As fun as this sounds, many VST/DXi plugins work at these rates using the windows kernel streaming hehe :). How would you provide an existing API ?! So, you have this existing API, and then ? You go and change the internals ?? Do you want to change the semantics of an existing API or what ? What do you do with existing code that uses this API and relies on its semantics ? Unless you can specify *in code* what you mean by this, I qualify this idea as a load of male cow excrement. Sorry for being harsh, I will happily clean up after myself if you get to prove your point. This is not a call for a flame war. Sometimes being loud and using an angry tone has much more potential of bringing the message. 2-I also DO aknowledge a _new_ API for doing this low latency, JACK works perfect for this. I've never said it doesnt. When I said that JACK should become part of Alsa-lib i've meant that jack could go in a lower layer than it currently goes (maybe a driver level or something?) so it can capture and automatically jackify the data from existing apps that use the native api (alsa/oss emulation). The stream doesnt need to go low latency (and from what I know JACK should support normal latency apps fine) but you can still route existing apps and share the the device. How realistic do you think this approach is? What is the point in a lower layer ? There is clearly some lower layer fallacy. Just like people go ooh when you put something inside the kernel, instead of in userspace. There is *no point* in doing stuff lowlevel if you can do it highlevel, with more comprehensive code (and less chance to fsck up). Ok, I'm wishing to give you some credit here. I think you have some point I do not get. Suppose I give you a fully working API with the implementation of some form. What do you want to do with it. What do you mean by pushing it to a lower layer ?? Also note that this is Linux Audio _Dev_ I really look forward to hearing valid points from a developers point of view from what you have been suggesting. best regards, Vincent
Re: [linux-audio-dev] Audio routing issues for linux..
On Mon, Jun 10, 2002 at 06:09:01PM -0300, Juan Linietsky wrote: (cut) I think Kai Vehmanen did a much better job explaining this than myself, since I dont know the internals of alsalib. I'll just repost what he said: (cut) Ok :) If you want what Kai and Taybin are referring to, its doable, it just needs a developer ;) For a while I was fearing you were wanting something else entirely. regards and sorry for the misunderstanding Vincent
Re: [linux-audio-dev] Low latency and X11 Direct Rendering
Do you know if these patches will make it into the mainline kernel ? I don't know what objections there could be to a conditional_reschedule() ? regards Vincent On Sun, Jun 09, 2002 at 11:00:53PM +0300, Jussi Laako wrote: Yes, I have made some lowlatency additions to Matrox and ATI drivers. At least latencies caused by my ATI Radeon dropped from ~100 ms to 1 ms. The -ll version contains full lowlatency + lowlatency DRM. See http://uworld.dyndns.org/projects/linux/ - Jussi Laako
Re: [linux-audio-dev] [ANN] A novel approach to real-time free software
On Sat, Jun 08, 2002 at 01:11:10AM +0200, David Olofson wrote: (cut) From the application POV, both approaches give the same result: Two worlds with different schedulers and services - and unfortunately, different drivers. That is, if you want real time I/O, you still have to port Linux drivers to RTAI/ADEOS, just like you have to do with the current RTAI, or RTL. True, but at least it will be real realtime, something that cannot be achieved using any lowlatency patch. Its great that we will be able to run Linux and RTAI side to side :) But, you're right, the road is long. At least there is a road ;) best regards vincent
[linux-audio-dev] [ANN] A novel approach to real-time free software
I took the freedom to announce this here :) I think it is a _great_ step forward for low latency, besides the low latency and interruptible kernel patches. Announcement: http://www.opersys.com/press/prelease-adeos-020603.html LKML thread: http://marc.theaimsgroup.com/?t=10230935972r=1w=2 Best regards Vincent PS: Hm, long time no see :)
[linux-audio-dev] [OT] test - please ignore
[OT] test - please ignore
