[linux-audio-dev] Does anyone have a working example of Supercollider and SCUM GUI where slider or a button does real-time update on the synth
Greetings all,
I guess title says it all. I do have working examples (i.e. the sequencer
example from the LAD 2004) that make new instances of synths but none of them
actually do real-time updates to existing instances.
At any rate I would greatly appreciate your help in this matter.
This is as far as I got and cannot figure it out beyond this point (my brain
is pretty darn fried :-):
s = Server.local.boot;
SynthDef(onetwoonetwo,{ arg out=0, freq;
w = SCUMWindow.new;
w.title = Slider example;
w.initialSize = Size(20, 300);
c = SCUMVBox( w );
v = SCUMSlider(c, { |v|
v.expand = 1;
v.fill = 1;
v.bgColor = Color.white;
v.fgColor = Color.black;
v.action = {
freq = v.value * 100;
};
v.doAction;
});
w.show;
Out.ar(out,
SinOsc.ar(freq + 400, 0, 0.5)
)
}).play;
What I am simply trying to do is to affect the frequency of the sinetone by
moving the slider, yet nothing changes when I move the slider.
Any help would be greatly appreciated!
Best wishes,
Ico
RE: [linux-audio-dev] Software with source code?
RTMix is (although being a fringe audio-related app) also open source. ;-) Description: Interactive Multimedia Art Script-base Performance Interface Ivica Ico Bukvic, composer multimedia sculptor http://meowing.ccm.uc.edu/~ico -Original Message- From: [EMAIL PROTECTED] [mailto:linux-audio-dev- [EMAIL PROTECTED] On Behalf Of Juhana Sadeharju Sent: Monday, February 02, 2004 2:53 PM To: [EMAIL PROTECTED]; linux-audio- [EMAIL PROTECTED] Subject: [linux-audio-dev] Software with source code? Hello. I have partially lost the track on the latest audio and graphics development. Even I'm on 50+ mailing lists, the whole picture is blurry. So, I'm making a list of software which comes with source code. The list is intended more to developers who are looking for example codes, library codes, and projects to join. An unfinished list follows. The list format is simple: name and description. That is because one must be able to read the list through line-by-line without getting bored to details. Maybe later I will fill in the details: what re-usable gizmos the software have (filters, drawing algorithms, etc). Regards, Juhana Audio and graphics applications === with source code for developers Audio - ac3filter AC3 decoder Alsa audio device drivers AlsaModularSynth (AMS) modular synth AlsaPlayer Anthem multitrack sequencer Aqsis Renderman renderer Ardour multitrack editor (and sequencer?) Audacity multitrack editor Audiality audiofile awesfx bacterium Brahms cdparanoia Ceciliagraphical front end for Csound Csound modular synth Ecasound FluidSynth SoundFont synth gAlan modular synth gdam Glame gmorganrhythm station, a pattern sequencer gmurf Gnomoradio a peer-to-peer music playing system Gramofile HorgandFM synth Hydrogen JACK JACK-Rack Jamin mastering tool Jazz jMax libsndfile mffmtimescale MusE multitrack audio and MIDI sequencer NoteEdit score editor OpenAL library for managing 3D spatialized audio devices OpenMusic PortAudio PureData (PD) Q/Q-Audio/Q-Midi Rezound Rosegarden multitrack audio and MIDI sequencer seq24 pattern sequencer solfege sooperlooper SoundFontCombi (SFC) MIDI router Specimen sampling synth SpiralLoop SpiralSynthModular (SSM) modular synth Supercollider Swami Sweep audio editor swh-pluginseffect plugin collection tapiir TerminatorX TimeMachine timidity sampling synth with SoundFont support TSE3 sequencer engine (used by Anthem) ZynAddSubFXanalog modelling synth CheeseTracker? LilyPond? Multitrack? Skale? SoundTracker? Ptolemy? Graphics Ayam 3D modeller Aztec Blender CinePaint ClanLib 3D game library Coin 3D graphics library with Open Inventor API Crystal Space 3D game library dia Dore DRI Effectv ewave 3D modeller FOX toolkit for developing GUIs, with OpenGL widgets Freeman FreeType font rendering library GIMP Glade glaraocr Glide graphics library for 3Dfx Voodoo based cards gman gmone GNetLibrary GNUPlot scientific plotting gocr (jocr) Gozer text rendering library Imlib Impress imtools Innovation3D 3D modeller jpegsrc K3D 3D modeller kpovmodeler libart LibGLEOpenGL tubing and extrusion library LibGNetwork libgnomecanvas libpng LibSolid Mesa MeshIOlibrary for loading 3D model files, 3DS format Nebuladevice MindsEye Moonlight Mops (ayam?) Ogre OpenEXR Open Inventor 3D graphics library OpenRM Open Scene Graph OpenSG Pango text rendering library Panorama Pixelize pixelizes an image using other images as pixels Pixie PLIB PLplotscientific plotting POV-Ray Prettypoly qcad Radiance Renderpark Rise SDL SGL SIPP polygon renderer Sketch smpeg Sodipodi SuperZoom tgif Threedom (3dom?) 3D modeller tiff UGS3D Vertex3D modeller Vreng networked virtual 3D world engine VR Juggler VTK 3D visualization library, OpenGL based xcircuit circuit schematics drawing program xfig XFree86 Xine video player Xite xpdf XSane Matterial? Khoros? gSculpt? == end ==
[linux-audio-dev] ANN: RTMix 0.76 released
Greetings all! It's my pleasure to announce immediate availability of RTMix version 0.76. RTMix is an interactive multimedia art performance, composition, and coaching interface capable of triggering various DSP applications and/or processes concurrently, as well as offering a tight coordination between computer(s) and live performers. It can also trigger real-time events utilizing MIDI and OSC protocols, and can be in theory networked from a single client with up to 1000 other RTMix clients (personally neither have I had the opportunity to try this and besides the network latency would probably get the best of it anyways). For more info on what it is, what it does, and how it does it, please see the online docs: http://meowing.ccm.uc.edu/~ico/RTMix-doc/ Changelog: *RTMix is now part of the AGNULA project! *In order to comply with the AGNULA inclusion requirements, the install is now completely modular. Please use ./configure --prefix=preferred-path to install all the data files to the custom location. Binary is stored in /preferred-path/bin directory, so in the case your path happens to be exotic, please make sure to use --bindir=path-to-bin-directory for custom binary directory placement. RTMix has so far been featured at ICMC 2002 conference (Sweden), SEAMUS 2003 conference (US), in the Organised Sound magazine (December 2002), and has been used in several of my works whose recordings are available on my website. If you happened to use RTMix in your work, I would love to hear in what ways you got to utilize its features, as well as how can I make the application better. Thanks! As usual, the tarball is available for immediate download from: http://meowing.ccm.uc.edu/~ico/rtmix-latest.tar.gz (4.3MB) For more info, please visit my website, RTMix forums at http://meowing.ccm.uc.edu/cgi-bin/ico/yabb/YaBB.cgi?board=Rtmix_id, and/or the online documentation (provided above). Best wishes, Ivica Ico Bukvic, composer multimedia sculptor http://meowing.ccm.uc.edu/~ico
RE: [linux-audio-dev] [OT] linux audio on PPCi
-Original Message- From: [EMAIL PROTECTED] [mailto:linux-audio-dev- [EMAIL PROTECTED] On Behalf Of Christian Schoenebeck Sent: Sunday, November 30, 2003 7:19 PM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] [OT] linux audio on PPCi Es geschah am Sonntag, 30. November 2003 21:52 als Robert Jonsson schrieb: I think this an urban myth, the Nvidia drivers may be proprietary but they are well functioning. Actually there are opensource drivers for nvidia chips, it is true though that only the proprietary drivers support OpenGL. The situation isn't much different with ATI, tbough there may be open source OpenGL enabled drivers, last time I checked it was a real pain to get them to work and they don't support all cards. Fact is I had serious crashs caused by the Nvidia opengl driver, although I have to admit that was one year ago and on the other hand I have a Radeon 9000 where opengl works just fine with a normal X installation. I had to drop one chipset line into XF86Config-4 for the Radeon to work, but that's nothing compared to the Nvidia stress. Best regards Christian I use Dell Inspiron 8200 with NVidia's Geforce4Go (64MB) and in the last 2 1/2 years only had once a problem like that with one particular release of the drivers. Simple downgrade (and later upgrade to the fixed drivers which were released promptly resolved that without a hitch). In addition, Nvidia's drivers, although proprietary, have a nifty installer that automatically detects the platform and install proper version of the driver (and/or recompile the non-proprietary aspects). I heard somewhere that some of the Linux distributions now ship with these drivers included. As far as the noise is concerned, Centrino notebooks are now the best for noise-free high-performance settings. 1.7GHz Centrino notebooks beat the living daylights outta 2.4GHz P4 desktop in performance, mainly because they are a complementary mix of P3 performance and P4 scalability. They also offer great battery life (sometimes even upwards of 5+ hours per battery). My notebook is 1.8GHz P4 and it rarely kicks in a fan when working with it. It usually does so when playing highly demanding 3D games. Dell laptops also have nifty but Dell-unsupported Linux tools that enable you to control the CPU and Fan throttling hence enabling you to completely shut them off (obviously if you fry your laptop in the process that is your own problem). I've used this feature without any problems so far and the P4 downclocked to 1.2GHz is still plenty fast (although lately I've been topping off the cpu with my real-time stuff, something that really annoys me :-). To give you a perspective on this matter, on the last conference I had the laptop on-stage with 2 batteries in it charging (hence extra heat was being generated) set between two pianos. Since my piece was not first on the program, some bright soul decided to cover both pianos with the thick protective piano cloth. When I realized this in the middle of the concert I almost screamed thinking that my laptop would end up in a pile of smoldering goop, especially considering the fact that the darn thing was turned on with the power management disabled (I wanted to make sure that the screensaver or some stupid thing did not impair my performance) and on top of that charging the batteries. I was very pleasantly surprised when my number finally came to uncover the cloth from the pianos and the laptop and realize that my laptop was completely cool, if barely warm to the touch. Fans never kicked in. I like Dell for one more reason, their support/warranty is awesome. Sure, here or there you stumble across a pretty mentally challenged tech support person that asks you stupid questions and guides you through the steps that defy common reasoning, but most of the time they are very prompt (whenever I had to get my laptop fixed, the tech person would come to *my home* the very next day with the necessary parts, even if that had to be the whole motherboard and fixed it within minutes -- Disclaimer: I live in US, not sure how it works in other countries) and helpful. On top of that, when everything fails (i.e. they have no idea why laptop does what it does), they provide you with a whole new system! I initially bought a refurbished Inspiron 8000 P3 800Mhz with an old Ati Rage 4 Mobility (32MB) (their refurbs get a great price/value ratio and the same support as the new models) and throughout the years when it broke to the point they had no idea what was wrong, they replaced it with the current Inspiron8200 1.8GHz P4 at no cost to me. I also was able to upgrade the video card by myself (from geforce2go to geforce4go -- Dell has the spare parts division where you can get this kind of stuff) without a hitch, although this may void your warranty if you screw something up. Anyhow, Dell really worked well for me. Some other people were perhaps not as lucky as me and may have had pretty rotten experiences.
RE: [linux-audio-dev] Re: Hammerfall latency confusion in germanKeyboards articles ?
-Original Message- From: [EMAIL PROTECTED] [mailto:linux-audio-dev- [EMAIL PROTECTED] On Behalf Of Benno Senoner Sent: Saturday, November 01, 2003 5:03 PM To: [EMAIL PROTECTED] Subject: [linux-audio-dev] Re: Hammerfall latency confusion in germanKeyboards articles ? hmmm, I'll try to respond to my own question: (hoping having done the math correctly): alsa-kernel/pci/rme9652/hdsp.c: hdsp-period_bytes = 1 ((hdsp_decode_latency(hdsp-control_register) + 8)); latency register is 3 bit long, set all 3 bit to 0 and you get the lowest possible latency: period_bytes=1 (0+8) = 256 we are talking about 32bit words (24bit audio embedded in 32bit words) thus we need to divide bytes / 4 we get 64. one period = one fragment thus I assume the minimum buffer size = 2 x 64 = 128 samples which at 44100 = 3msec. (the keyboards test were done at 44.1kHz). All that seems to be correct. However AFAIK, the higher the sampling rate the lesser amount of time do those 128 samples encompass. Hence if you have double the sampling rate 88200Hz, then 128 samples ends up being only ~1.5ms. Of course you could go really crazy and do 192000, in which case latencies would be sub-millisecond. There is obviously still a question whether any kernel on the face of earth would be able to provide soundcard with data in time in order to avoid dropouts... Ico
RE: [linux-audio-dev] Re: Hammerfall latency confusion ingermanKeyboards articles ?
But the sample rate *was* specified to 44.1 kHz in this case, wasn't it...? Well if you wanna get *technical* about it, the hdsp tools (which was in the screenshot) on Windows reflects the same latency values regardless of what sampling rate you use (they do not change their ms rating in order to adjust to the changes in sampling rate -- see http://meowing.ccm.uc.edu/~ico/hdsp.jpg), and the original question, even though pointing at that particular screenshot did not necessarily refer only to the 44.1kHz sampling rate, but rather to the best achievable latency. In his case the original poster was right in both assumptions: 128 bits x 2 could be either 1.5ms or 3ms depending upon the sampling rate... There is obviously still a question whether any kernel on the face of earth would be able to provide soundcard with data in time in order to avoid dropouts... snip Also note that the x86 arch sucks at this pretty much by design. Alpha, PPC and others can get even lower latencies. Although this used to be the case, I tend to disagree, because where x86 architecture is lacking in design, it compensates with the increased clock speeds and various add-ons (i.e. hyper-threading). Even with a branch mis-prediction in a lengthy pipeline, these chips pump-out enough cycles/second to be able to withstand such penalties without much, if any performance loss when compared to their competition. This furthermore is a mute point with the 64-bit Intel's and AMD's offering as well as the upcoming Prescott (if the rumors are to be trusted). Ico
[linux-audio-dev] question about libalsaplayer's functionality (and its possible incorporation in my app)
Hi all, I've tried contacting the maintainer of the project (Andy), but he never bothered to reply, so now I am taking this question to all of you out there that might have had exposure to this interesting library. Does anyone know what is the current status of the whole project anyhow? Any help on this matter is greatly appreciated! When answering any of the given questions, please include the question in your reply. Thank you very much! So here's the excerpt from the letter: I've recently decided to incorporate libalsaplayer-like functionality the upcoming version of my app RTMix. However, with having a particular feature in mind I am wondering whether libalsaplayer provides that and if not, whether you'd be willing to add it (or let me add it, although that might get messy since I am not too familiar with the inner workings of the lib). So, here it goes: Apart from all the wonderful features libalsaplayer offers, I am looking for some additional ones: I would like to be able to indefinitely loop specific ranges of a particular soundfile (i.e. 2.2secs-4.12secs or whatever). 1. Is it possible to do this and have music continually loop even if one changes the direction of playing so that when the alsaplayer runs out of the looping material in each direction that it just jumps back onto the other end of the loop and contiues on (kind of like a ring-buffer)? 2. Is it also possible to do this kind of looping on the whole soundfile (the gui version of alsaplayer always stops if I let it play 'til the end or the beginning, depending in which direction I am going). 3. Is it possible to define loop points by addressing a particular sample number rather than giving time in seconds? 4. How stable is alsaplayer when looping really small chunks of sound (i.e. like 5 sample loop)? 5. Is alsaplayer capable of ramping such loop points by attenuating let's say ending 20 samples (it would be cool if this number could be user-selectable) and then ramping up the beginning 20 samples in order to alleviate the pop that happens when looping a sound where waveforms at the beginning and the end do not align? 6. If the feature in question 5 does not exist is there a way to control output level of a player on a per-sample basis via callback so that one can implement that outside of the lib? 7. If neither 5 or 6 are possible, would you be willing to implement such functionality (i.e. a toggle_ramp( bool ); and set_ramp_length( int ); callbacks or something similar. I would greatly appreciate your feedback on this matter as that will greatly assist me in determining how to go about implementing such functionality in my app. Thank you very much! Looking forward to hearing from you. Sincerely, Ivica Ico Bukvic, composer multimedia sculptor http://meowing.ccm.uc.edu/~ico P.S. How do you implement reading of a sound faster and slower than it sounds in such a gradual fashion? Do you adjust the sampling rate of the DSP and if so does that affect other streams coming from the libalsaplayer, or is this something that is sound-specific (and if so, how)?
[linux-audio-dev] Question regarding the alsa's audio latency benchmark
Hi all, I've had an interesting discussion with a professor and a distinguished member of the electroacoustic music community regarding audio latencies which made me realize that I did not understand the issue in its entirety. Hence, I looked around the net in order to educate myself. I soon stumbled across the following site: http://old.lwn.net/1999/0916/a/latency.html Admittedly, it's quite old but that, if anything speaks only in Linux's favor in terms of its pro-audio readiness. At any rate, I was checking out the benchmark data and was wondering as to how did this person/software app get to the 0.73ms buffer fragment that is equal to 128bytes? In other words, what sampling rate was used? 128 bytes in 44100Hz sampling rate = 3ms 128 bytes in 88200Hz sampling rate = 1.45ms 128 bytes in 176400Hz sampling rate = 0.725ms (this one being obviously closest, but at the same time, what kind of hardware supports this sampling rate, especially in 1999 when this test was done?) 128 bytes in 192000Hz sampling rate = 0.3ms So what gives? It seems like it is some kind of a 176k-ish sampling rate that, AFAIK does not exist. Furthermore, my question is what app was used to produce those graphs/results and whether these latency tests take into account hardware latencies (i.e. DSP converters, PCI-CPU-PCI-output etc.), in other words, is this latency that is achievable with the following setup: Input-soundcard-cpu(with some kind of DSP)-soundcard-Output Your help on this matter is greatly appreciated! Ivica Ico Bukvic, composer multimedia sculptor http://meowing.ccm.uc.edu/~ico
[linux-audio-dev] ANN: Initial public release of the Linux version of Soundmesh -- an Internet2 audio streaming software
Hi all, Announcing immediate availability of Soundmesh Internet2 audio streaming software. 1. What is Soundmesh Soundmesh is a result of a collaborative work with Mara Helmuth. It originally started as an Internet Sound Exchange Internet2 project and has since grown to become a full-fledged audio streaming front-end. The sole purpose of this app is to provide a mechanism for streaming multiple CD-quality (or better) audio soundfiles via fast Internet2 connection, utilizing hacked version of the RTcmix v.3.1.0. Hence, Soundmesh provides for a unique jamming tool via Internet for a larger groups of participants. 2. Obtaining Soundmesh Soundmesh is currently only available in a source form and is downloadable from my website. It's download is broken into 2 parts: the soundmesh front-end (~530KB)and the hacked full version of the RTcmix3.1.0 (8.2MB). They can be obtained using the following direct URL's: http://meowing.ccm.uc.edu/~ico/soundmesh/soundmesh-latest.tar.gz (~530KB) http://meowing.ccm.uc.edu/~ico/soundmesh/rtcmix-soundmesh.tar.gz (8.2MB) Alternately, you can also find the download links on my website. Documentation is also available: http://meowing.ccm.uc.edu/~ico/soundmesh/Documentation.txt Screenshot: http://meowing.ccm.uc.edu/~ico/soundmesh/Screenshot.jpg 3. Current Limitations *Soundmesh obviously does not currently support modular numbers of incoming and outgoing streams. This is something that is planned for a future release. *Perl (.pl) scorefiles are supported in soundmesh but do not work in RTcmix *Python RTcmix scorefiles are currently not supported and do not work with either soundmesh or this version of RTcmix *A number of playable streams before gapping occurs varies depending on the quality of a stream and the internet connection. Considering that this is an Internet2 project, chances are your modem connection will simply not work [well or at all]. *Sound played via network is not heard locally (should be a quick fix). *Connections are not secure. 4. Disclaimer Copyright Mara Helmuth Ivica Ico Bukvic 2001-3 Linux version distributed under the GPL license (see http://www.gnu.org/licenses/gpl.html for more info) This software comes with no warranty whatsoever! Use at your own risk! Best wishes, Ivica Ico Bukvic, composer multimedia sculptor http://meowing.ccm.uc.edu/~ico
RE: [linux-audio-dev] New form of GPL licence that protects Linux from proprietary world [was: New powermacs?]
if you assume what i'm saying two paragraphs up is in some way accurate, then it makes sense that you should make software so good that it will make people want to switch (and once they switch to the audio software and are happy, motivating a switch to linux is easy). Well, that's what I am not so sure of. If they can use this better app x on their OS which is not Linux, why switch? Just because it is free is not good enough (at least not in my personal experience of teaching Linux). by the way what is your particular research bent/area? it seems like that would in the short term be the easiest and most likely way of doing it (ie grants to fund development of a foundation and set of applications which have much greater flexibility and appeal to more users (than say Csound, et.al.) might without the high cost and inflexibility of proprietary solutions). I am a composer, but also a student (DMA -- soon to be done), hence my sphere of influence is currently minimal. I am lucky enough that I got the blessing from my department to start my own course Linux Multimedia and get some marginal funding for the computer equipment (I did not get paid squat, I was doing it because I like teaching it and I believe in it). This course came as a result of the fact that Linux, after the advent of OS X and porting of the pertinent GPL'ed apps to it, became (at least to the powers that be) a second-rate citizen in the audio studios, so I decided to create a separate class that would expose students to the power of Linux. Csound et al. already run on OSX and that is why I started this whole thread because I wanted to somehow find a way to shield the Linux and GPL'ed software designed on it by restricting it to Linux and hence encouraging use of Linux by others who might not be aware of its more important advantages (or not value them enough to switch) over its commercial alternatives. Ico
RE: [linux-audio-dev] New form of GPL licence that protects Linux from proprietary world [was: New powermacs?]
How do you think the Linux kernel is being developed so fast? By enthusiatic developers with enough money to survive. Wrong. How do you think Linus will now dedicate full-time to developing kernel, from paypal contributions from other geeks? It's IBM, Redhat, and many other companies with interests that pour big bucks as well as contribute code in the kernel development. Granted, Linus is not the only contributor, and there is huge contingent of people who simply give because they believe. Yet, the overall movement is perhaps the most heavily funded aspect of the Linux OS. In part by observing this trend I was hoping to somehow adjust it so it fits better needs of the LAD software (or perhaps to minimize problem that has caused me to pursue this issue in the first place). Musicians rarely care about their liberty. You should not expect the music industry, even your academic circle, to strongly embrace the free software movement. You might be forced to use proprietary tools, so in this case you better want free software to run on any computer. Good points. It saddens me, tough, that the artists take liberties so casually. Ico
RE: [linux-audio-dev] New form of GPL licence that protects Linux from proprietary world [was: New powermacs?]
It is important to note some of Apple's contributions to the open source community besides darwin. Darwin was not developed by Apple. It's originally a project that was developed on Intel machines. Apple took it on since it had an acceptable license (BSD). Several compiler and debugger engineers that I worked with at Cygnus Solutions before it was bought by Red Hat now work at Apple. These people work full time on gcc and gdb and all contributions go back to these projects. Optimizations and improvements for the PPC architecture in gcc and gdb benefits Linux on that platform as much as Apple. The html rendering engine of Apple's Safari browser is based on Konquerer, and the improvements Apple made are being contributed back to the project. Those contributions are in my personal experience, yet to be noticed. Konqueror was a formidable browser before Safari, and so it is now. As it stands right now, Apple has gained a lot more from the community than it has given back. Granted giving something instead of nothing is certainly better, but in my opinion not good enough. After all, you have to consider the impetus behind these moves on Apple's part. They did not choose to do this because they like oss, but because they have no alternative. Msft has held them in check with the crappy version of IE for years and they simply waited until Konqueror engine became good enough so that they could implement it without investing too much dev time. Same goes for the gcc and gdb. They took on a project that has been quite optimized for the PPC platform. For instance, it was Redhat who added the altivec optimizations to gnu compiler, not Apple. Hence, Apple's contributions are marginal at best. So where do you draw the line? Companies that don't contribute to open source? Companies that sell anything proprietary (which would eliminate Red Hat, check the licensing on some of their high end products). And if you want to punish M$, nothing is more powerful than the GPL. That license terrifies them. This truly is a pickle. But as it stands right now, I'd say any OS that has one impenetrable closed-source layer that is essential for the workings of the OS is in my eyes closed-source. Redhat's closed source products are not essential for the functioning of Linux, they are a mered add-on software, as opposed to the Apple's Quartz (and other underlying closed-source elements, such as Finder etc.), or Msft's entire OS. The beauty of the GPL is that it is blind like justice. Free means always and forever free. Very true. As it is right now, I've received a lot of convincing rebuttals of my idea, which certainly is a good thing, and I thank you all for that. However, no one has yet managed to propose an alternative that would resolve the dilemma that started the whole discussion -- ensuring that Linux-developed audio software primarily benefits Linux, not a non-related third-party OS that makes money off of our sweat. Any takers? ;-) Ico
RE: [linux-audio-dev] New form of GPL licence that protects Linux from proprietary world [was: New powermacs?]
On Sun, Jun 22, 2003 at 01:46:30PM -0400, Ivica Bukvic wrote: So basically, you want to restrict the use of a software to a specific type of operating system? Like M$ does? Not a _specific_ OS. There are _many_ open-source OS's out there and none of them have monopolistic agenda like Apple or M$. Nor do they use one theme that permeates much opensource software is user empowerment. freedom from silly obstacles like per-seat licensing or artificial technical limits by design or stupidity. because of this, i'd much rather work with opensource software like gcc or apache, etc than their closed counterparts even before considering price. Software would remain open-source. But the assumption is if you are willing to part with the freedoms Linux and other GNU OS's offer, and pay for a costlier system, as well as a bunch of shrink-wrapped apps, then you might as well pay for the oss apps and help the oss community. No one would switch to Apache in the first place were it not better than the closed-source solutions. By the same token if I have a killer audio app, they would either pay for it for their OS or switch to Linux or any other oss OS and enjoy the freedom. It's a bit pushy tactics, but that's exactly what our competition is doing, and doing it rather well. but this plan does not empower the user. it penalizes the wrong people (the users) for a marginal effect if any on the company. I disagree. It penalizes the company so that it cannot claim that it is Unix-like environment when it does not run (albeit for licensing reasons) Unix software. if it were your goal to make free software more popular (and admittedly this isn't my goal), it would make sense to make lots of free software available to people on OS X and XP who may not otherwise come in contact with it. so maybe they'll say, hey, i got this software for free and it's neati wonder what else is out there like it? You are mixing two notions: popularity of free software vs. popularity of _free OS_. Two are not the same. But even if they get in contact with the oss as you pointed out, my personal experience has taught me that they do not say cool app, let me switch to the oss OS. Rather, they say, cool app, let's download more since it obviously works just fine on their OS and there is no need to use Linux or any other oss OS. Hence, there is no benefit in it for Linux. you don't put a 'no gurls allowed' sign on your clubhouse and then complain about how no hot chicks ever show up. (ohhh that was probably offensive, but i think it's a fantastic metaphor ... for something). Wrong analogy. To use your context (as funny as it seems :-), I would put 'no gurls allowed without paying' on a clubhouse that has a covercharge. Then, next to it would be a clubhouse that is free for both boys and girls. Pop quiz: Where would the girls go? if nothing else think of the children: just because the school system makes a deal with apple or MS does that mean those kids don't deserve free software or deserve to make music if their school can't afford 5 or 10 copies off logic? are they just little closed source satans in the making waiting in dark places to monopolize your precious bodily fluids[1]? this could actually mean a substantive even life altering change by giving them the chance to play with your audio programs. With my proposal the schools would realize that with Linux they would get both the cheap computer and all the software they needed for free, instead of licensing the closed source alternatives. It would be simply an economical decision if nothing else. Hence, no need for weird cult examples of their activities in dark places ;-) (and if anyone wants to start a company that gives away free audio software and sells hardware, lesson plans, training, and support to k-12 (and especially economically disadvantaged) schools to create hands on music classes count me in. you would probably be eaten alive by good press). Sorry, you lost me there. I guess you are implying it's a good thing, and I concur. However, I do not see how it connects with the stuff above. Thanks for your insights! Regards, Ico
RE: [linux-audio-dev] New form of GPL licence that protects Linuxfrom proprietary world [was: New powermacs?]
Do we want to _become_ what our competition is? I don't think so. I don't like pushy tactics. We are (by some measure) successsfull because we are not like the competition. Point well taken. However, as someone pointed out earlier, we need more contributors to our community in order to have faster (or more competitive) progress. And the only way I see getting more contributors is to have larger pool of users. Besides, I am not suggesting the same tactics as our competitors, since the source will be still freely available, which in itself is lightyears beyond what msft and apple provide. Of course, the measure of success is in the eye of beholder. Yet, I am overly surprised that this community is not so much about Linux as much it is about the free software. I always felt that the two are synonymous and that with the failure of one, the other would be left stranded. If Linux were to fail, I don't think I would have enough of energy to start from scratch using another free OS, regardless how similar it is/was. I simply find it a bit frustrating that someone who has chipped-in very little is benefiting a lot from our work, and on top of that makes a good buck out of it -- and I am restlessly looking for a rational solution to it. Please understand that I have no problem with the GPL license in general and am honored to be a part of this community giving my own contribution out for free. It does wonders for my ego :-). Still, the question(s) remain: How do we channel the income made off of the GPL'ed software from commercial companies so that they directly benefit us, the developers, not the companies who had very little to do with our efforts (this question sounds a bit messy since it also implies that Redhat is bad, but that is not what I am trying to imply -- well you know what I mean, too tired to type any more :-)? Is this worth pursuing (obviously you know my answer)? If so, what are the options that yield concrete results (if there are any)? [just to keep banging on a bad analogy :-] My guess is that they would go to the one that is cool (whatever is cool at the moment). If the one that is not free is the one where the cool crowd hangs out, they will pay. And you will have a free but empty clubhouse (well, not really empty, a few geeks will be there talking about cool software... and yes, I would end up there as well :-). Of course it might also happen that the cool clubhouse is the one that is free, but don't take that as a given. Good point. However, the concept of cool from this analogy obviously in the world of software is directly related to the cost and the power of an app, apache being a perfect example of that. Hence, we already have a great advantage in that respect (the power being obviously perpetually evolving aspect that hopefully increases with the continuous development of an app), and with the inflow of funds from places that have plenty of it (not from paypal donations from other poor student Linux geeks), the development should also take a faster pace because people could make even the living off of such development, needless to mention that the whole concept would be perceived a lot more favorably among the corporate clientele (perhaps potentially profitable world == better hw vendor support == better Linux end-user experience). Anyway, I don't think acceptance of the os will ever come from twisting arms. Agree. But... (you knew that was coming :-) putting an affordable pricetag on a (for instance) pro-tools alternative such as Ardour would be hardly calling it twisting arms. I am not talking here about excessive prices, but rather shareware price ranges (obviously depending on the nature and scope of the software), that is enough to still greatly help the inflow of money for the development purposes, while ensuring competitive if not ludicrously cheap prices (when compared to the alternatives). Besides, if anyone wants it for free, they can simply install Linux and run it on their boxes free-of-charge regardless of their hw. This is really not even close to the monopolistic tactics of companies such as M$ and Apple. Users will use the os that meets their need. Actually, most users will use the os that comes with the machine they bought. Well, with the increased funding and therefore development, comes increased user-base, and with that better vendor support. All that amounts to increased presence of pre-installed Linux boxes. It's a closed circle that is tough to penetrate, but once in the loop, it becomes a lot simpler. Tying the use of a free cool app to running it in the free operating system so that users will switch will not work (I think). If the os they use does not come with the coolest tools (BTW, their idea of cool may be different from ours), and they are not available in free versions because of licensing issues they will just not use them and will use whatever else is available (free or not). That else could be our apps because they
RE: [linux-audio-dev] New form of GPL licence that protects Linux from proprietary world [was: New powermacs?]
Guess what: your derived license would be incompatible with the GPL or any OSI license. You don't understand what free software is. Here you go again, yakking making conclusions on your own doctored facts. I never implied occlusion of the source code nor did I ever suggest that I've worked out all the quirks out of the whole system. It is/was a mere proposal to instigate a discussion at this point, nothing more. Are you stating that I'm elitist because I use command line tools? I never agreed with gui users that believe their tools are easier and better for ordinary people. These tools are sometimes so complicated and badly designed that the only reasonable command to use is quit. As much as you think they should use a gui because you believe they can't use anything else, I think ordinary people should use free command line tools because they can. Text is not elitist, and it's still the easiest and most powerful intellectual technology. First you make an implied conclusion that had no grounds, now you extrapolate upon that. You'd be a wonderful politician. This has nothing to do with command line tools. This has to do with the _attitude_ you give to outsiders when you talk about oss/linux issues... Have you ever tried to reduce a bunch of images (let's say 1) with Photoshop? Now that you mention it, there are scripts you can run in Photoshop, predetermined operations on a file, or sets of files. How do you think they do post-production of movie clips (i.e. in a film-gimp fashion)? But that is beside the point. Your whole argument stems from your own implication and hence it's not worth discussing. I don't care about Linux. So what in the world are you doing on a _linux_ audio dev list? The free software movement is not purist Perhaps in its implementation, but in theory... (My advice: do not tell this to Richard Stallman) Hopefully, at some point, most of the computing chain will be free, including the hardware. And who will fund such a development? How do you think the Linux kernel is being developed so fast? If we wait for us geeks to come up with such a machine, at this pace I'll be long dead before that happens, so meanwhile I am trying to cook-up the second best thing that might just happen within my lifetime. Nonetheless, for what it's worth I share your enthusiasm, otherwise I would not be here. So, in short, yes, I am interested in seeing larger adoption of Linux. It's on my agenda because I believe. And I would love to see its greater deployment in the academic circles since this is what my domain/profession is. The reason for this discussion is because I am trying to come up with a way to strengthen the case for Linux in academic audio studios. As it stands right now, for a good number of musicians/studios out there the Linux has less and less of advantages over its competitors (obviously in part because they fail to understand its greatest strength -- its freedom), and a steep learning curve working against it. Cheers, Ico
[linux-audio-dev] New powermacs?
Hi all, Just heard the news (rumors) of new Macs that are going to hit the streets on Monday. Seems like Apple is finally going to catch-up with the PC world: there's talk of using IBM's PowerPC 970 64-bit CPU's. Makes me wonder what repercussions this will have on the whole LAD/LAU community, considering that they supposedly will have built-in optical audio I/O and with the recent announcement of Trolltech to make OS X Qt GPL-ed, leaves less and less advantages in Linux's favor (apart from the obvious untouchable open architecture and perhaps faster growing user-base -- according to recent news, can't remember where I exactly I read it tho, sale of factory-built Linux boxes should surpass Apple's this year, and that does not even include people with home-built machines and dual-booters). Please don't get me wrong. I am still in favor of Linux, obviously due to its open architecture. But at the same time I am becoming a bit weary of having to hack my advanced audio settings rather than use user-friendly tools. That, coupled with still anemic direct vendor hw driver support has really made me pay closer attention on Macs (as scary as that sounds). Yet, I feel such a sense of accomplishment when my Linux purrs just right with my desktop being uniquely configured and tailored to my needs. After all, I am a geek. :-) And the inner struggle goes on... Anyone care to comment or (please) dissuade me from potentially making a costly mistake? ;-) Ivica Ico Bukvic, composer multimedia sculptor http://meowing.ccm.uc.edu/~ico
RE: [linux-audio-dev] New powermacs?
Although if I ended up running Linux on it I would be paying a lot more for (at best) comparable hardware shrink-wrapped in the pretty box. If that is all, then I guess I feel rehabilitated :-). I am really thinking here whether OS X is worth the stab, or will I feel caged once I abandon the freedom of Linux. It seems you've partially answered my question, and I thank you for that! Thank you very much for your honest reply! Ivica Ico Bukvic, composer multimedia sculptor http://meowing.ccm.uc.edu/~ico -Original Message- From: [EMAIL PROTECTED] [mailto:linux-audio-dev- [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, June 21, 2003 1:42 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] New powermacs? Hi all, [snip - mac news - ] Please don't get me wrong. I am still in favor of Linux, obviously due to its open architecture. But at the same time I am becoming a bit weary of having to hack my advanced audio settings rather than use user-friendly tools. That, coupled with still anemic direct vendor hw driver support has really made me pay closer attention on Macs (as scary as that sounds). Yet, I feel such a sense of accomplishment when my Linux purrs just right with my desktop being uniquely configured and tailored to my needs. After all, I am a geek. :-) And the inner struggle goes on... Anyone care to comment or (please) dissuade me from potentially making a costly mistake? ;-) Well, i'm messing with a used iBook G3/500 right at the moment. OS X does look nice, and the few OS X audio apps i demo'd are solid. And, dual-booting w/Debian unstable was dead easy to do, i have OSS audio working jest fine with the built-in set, and i'm hoping to do ALSA via USB audio soon, which will be kewl. I like the hardware platform. The display is noticeably better than most Intel laptops, certainly better than the used ones i was comparing to. The Firewire Just Worked, right from the Debian install kernel. I've been using it with a IDE - firewire disk carrier. The unit is solid. The built-in audio is okay, my model has no real inputs (built-in mic) - you would definately be using USB or firewire for Real Work. Using Open Firmware at boot instead of BIOS is sweet. With Linux, performance is fine, even with the 500mhz chip. The OS X on the other hand, is noticeably slooower than Linux (2.4.21 + 2.5.72 kernels ), especially at reboot. And the Mac world is insanely closed, it actually surprized _me how little choice you have with OS X - near as i can figure, you buy most everything from Apple, pay a bunch more money than a comparable M$ product, or suffer. And since they are _not a huge monopoly, they seem to have little shame about being closed - i was very amused by the way they attempt to corral the first-time user into signing up for .Mac (Apple's version of MSN) during the OS X install, iTunes also. The main thing-that-makes-me-nutbar is the keyboard layout. That's fixable with X, and you can set up keymappings with sysctl for some Mac-specific things. Main installation pain is the Mac version of fdisk, which isterse. So in conclusion, i'd say the iBook + external converter (USB/fire) would make a fine Linux audio laptop. Get a decent sized disk, and you can dual-boot with OS X, and that will motivate you to run Linux again. :) cliffw (PS - http://www.penguinppc.org - is a good start point for Mac links) Ivica Ico Bukvic, composer multimedia sculptor http://meowing.ccm.uc.edu/~ico
RE: [linux-audio-dev] New powermacs?
If you really believe a GNU/Linux system if a better choice because of its open architecture, then hack some user-friendly tools, or ask someone else to do it. I am. Check my website. But I am also running out of steam (or maybe I am simply exhausted by the end-of-school-year syndrome, so everything appears to be grim to me :-), so to speak. I feel as if my efforts are on a larger scale practically pointless simply because the community is so fragmented that we have tons of redundant apps (see sound servers for example), out of which many of them are incomplete, other that work great do not have widespread use and/or purpose, and others are simply inefficient. For instance, I would love to see KDE drop the ugly artsd and use either Jackd or alsa's dmix plugin, but that is not going to happen because they believe that artsd is better (for whatever odd reason). Now for me to hack KDE to use jackd is simply too daunting a task (if not impossible), and yet to convince KDE developers to take that path has been tried in the past and has yielded even less promising results than the first option. If, only if we could do this small step of setting the platform-wide standards (and here I do not speak only in terms of audio), we would have OSX unified framework in Linux where it would make sense to make user-friendly tools that sit on top of that framework (regardless of its continuous development -- at least we would have one framework to deal with). As it is now, there is no sense of doing so when the underlying frameworks continuously change and/or compete making any kind of such tool obsolete overnight. At best one could keep on wasting time updating the user-friendly tool to keep up with the underlying changes, but that would detract efforts of many from bettering what is most important now -- a unified and powerful underlying framework. Yet, that is not what we're working on right now... 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 :-)... Regards, Ico
[linux-audio-dev] New form of GPL licence that protects Linux from proprietary world [was: New powermacs?]
. Small studios like mine and his can't afford not to adopt the Linux solutions. After the financial benefits are realized we can learn to appreciate the intelectual opportunities. One problem I became aware during the exchange with my friend is that Linux is percieved as a technically difficult solution. That's an interesting perception and the LAD/LAU communities can deal with it. The larger Linux community has made a great deal of progress with this. How hard is it to install Red Hat? Maybe it's more difficult to configure linux. But it's alot less painful to purchase and configure x86 hardware, rme cards, and a $2,000.00 digital mixer than it is to invest in a $15,000.00 Protools setup. OK, I'll shutup. ron --- Ivica Bukvic [EMAIL PROTECTED] wrote: Hi all, Just heard the news (rumors) of new Macs that are going to hit the streets on Monday. Seems like Apple is finally going to catch-up with the PC world: there's talk of using IBM's PowerPC 970 64-bit CPU's. Makes me wonder what repercussions this will have on the whole LAD/LAU community, considering that they supposedly will have built-in optical audio I/O and with the recent announcement of Trolltech to make OS X Qt GPL-ed, leaves less and less advantages in Linux's favor (apart from the obvious untouchable open architecture and perhaps faster growing user-base -- according to recent news, can't remember where I exactly I read it tho, sale of factory-built Linux boxes should surpass Apple's this year, and that does not even include people with home-built machines and dual-booters). Please don't get me wrong. I am still in favor of Linux, obviously due to its open architecture. But at the same time I am becoming a bit weary of having to hack my advanced audio settings rather than use user-friendly tools. That, coupled with still anemic direct vendor hw driver support has really made me pay closer attention on Macs (as scary as that sounds). Yet, I feel such a sense of accomplishment when my Linux purrs just right with my desktop being uniquely configured and tailored to my needs. After all, I am a geek. :-) And the inner struggle goes on... Anyone care to comment or (please) dissuade me from potentially making a costly mistake? ;-) Ivica Ico Bukvic, composer multimedia sculptor http://meowing.ccm.uc.edu/~ico __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
RE: [linux-audio-dev] New form of GPL licence that protects Linux from proprietary world [was: New powermacs?]
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. This way, we Sorry, meant to say commercial OS since obviously one could run such software on OS X using X11, hence bypassing proprietary parts (or at least most of them). Ico
RE: [linux-audio-dev] New form of GPL licence that protects Linux from proprietary world [was: New powermacs?]
I really don't see this as a problem. Do you mind saying why? The way I see it is it could be possibly because it feels good for a developer to see that the interest in their creation is increasing beyond the confines of the original platform, which certainly is good for the developer as an individual, but does not do as much for Linux overall (I am putting a big * since in your case we are talking about a lib, please see below). Sure, a contributor from another platform might contribute a system-independent improvement, but then again they might only (and perhaps more likely) provide platform-dependent improvement, which might not transfer so well back into Linux version (obviously assuming that it was originally developed for Linux). OTOH, if let's say theoretically the user base eventually tips in other OS's favor (meaning majority of users are on a different platform than the one it was originally designed for), then the project might eventually abandon original OS altogether. This is again, assuming that the nature of the project demands some kind of system dependence. *Obviously in your case, there is no need for system dependence since we are talking about a library, but in the case of an app like Ardour, this might be an issue. So, perhaps having libraries cross-platform compatible would encourage new avenues of porting apps from other OS's into Linux, but the same could not be said for the apps themselves (this again being an over-generalization). The reason I am bringing this up is because in the studio where I work (part of an university), I had this short window of opportunity when Macs were getting way behind Wintel machines (and Wintel machines were not an option) to introduce Linux, which I did. However, with the appearance of OS X shortly thereafter, the Linux adoption has come to standstill, primarily because a majority of the software studio was using was soon ported to OS X, and Linux lost its unique appeal. Hence, we now have only one Linux box in the official studio, while I use another completely unrelated lab with 5 Linux boxes to teach my Linux Multimedia class. Also, in response to Tim Hockin who mentioned: I guess I don't see it as a problem. Forcing people to use this or that software is exactly what GPL is AGAINST. Use whatever works for you. I don't see how would that go against GPL. If anything, I see my proposal as a GPL-offspring since it has a lot in common with the whole issue of using closed-source drivers (i.e. nvidia's or ati's) which taints the GPL nature of the kernel. By the same token, using the GPL'ed software on top of proprietary framework to me seems also a kind of a tainted approach to the whole issue. I know that this comparison is a bit far-fetched, but not completely unrealistic. Think of it this, very economically driven way: For instance, Linux developers (among others) have poured a lot of time and effort into developing gnu compilers and various other dev tools (i.e. glade, kdevelop). Now, person X designs an app using those tools, but uses it for OS other than Linux. End result, Linux OS does not gain anything, while the other proprietary OS does. Does this seem like a sane business? I know that GPL is not about that, and that its primary goal is to provide freedom for all, but then again knowing that there are forces out there who would rather see FSF, GNU, and Linux die, one has to wonder whether we are prepared to survive the commercial onslaught we are already tasting with the whole SCO fiasco. Besides, this could provide avenues for profit that some of the audio projects desperately need: like Trolltech with Qt, where they sell the dev tools to Microsoft's platform, but give them under GPL to GNU/Linux. OK, enough for now. Sorry all for the long ramble. Hope this will instigate an interesting discussion. :-) Ico
RE: [linux-audio-dev] New form of GPL licence that protects Linuxfrom proprietary world [was: New powermacs?]t
I wouldn't decline this idea so fast, i think he made a valid point. If you watch todays software market, especially the battle between the OSes, you can see Apple as well as M$ aquiring so-called Killer-Applications which shall force people who need that Apps to move to their OS. Especially what Apple did with Emagic Logic is a perfect example. Now if you allow your Open Source Applications to be ported to this proprietary OSes, you strengthen this behaviour and weaken the Open Source Movement. People will get your software but will stick with OSX or whatever cause of this called Killerapps. And i dont think GPL is not so much about not ppl letting you force to use special software. IMO its more about sharing and passing knowledge (great both in a technical but also social/political way) and do better software by the benefits of it. Actually i dont know if this new form of GPL is a good idea, but i guess its worth thinking about it, as you still have the goods of opensource but just decline the possibility to support Non-Opensource Systems. 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). Ico
[linux-audio-dev] Needing help in resolving the Pd-Gem package linker problem (and hopefully learn something in the process :-)
Hi all, This is the issue I've been dealing with for the past couple of hours. I am using mostly vanilla Mdk 9.0. I am trying to compile Gem from source (for Pd), and while it does compile without any problems at runtime (pd -lib Gem) I get the following issue: /usr/lib/pd/extra/Gem.pd_linux: /usr/lib/pd/extra/Gem.pd_linux: undefined symbol: __ctype_toupper_loc /usr/lib/pd/extra/Gem: can't load library I've tracked this one to the gcc library (please correct me if I am wrong). However, there are no errors at compile time: g++ -o Gem.pd_linux -L/usr/X11R6/lib -L../../../GemLibs/liborb ../Manips/*.o ../Particles/*.o ../Base/*.o ../MarkEx/*.o ../Pixes/*.o ../Controls/*.o ../Nongeos/*.o ../Geos/*.o ../openGL/*.o -shared -lquicktime -lmpeg3 -lorb -lglib -lgltt -lttf -ljpeg -ltiff -lpng -lglut -lGLU -lGL -lz -lm -Wl,-shared -Wl,-export-dynamic -lXxf86vm -lXext -lX11 I also tried adding all over the place -lgcc like this: g++ -o Gem.pd_linux -L/usr/X11R6/lib -L../../../GemLibs/liborb ../Manips/*.o ../Particles/*.o ../Base/*.o ../MarkEx/*.o ../Pixes/*.o ../Controls/*.o ../Nongeos/*.o ../Geos/*.o ../openGL/*.o -shared -lgcc -lquicktime -lmpeg3 -lorb -lglib -lgltt -lttf -ljpeg -ltiff -lpng -lglut -lGLU -lGL -lz -lm -Wl,-shared -lgcc -Wl,-export-dynamic -lgcc -lXxf86vm -lXext -lX11 and the compile is successful, but I still keep getting the same error. I tried building the static version, but then I get the following error: g++ -o Gem.pd_linux -L/usr/X11R6/lib -L../../../GemLibs/liborb ../Manips/*.o ../Particles/*.o ../Base/*.o ../MarkEx/*.o ../Pixes/*.o ../Controls/*.o ../Nongeos/*.o ../Geos/*.o ../openGL/*.o -shared -lquicktime -lmpeg3 -lorb -lglib -lgltt -lttf -ljpeg -ltiff -lpng -lglut -lGLU -lGL -Wl,-Bstatic -lz -lm -Wl,-shared -Wl,-export-dynamic -lXxf86vm -lXext -lX11 /usr/bin/ld: cannot find -lgcc_s collect2: ld returned 1 exit status make: *** [Gem.pd_linux] Error 1 I then checked ld -lgcc_s And the only thing I got was: ld: warning: cannot find entry symbol _start; not setting start address Now, could someone please tell me what the heck does this mean??? ldd /usr/lib/libgcc_s.so gives: libc.so.6 = /lib/i686/libc.so.6 (0x4001a000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) At this point, I am confused and do not know what to do. I tried upgrading ldconfig, ld, and am currently recompiling gcc from a cooker source (which is taking a lot of time). So, I would greatly appreciate any help I can get on this issue, since the whole idea of linking is not so clear to me. Finally, I would appreciate the explanation of -Bstatic flag which seems to invoke -lgcc_s that is subsequently not found for whatever reason, despite the fact the ld otherwise finds it (with the aforementioned warning though). Any help on this issue is greatly appreciated! Sincerely, Ico
[linux-audio-dev] Helpful info for ppl trying to install RH 8.0 (for CCRMA stuff) using Intel 845G chipset (this could be a valuable documentation for others)
Hi all, I saw a couple posts on this matter on other lists namely from people who are trying to make multimedia Linux boxes using CCRMA packages and RH 8.0. The issue at hand is that many of the newer machines with cheapo embedded video cards use Intel 845G chipset which is unsupported by RH 8.0's XFree 4.2. However, XFree 4.3 does support it and so the following needs to be done (assumption is that you have a reasonably fast internet connection, otherwise this might prove to be pain -- total d/l amount is approx. 70MB): 1) Install RH 8.0 in command-line mode (graphics mode will most likely fail -- it did on mine, although it might have been partially due to use of an outdated flatscreen monitor that did not allow even the framebuffer mode) 2) Skip XFree config (if you really feel compelled to configure it, do NOT test it, it WILL fail) 3) Upon reboot, using Internet connection, connect to the following ftp in order to retrieve XFree 4.3 version of the x server for the RH 8.0 (you might try the Rawhide mirrors as well but I am not sure whether those will work): ftp://people.redhat.com/mharris/testing/unstable/XFree86 (thanks to Mike Harris from Redhat for making them) 4) Install XFree packages by doing: rpm -Uvh *.rpm --nodeps --force (don't worry it should be ok, at least it was on mine :-) 5) configure up2date 6) run: up2date glibc (you need 2.3.2 for Xfree 4.3, and the one that comes with RH is 2.2.something) 7) Upon finishing installation, run: redhat-config-xfree86 -o /etc/X11/XF86Config (you might need to tinker with the config file, depending on your monitor and other hw) 8) Try starting x server with: startx 9) Now, you should be up and running, but you still need to enable acceleration (since otherwise anything with OpenGL will be simply impossible to use). You need to get the new version of DRI (which reports errors since the kernel module i830.o is ver.1.2 not 1.3 as required by Xfree4.3). So go download new DRI package for 4.3 from here: http://www.xfree86.org/~alanh/linux-drm-4.3.0-kernelsource.tar.gz (big thanks to Leif Delgass for pointing this out) 10) untar the package and make the new module by doing: make -f Makefile.linux 11) install the i830.o file by copying it to the /lib/modules/kernel-version/kernel/drivers/char/drm/ (you might wanna backup the old module to something like old-i830.o just in case something screws up) 12) Now reboot the machine and check the /var/log/XFree86.0.log for any DRI errors. You might also wanna run the glxgears or something similar to see if everything is ok. Don't expect much of a fps increase, though (I had 336 fps on the studio's 2.4GHz P4 machine, while with DRI it went up to only 400+ fps). What you will, however, see is the smoother moving the OpenGL window around the desktop and generally better system responsiveness. Now I can even play the Tuxracer at a reasonable framerate. Yay! That's it. Hope someone finds this helpful. Cheers! Ivica Ico Bukvic http://meowing.ccm.uc.edu/~ico
RE: [linux-audio-dev] OpenSoundControl. WAS: Modular synths of the world, unite and take over :-)
AFAIK a timestamp can only be prepended an OSC-bundle (which contains OSC messages or recursively bundles again), but not a single message? so the only way to set a certain execution time is by sending a bundle: #bundle timestamp sizecount /midi/channel/ and so on... Yes, you are right. However, nothing wrong with sending one-message bundle :-). i could not found any hint about the license of matt wright's library, he always says OpenSource, which is not necessarily free. will ask him about this. See the source code of OSC-kit. It's included in there. Basically it's free for use as long as it is not used for commercial purposes (the license must be included in the source code). Otherwise, it must be licensed. Hope this helps! Ico
[linux-audio-dev] How does one alter the main mixer volume (or any other mixer level) in ALSA from a command line (via a simple system call)?
Hi all, I have this small question: Is it possible (I presume it is) to alter mixer settings in Alsa by invoking some kind of a system call using shell (i.e. how the RME hdsp can have its stuff altered)? If so, what is the range of values that describe the loudest and softest levels? Finally, are these levels standardized? Any help on this matter is greatly appreciated! Thank you! Sincerely, Ico P.S. Apologies for cross-posting.
RE: [linux-audio-dev] Help wanted with audio app design
Hi, Some of your ideas already reside in other projects, so perhaps consider contributing to them rather than starting yet another project. IMHO what we really need now in Linux community is a couple of really stable and versatile apps, rather than a huge number of unfinished projects. If you are interested in live-control of various audio/midi processes, you may want to look into my RTMix. The latest version (that will be available for download very shortly -- squashing last batch of the nasty bugs :-) has midi and OSC implemented and can pose as a Midi router/server as well as network host/client, as well as do various algorhythmic things. What it does not have is sequencing capabilities (other than routing the sequenced data), although it could be easily expanded to accommodate for that functionality as well. I am sure there are other similar projects out there that address your needs in one way or the other. For RTMix go here: http://meowing.ccm.uc.edu/~ico/ Ico
[linux-audio-dev] problems with Midisport 2x2
Hi all, I've got a small problem with my Midisport 2x2 MIDI interface. While it worked ok before, now for some odd reason I cannot get it to open for MIDI output (from the computer). I've checked the /var/log/messages and this is what I got: Feb 24 20:44:41 mycomp kernel: hub.c: USB new device connect on bus2/1, assigned device number 2 Feb 24 20:44:41 mycomp kernel: usb.c: USB device 2 (vend/prod 0x763/0x1001) is not claimed by any active driver. Feb 24 20:44:44 mycomp /etc/hotplug/usb.agent: Setup ezusbmidi for USB product 763/1001/1 Feb 24 20:44:44 mycomp /etc/hotplug/usb.agent: Module setup ezusbmidi for USB product 763/1001/1 Feb 24 20:44:44 mycomp /etc/hotplug/usb/ezusbmidi: load /usr/share/usb/ezusbmidi/ezusbmidi2x2.ihx for 763/1001/1 to /proc/bus/usb/002/002 Feb 24 20:44:44 mycomp kernel: usb-uhci.c: interrupt, status 2, frame# 1645 Feb 24 20:44:44 mycomp kernel: usb.c: USB disconnect on device 2 Feb 24 20:44:44 mycomp kernel: hub.c: USB new device connect on bus2/1, assigned device number 3 Feb 24 20:44:44 mycomp kernel: usb.c: USB device 3 (vend/prod 0x763/0x1110) is not claimed by any active driver. Feb 24 20:44:48 mycomp /etc/hotplug/usb.agent: Setup snd-usb-audio audio usb usb-midi for USB product 763/1110/1 Feb 24 20:44:48 mycomp kernel: usb.c: registered new driver snd-usb-audio Feb 24 20:44:48 mycomp kernel: snd-usb-midi: MIDIStreaming version 01.00 Feb 24 20:44:48 mycomp kernel: snd-usb-midi: EP 01: 2 jack(s) Feb 24 20:44:48 mycomp kernel: snd-usb-midi: EP 81: 2 jack(s) Feb 24 20:44:48 mycomp kernel: snd-usb-midi: created 0 output and 4 input ports Feb 24 20:44:48 mycomp kernel: usb-uhci.c: ENXIO c0008380, flags 0, urb cdc59d60, burb cdc59ce0 Feb 24 20:44:48 mycomp kernel: snd-usb-midi: usb_submit_urb: -6 Feb 24 20:44:48 mycomp /etc/hotplug/usb.agent: ... blacklisted module: audio Feb 24 20:44:48 mycomp kernel: usb.c: registered new driver midi Feb 24 20:44:48 mycomp /etc/hotplug/usb.agent: ... blacklisted module: usb-midi It says that the device was opened with 4 input and 0 output ports. Why is this the case? I have no problem getting the midi input going, but my output is mysteriously dead. I've read somewhere that if the device is reconnected that the output stops working (might have been CCRMA's Fernando), but this is the log from the initial connect as soon as the computer boots. I've also made sure that no MIDI devices were connected to the MIDISPORT upon starting up. Any help on this issue is greatly appreciated! Sincerely, Ico
RE: [linux-audio-dev] SuperCollider
Does this mean that Supercollider will be fully functional in Linux soon? The thought of this makes me drool all over my keyboard :-) Ico -Original Message- From: [EMAIL PROTECTED] [mailto:linux-audio-dev- [EMAIL PROTECTED] On Behalf Of stefan kersten Sent: Friday, February 21, 2003 12:03 PM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] SuperCollider Miha Tomsic wrote: What is new on the SuperCollider front? i'm working on it. i just passed my exams and will move tomorrow; expect a new release of scsynth and sclang for linux early next week. I've seen there are some new files up on the page and will try to compile them later today. the 'new' packages on my page are undocumented and unsupported. as a teaser, though: sclang is basically ported and has an emacs text editing interface. i'll post an announcement to this list as soon as i'm finished. sk
RE: [linux-audio-dev] Re: why is no-one responding are you all just a bunch of *^%^%^ wits???
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. --p Do I/we have at least your permission (if we do manage to compile out of CVS) to redistribute my/our compiled version? Ico
[linux-audio-dev] While we're talking about lack of responses :-)
I e-mailed the list a couple of days ago asking for some advice regarding my RTMix app (how to make it more user-friendly). I am still waiting for some help on this one :-D. Again, any insight is greatly appreciated! Sincerely, P.S. Web server hosting my page is still down, thanks to the smart university technicians... If someone desires screenshots I'd be more than willing to send them to you as an attachment (I just don't wanna do that over the mailing list because it would clutter a lot of people's inboxes). Ico
RE: [linux-audio-dev] While we're talking about lack of responses :-)
Thanks for your reply! Personally, I am rather against the Apple's layout and usability ideas (for that matter I am also against the KDE's outdated usability guidelines as well) since it has proven to be nothing but a nightmare for the computer illiterate (or barely literate) students whom I taught in the past. One of the recurring issues is the persistent toolbar on the top (which arguably is easier to hit since it is positioned at the edge of the screen) that changes as you focus onto different apps. Almost every new user figures that the app is closed when the window is closed (which then would bring me to conclusion that this is the way things should be) and so I always have crashing (OS 9) machines in my studio due to fact that they run 5-10 apps at the same time in the background while trying to open a new one (or even better, wondering while the app is not opening when in fact it is already open and the new window needs to be opened). Other gripe is that some menus need to be selected by holding the mouse button and releasing it when the pointer is above the option -- what if your hand slips and you accidentally press the wrong option? Such as slip-up in apps that have 1-level undo could prove to be a real nuisance. Other issues are purely performance-based. Aqua GUI, apart from being very attractive (although we could argue that one gets tired of it rather easy and soon it becomes somewhat cumbersome, especially on the interleaved LCD screens where its horizontal-line pattern creates an eye-straining shimmer effect) is a humongous resource hog. If you ever try to resize a window with a complex layout, you'll see what I mean. What we could learn from Apple, though, is how far-reaching eye-candy can be. This is definitely something worth looking into. Especially now that the libsvg has finally gotten so optimized that you can resize vectorized icons/images in real-time without eating too many cpu cycles. From what I've seen on the links you've given it seems that focusing widgets and keyboard accelerators are a good thing (which makes me feel good since my app has already both :-) Ico Great suggestions nonetheless, keep them coming!
[linux-audio-dev] Seeking advice in making my app more user-friendly
Hi all, I am in the process of revamping my app as well as adding more features. The problem my app currently has is that the main window is not resizable, which may potentially cause problems on displays with limited resolution. I've decided to fix this issue once and for all but am not sure which path to take. The app in question is RTMix and its current layout is split into two parts: Top with timers and buttons Bottom with the main notification widget and bunch of tabs for editor and other functionalities. The app looks something like this: _ |buttons| | timer | _ | tabs | |widgets| _ Now I am ready to begin working on a resizable version (which should mostly not be a problem, other than being time-consuming) and am wondering whether I should separate the two widgets all together and have them therefore fully customizable (size-wise). While this option seems very easy to implement and also attractive, I am concerned with the issue that the app will easily lose its default looks and may quickly become overwhelming for the first-time user (since it is designed to provide performer-computer interface with the least amount of familiarization required). I would especially appreciate comments from people who got to use RTMix as to what would they like to see, but of course I would appreciate anyone else's opinions on this matter as well. The other option I've been thinking is to move the two widgets side-by-side, rather than having one over the other, which would certainly make maximizing window easier and would utilize the desktop space more efficiently. However, the issue is also that the app has a bunch of other deployable floating sub-windows and as such this may not prove to be the best solution, and would probably look pretty useless when having a relatively small window. Finally, I can simply leave the app as it is but then the notification interface (the bottom part) as well as other tabbed widgets of the bottom part (such as the script editor) will not be as efficient in utilizing the desktop space as they could possibly be. I also thought of having the two widgets designed in such a way that they can be glued together (i.e. xmms-like) or separated as needed, but I am just afraid that this option may take too much effort since then I would have to get rid of the default window decorations (in order to make them gluable) and make my own custom-designed window handles, which seems too much of a nuisance to implement. I am sure someone might have yet another idea regarding this issue that I am simply unable to think of so I would greatly appreciate your input on this matter. The bottom line is that I am looking to make this app as flexible in terms of desktop space utilization as possible while sacrificing the minimum amounts of the standardization it currently has to offer. Your help is greatly appreciated! BTW I am using Qt (if that becomes relevant at some point). P.S. I have a bunch of screenshots on my site, but the network is currently screwed up on the University campus so it may end up not being available for the next 8-24 hrs. Hence, I am unable to give you the screenshots. However, you may wanna try the URL in my sig -- who knows, maybe the network will be up by the time this hits your inboxes :-). Again thanks for your help! Sincerely, Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico To be or not to be - Shakespeare To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra 2b || ! 2b - ? I am - God
[linux-audio-dev] Addition to the Usb-midi problem (Midisport 2x2)
Forgot to mention that I blacklisted usb-midi and audio drivers in the /etc/hotplug/blacklist. The computer tried also to load snd-usb-audio (why?), so I blacklisted that one as well. Btw, using Alsa 9.0.rc5. Finally, even though the /var/log/messages mentions creating two pairs I/O ports (since it is Midisport 2x2) I only have one /dev/midi1 device hooked up I guess to the first 16 channels. Where are the other 16? Any help is appreciated! Ico
[linux-audio-dev] Question regarding Usb-midi and Midisport 2x2
Hi all, a small question regarding getting this thing to work. I'd appreciate any help I can get. I am running MDK 9.0 and am trying to get Midisport 2x2 to hotplug. The problem is that if I use the ezusbmidi script (obviously coupled with the right firmware and hotplug stuff) the /var/log/messages definitely notes its successful recognition of the device and announces the last line echo that the firmware has been installed onto the device /proc/bus/usb/002/021 (or whatever number it gets assigned), yet the midisport remains dead. I understand that the ezusbmidi script uses fxload to upload the firmware, but according to the syntax of the ezusbmidi script it sends the command in the following format: Fxload -I /path/to/firmware But this is not sufficient when you try just fxload by itself, it complains that it is missing the destination device (-D flag). So subsequently I am guessing that this is the stepping stone but then how is everyone else getting this thing to work. OTOH, when I try ezusb2131 it works flawlessly (manually) but there is no automation script for it, so I know that everything loads properly, it is just that my fxload for some reason is not working properly. I tested my midi after using ezusb2131 and it does work (/dev/midi1). Now, I hacked the script for the ezusbmidi and it does hotplug, but it is an ugly hack and I am wondering what is wrong with this picture? Any help is greatly appreciated! Sincerely, Ivica Ico Bukvic
[linux-audio-dev] interesting info regarding hdsp behavior
Hi all, I've been messing with hdsp and found out an interesting issue. After installing the driver for the first time onto the xp machine I also had no sound coming out of the soundcard even though totalmix app showed levels to be up. After clicking on the levels and/or moving them a bit, suddenly the sound was there (as if the default values were there only in the app itself, but did not affect the actual levels on the card until they were moved for the first time). I was wondering maybe this is the problem we're having in Linux, where the card loads just fine, but for some reason there is no sound until a reboot has taken place. I know this may be completely stupid thing to pursue, but since I've heard of no fix for this issue, I thought this may be a possible culprit. I am still struggling with the Linux driver (I got the card working on an Dell Inspiron 8200 where the card posts and everything supposedly works, but there is no sound coming from it), so perhaps as dumb as this sounds, this may be the solution to the problem we've been having with the hdsp in Linux. I should also mention that I am using hdsp pcmcia interface and that I've flashed it using the latest update from the rme-audio website (could this also have something to do with it?). Any info on this issue is greatly appreciated. Sincerely, Ivica Ico Bukvic
RE: [linux-audio-dev] OpenSynth Eko supports Linux ?
On Fri, Jan 17, 2003 at 11:07:40AM +0100, Vincent Touquet wrote: Check this out: - http://www.opnlabs.com/ - http://www.opnlabs.com/ekochart.php [comes with XP or LINUX !] HOLY CRAP -- OMG! Where can one buy one? Couldn't find anything on the site. Anyone knows how they utilize VSTi architecture under Linux? Ico
[linux-audio-dev] Need help implementing MIDI into my app
Hi all, I got a couple of questions regarding MIDI implementation in Linux. My app (that I am currently working on) will not use MIDI for sequencing, but rather as a real-time triggering mechanism (including continuous controllers) that will intercommunicate with other MIDI-capable apps on the (usually) same system. A while ago I was suggested that the best path is to use Open Sound Control for such stuff. However, upon [quickly] glancing at the .h file for OSC, I realized that it is nothing more than a network protocol for such stuff and that it has nothing in it that would enable it to hook-up directly to the /dev/midi port and then parse the info by itself and route accordingly to the settings in my main app. So, I would greatly appreciate any help in figuring out where can I get the code that would bridge this gap between /dev/midi and the OSC, and that would be flexible enough for me to be able to customize routing (let's say based on what controller and what channel the data is coming from). Any source code you could point me towards would be greatly appreciated (preferably something that is not a part of a gargantuan project that will be hard to extract). Also, if I have misstated anything above, please do correct me. Finally, any alternative suggestions for my implementation would be greatly appreciated as well. My need is for: 1) ability to route MIDI data on a local machine incoming from outer physical MIDI controller 2) ability to communicate with as many apps as possible 3) ability to do so in an elegant fashion (i.e. easy to implement) 4) communication needs to be only one-way (returned MIDI data from apps receiving my app do not interest me) Thank you for your help! Sincerely, Ivica Ico Bukvic
[linux-audio-dev] ANN: RTMix 0.52 version available
Hello all! A new version of RTMix is available at the same old place: http://meowing.ccm.uc.edu/~ico/ (use html entrance for low-bandwith version - cpu's - rtmix download) New improvements include: *Fixed networking seg-faults in Qt3 *Finished network code *Removed all kde-libs dependencies (I overlooked a couple in the configure script itself, sorry about this) *Several minor bug-fixes *Fixed all other known seg-faulting bugs *Added a couple of networking tutorials Enjoy! Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ To be or not to be - Shakespeare To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra 2b || ! 2b - ? I am - God
RE: [linux-audio-dev] Looking for some PR stuff related to Jack
however, i can guarantee you that it will be a long time or never that ardour runs as an in-process client. --p Pardon my ignorance, as well as probably beating a dead horse, but I would appreciate just a quick insight as to why is out-of-process client better than in-process, or if not, why is ardour geared towards being out-of-process app, when (at least judging from the info I've gotten so far) in-process stuff provides so much better performance? I am completely clueless on this seemingly low-level issue so any quick insight would be greatly appreciated! Ico
RE: [linux-audio-dev] Looking for some PR stuff related to Jack
as you can hopefully see, things start to get more and more and more complex. its not impossible to do this, but its hard, and i have much more important things on my mind than re-engineering the 80,000 lines of Ardour's code to make an in-process version possible. --p So, I presume it is impossible to get let's say an i-p version of Jack running that can accept both i-p and o-o-p connections (so for instance Ardour would be o-o-p, while freqtweak i-p)? If this were possible, then the clients could harness the potential of low-latency Jack, while more complex apps like Ardour would have a kind of a compromise. Would this be feasible? Alternately, you spoke of o-o-p being just not reliable enough. What aspect of Linux needs to improve in order for o-o-p to become as reliable as i-i-p? Thanks for all the valuable info! Ico
RE: [linux-audio-dev] Looking for some PR stuff related to Jack
Thanks for the info! Just two more questions: Was the Jack latency always been this way or was it in the past comparable to the Alsa-only latency? Also, would you presume that having for newer machines with faster FSB would improve latency even further? Once more thanks for your help! Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God
RE: [linux-audio-dev] Looking for some PR stuff related to Jack
Could this be a possible solution to the in-process xrun issue? http://www.onlamp.com/pub/a/onlamp/2002/11/07/linux_threads.html Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God -Original Message- From: [EMAIL PROTECTED] [mailto:linux-audio-dev- [EMAIL PROTECTED]] On Behalf Of Paul Davis Sent: Saturday, November 09, 2002 2:40 PM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] Looking for some PR stuff related to Jack Was the Jack latency always been this way or was it in the past comparable to the Alsa-only latency? BTW, the best case should have been 2.6ms, not 2.3ms. --p
[linux-audio-dev] Looking for some PR stuff related to Jack
Hi all, I am currently writing an article talks (among other things) about Linux as one of the currently viable pro-quality-audio platforms. I am trying to get a hold of some specs in relation to JACK, so I'd appreciate it if you can give me a quick rundown of the following information: All of these pertain to ALSA or JACK: 1.) What is the lowest stable achievable latency with the current stable (2.4) branch of the kernel (with ll and preempt patches) using Alsa on a modern system (i.e. at least 1GHz machine)? 2.) What is the lowest stable achievable latency utilizing app---jack---audio hw kind of setup on a modern system (i.e. at least 1GHz machine) with the current stable (2.4) branch of the kernel (with ll and preempt patches) using Alsa? I would appreciate it if you restrict your responses to simple numbers (i.e. 1) 1.6ms 2) 2ms ) since I do not have the time to have a discussion on this matter, but am rather looking for a quick list of testimonials in regards to the two given questions. Thank you for your help! Sincerely, Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God
RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
JACK *isn't* intended for general use, and i get tired of suggestions that it should be. snip and then later... the reason for not doing this is that there isn't manpower to do it. i am focused on JACK as the engine for a set of apps that i want to be able use (and i want others to be able to use them) in pro audio, real time, low latency environments. i don't have the hours (or the cash) to support the development of a joe user sound server. if you do, then please join the development team and help us out. Then explain it this way, and do not contradict yourself by initially saying Jack will never replace other sound daemons, and then mention that it is simply an issue that there is not enough manpower... Besides Jack can be high-latency (up to 8192 buffer size), so it is already fit to be used for purposes other than pro or SOPMF-whatever... RTcmix, as fabulous of a program as it is, doesn't meet my definition of pro audio. actually, pro audio is a bad term. i should stick with stuff like studios operated as profit-making entities and/or real time performance with a mixture of electronic and acoustic sound sources. i'll call SOPME/RTP from now on, OK? First off, I USE RTcmix for real-time performance with a mixture of electronic and acoustic sound sources, so obviously you have no idea what RTcmix is. Sure, it did not have a fancy gui (although that just changed a couple months ago with a new GUI from Dave Topper that makes RTcmix look like another Pd-like product). Other thing is, it is VERY LOW LATENCY, you can specify a single buffer size of 64 if you feel like it, the only question is whether your computer will keep up with it and how cpu intensive the process is. RTcmix has one of the best reverb, flange, place, and move filters I've heard, it has its own sub-busses (for mixing multiple filters), needless to mention dozens and dozens of other incredible instruments. It could as well be much better than any LADSPA plugin out there... Yet you say it's no good for commercial market... Hmmm... If you knew anything about the market, then you'd realize that as many SOPME/RTP studios there are in the world, they don't stack up to the amount of money educational institutions spend on building their electronic music studios, and this is where apps like RTcmix are an equal concern as Protools (even the university this list is hosted on uses RTcmix). If you had realized that, you'd know you'd be making a lot more money by selling your computers with Ardour and other stuff preinstalled to institutions like these (yet the institutions want their cpu's to do more than just Ardour). Just to give you a perspective, some of the INDIVIDUAL University studios in the US spend over $100,000/year for the new equipment/software. How much do the SOPME/RTP spend once they equip it for the first time? This will create an unnecessary polarization in an already heavily fragmented audio community (oss vs. alsa, esd vs. asd vs. artsd vs. gstreamer vs. jackd etc.). Linux is supposed to be all-inclusive and 1) who said linux is supposed to be all inclusive? who? Show me any past hardware that is not any more compatible with Linux and you'll know what I am talking about. Even if the device is not supported by the current kernel, you can always find a module and recompile it. That is by anyone's definition all-inclusive. Sure, some things do not work yet, but will be there soon (and this is not the issue in this case, since that falls into the forward-looking aspect). i never said that not supporting JACK makes something a toy. i noted that most of the audio applications for linux are (1) written to use OSS and (2) are toys. there are thousands of links to such programs on dave's pages. the toys are fun, and often very useful. however, they are not viable candidates to act as the basis of SOPME/RTP for most people. But are commonly used in educational institutions for professional music making purposes. Besides, please define most people. I clearly see split on this list in terms of interests, so at best it's 50/50. why should i be doing *anything* for users who aren't interested in paying me, aren't interested in what i'm interested in, and keep telling me they want things that i can give them but don't like the package it comes in? Who said anything about you being the one who develops all this? What I did say is that you should not propagate the idea that Jack is never going to be an all-purpose sound daemon, when it is clear it could fulfill that purpose. In the end, it should be user's choice what they will do with it. Besides, I'd gladly poll my resources to add this feature to Jack, but the elusive alsa-server is in existence only in these discussions, alsa docs are still skimpy, and on top of that I do need to familiarize with the Jack's framework before I can contribute anything. Now why would I contribute to a project that you are so strongly trying to separate from having
RE: [linux-audio-dev] Re: image problem
This is a fair question. First, many people might promote OSS, but that doesn't mean unconditional surrender. ;) I mean, I was really quite offended by Ivica's message where he proposed that JACK developers are arrogant if they don't implement x and y. OSS or not, that's not very nice considering how much free time we have spend on this. And what do you think how do I feel when I contribute to this community with my apps (which certainly are nothing even close in scope or quality to Ardour, but are my best and most honest shot at it), spend most of my time promoting Linux, conceiving a Linux Multimedia class at my University and teaching it, convincing my mentor that the Linux is the way to go by purchasing new Linux machines, and evangelizing Linux/Alsa/Jack among my peers, and all this without any compensation whatsoever? Do you think my time is any less valuable than yours? Besides, I was, and still am the advocate of Alsa. But even Alsa supports OSS apps (to some extent), so I have no clue as to why you are placing me in the OSS camp. If you read my post carefully, you'd realize that I am talking about good quality apps that will simply not be usable with Jack framework which is a shame, and as such would limit user's ability to unlock the full potential of Linux audio... The arrogance I spoke of you managed to misinterpret rather well. What I spoke of is the fact when addressing this issue to Jack developers, you get cornered into a situation where you are damned if you do present the issue, and damned if you don't while at the same time Jack developers simply suggest the impossible: why don't you port all those 1000+ apps to Jack? So if I come out with a suggestion, then I get flamed all over for it, but if I keep quiet, then I cannot use it for what I need it for. If that did not come of as described above, then I do apologize. Every wish for contribution that came from my mouth was in a form of suggestion/criticism/request for a feature, because that is the most comprehensive and quickest way of presenting the case. After all, stroking egos will not make Jack any better... Every one of those was met with a strong opposition and defensive behavior. I want to contribute, but if the project developers to whose project I want to contribute to marginalize my suggestion for contribution, then what's the point? Ico
RE: [linux-audio-dev] Re: image problem
You're right, I need a coffee break :-). But before I do that... i think everyone appreciates food for thought, but (at least to me) the wording of some of the opinions in this thread was rather suboptimal and might easily provoke some strong rhetoric in defense. let's just all take a deep breath and stop the jack bashing. No one is bashing jack and constructive criticism never hurt anyone. Just because it's not shrink-wrapped with cherry and whipped cream on top, it does not mean it's somehow geared towards bashing. If I had time to talk with Paul in person, I am sure I'd choose a smoother way of expressing my concerns. But on mailing lists, I don't have the time to proofread and make every statement of mine a Shakespearen creation of thousand words. (yet I am here ranting and ranting away... oh, well...) this thread has some ugly similarities to the reborn flamefest and that curious religious EULA of nasca's synthesizer: it's criticizing *people* for something we wouldn't even have if not for those very same people. I am thankful for Jack, but at the same time that does not mean there should be no criticism. If you are referring to me criticizing Paul's statements, then how do we dare criticize Linus Torvalds for letting OSS happen? After all, he is the one who made Linux, without him Linux would have never been. And since we use it, should we simply shut up and use it with OSS? ;-) Now, onto that coffee... Cheers! Ico
RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
On Mon, 21 Oct 2002, Paul Davis wrote: So why, having studied the docs, am I completely stumped with jack? It refuses to play. I don't consider any solution based on a piece of software _I_ can't operate suitable for general use. JACK *isn't* intended for general use, and i get tired of suggestions that it should be. there are lots of people working on solutions for general use. JACK is intended for people who are serious about audio. in particular, although it might work with crappy consumer audio interfaces, its not intended to do so. if you can't run JACK at all, you basically have a box that wouldn't run an ASIO device driver under windows or macos. So, in essence Jack is yet another ASIO wannabe. If I wanted ASIO, I'd be working on Windows or MacOS. What about making it more like Core Audio on steroids where everything can be low latency, or high latency, where USER HAS THE CHOICE? This Jackd is only for pro's sounds too much like Apple die-hard fan zealotry to me, something that I readily detest. there's not much we can do about that except to point you at kernel adjustments (like hdparm) and ask that you check other mailing lists to see if your audio interface, video interface, etc. are known to be horrible in some respect. JACK is not yet finished, and it has some definite usability issues that need to be resolved. but it is not, and i hope will never be (primarily) a general purpose sound server. alternatively, there might be a bug in JACK. perhaps you can help us find it. --p And as long as you view JACK as that, it will have a very small user base and hence very small pool of audio apps that will support it. All this will lead to the fact that, no matter how good JACK is (or is supposed to be), it will be always a questionable solution, since a lot of good PRO apps (contrary to your definition of OSS-based toys in one of your previous e-mails) do not, and will not support it (i.e. RTcmix) [either due to fact the apps are not being constantly updated any more, or maybe the developers are skeptical about porting to Jack when there are so few apps ported into its framework], while a few PRO apps (i.e. Ardour) will. This will create an unnecessary polarization in an already heavily fragmented audio community (oss vs. alsa, esd vs. asd vs. artsd vs. gstreamer vs. jackd etc.). Linux is supposed to be all-inclusive and free. Most of us in Linux strive to make everything work under it both hardware-wise and software-wise, as well as being backwards-compatible. Yet, in this case if the audio app does not support JACK, then it's either a toy or basically whomever wants to use it is screwed and has to make a choice whether to use jack-based apps or work with oss drivers coupled with some kind of artsd high latency daemon (that at least let's you do multiple opens in software or select mic inputs on the mixer -- something that is not the case with Alsa + artsd). I do not want to have my artistic ideas limited by the questionable software limitations. Do you? If you really want the JACK to take off, then you should look not only forwards, but also backwards, and find a relatively viable solution (even if it is at the expense of the latency) that will work with 1000+ decent apps that have not been ported to JACK framework, thus leaving the issue of latency for the user to choose. And if the only explanation to this problem is they need to port their apps to JACK, while there is no effort to meet the user needs at least half-way by offering an easy interfacing for apps that may not be ported to JACK in the recent future for whatever reasons, then I see that as sheer arrogance. I am not only interested in using Ecasound, Ardour, FreqTweak, and Pd for my music making purposes, neither is a majority of other Linux users. Case and point, I may want to use ardour, but if I take a break and want to listen to some mp3's on an un-jackified player (such as xmms, for instance), how user-friendly would it be to have to save session, close ardour, close jackd, and only then start xmms, and then after 10 minutes do all that in reverse? Why couldn't xmms simply connect automagically to jackd by jackd detecting simple oss-open-dsp-resource call? If it isn't user-friendly, who will want to deal with it, except for Linux die-hard fans (one of them being myself)? Even you mentioned your intentions of selling ardour-installed computers. Who will want to deal with all this configuration crud? People in studios do not want to hear about jackd -d alsa or hw:0,0 crap, nor do they want to buy a computer that will do only ardour. They just want it to work, and while working on pro audio software, they may still want to hear audible alerts that their laptop is running out of battery or that they have a pending appointment. Instead they will get mind-boggling errors, such as /dev/dsp resource busy, and similar junk... Neither will the commercial companies want to touch
RE: [linux-audio-dev] Quick and efficient sound daemon idea -- why not do it this way?
First off, thanks for the reply... i don't understand why you keep asking about this when esd exists and when abramo has already written the mix plugin for alsa-lib? if you don't like the qualities of esd, why not take that up on the development list for esd? Because esd is dead (or just about there). if you want to try out the mix plugin, why not write to abramo and gently nag him to do something with it. Ahhh, the ominous mix plugin... You said it yourself the best -- Abramo is the only one who knows how to get it to work, and in such state it is as good to me as a Porsche my next-door neighbor has. Sarcasm aside, esd sucks -- introduces all kinds of pops and clicks when engaging a new stream or disengaging streams, artsd cannot share the input (or at least I was unable to get it to do that), and does not work with all apps across the board (esp. when it comes to input sharing), Jack works only with Jack apps and from what I heard, does not tolerate many simultaneous apps running concurrently, furthermore it permanently drops a stream if it is late for whatever reason, which basically means it is useless for the real-time performance (last thing I need in the middle of the concert for JACK to drop one of my streams -- assuming I am only interested in using JACK apps, which is a huge assumption in itself), and this mix plugin is yet to be seen at work. I have no idea why you are mentioning Portaudio, when it again introduces a problem of porting apps into its API, and that again poses the same problem of excluding a lot of older audio apps that do not have that framework implemented. So, yes, sigh, I am discussing something that has been addressed a million times (prolly 999,999 out of those were initiated by me :-), but with a reason -- regardless of recent developments, things are still NOT working in the Linux audio world on one of the most fundamental levels... Regards, Ico
[linux-audio-dev] Quick and efficient sound daemon idea -- why not do it this way?
OK, here I go ranting about the same thing again... Can't help it :-), tired of fighting the issue. :-( Here's a simple proposal that I have been thinking of (even though my computing skills are not so good when it comes to system stuff), and you please tell me whether this is a good idea: There should be just a simple sound daemon running 24/7, constantly reading from the /dev/dsp inputs and writing into the outputs with a small circular buffer that keeps on recycling itself (i.e. 64 bytes to allow for low-latency work if needed). Then, when an app that does not care at all what is behind the /dev/dsp resource, addresses the /dev/dsp resource, it gets rerouted to the appropriate buffers provided by the sound daemon. This way, infinite number of apps could read and write into the same buffer, (writing being a bit trickier to do obviously) and being down-mixed in software. If the app works with larger buffers, it just simply reads off of the buffer longer and by the same token writes into the audio buffer as needed (daemon would adjust incoming buffer to app's needs by reading its OSS or ALSA request for the audio buffer). Now, someone please tell me why is this not doable? Sound daemon must be, at least in my mind, compatible with all software, and the only way it can be that is by making itself transparent. Therefore there would be no need for JACK-ifying or ARTSD-ing of an app. It would simply work (a concept that we definitely need more of in the Linux world). I am sure that with the above description I have covered in a nutshell both JACK and ARTSD to a certain extent, but the fact remains that both solutions require application to be aware of them if any serious work is to be done. And as such, there is only a VERY limited pool of applications that can be used in combination with either of these. Any comments and thoughts would be appreciated! Sincerely, Ico
RE: [linux-audio-dev] Needing advice on implementing MIDI in my app (RTMix)
Thanks for a quick reply. One more question: 1) Is there good documentation to be found, or even better, source code? 2) Can I use DMIDI in combination with TCP/IP (I saw you mentioned UDP on your site)? 3) Does application have to be DMIDI-aware in order to be able to send/receive MIDI via DMIDI server or does DMIDI server simply act transparently between sender and receiver (if they are presumably on the same machine)? Again, thanks for your help! Sincerely, Ivica Ico Bukvic -Original Message- From: Phil Kerr [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 10, 2002 9:49 PM To: Ivica Bukvic Subject: Re: [linux-audio-dev] Needing advice on implementing MIDI in my app (RTMix) Hi Ivica, DMIDI may be of some use to you. You can have one DMIDI server and your MIDI applications can broadcast DMIDI data. You use the server to isolate you from hardware and MIDI API's http://www.dmidi.org Cheers Phil
[linux-audio-dev] Needing advice on implementing MIDI in my app (RTMix)
Hi all, Currently, I am working on implementing MIDI in my app, and this is what I am currently trying to solve: I just simply want to implement MIDI not as a sequencer, but rather as an external controller of various events (since this is what my app RTMix does). Now, the problem is also that I want to use MIDI for intercommunication between my app and other apps running concurrently on the same machine (i.e. Pd), so here is the list of questions I would greatly appreciate any help on: 1) First off, is there a simple GPL library that is easy to implement and that focuses on MIDI? If not, any website with some sample code would be greatly appreciated! 2) I am trying to design something that is not driver specific (i.e. OSS or ALSA), so is there any way to do this (i.e. sending message directly to /dev/midi device or something similar without blocking it to other apps) 3) For checking the presence of the midi interface on a Linux box, is it safest to look for /dev/midi device, or is there a nicer way? 4) Is there a way to send MIDI data in such a way that it is perceived by other app on the system (i.e. like sending a midi signal through midi-out which is via cable connected to midi-in on the same machine, except without doing so physically)? If so, how? If not, what are the alternatives (other than above-mentioned physical solution)? 5) Finally, this may be a bit far-fetched question, but here it goes anyhow: does anyone know if Pd and other applications like it are able to receive simple numeric messages via network (TCP/IP) protocol (since this would be an alternative to #4)? Any help on this matter is greatly appreciated! Sincerely, Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God
RE: [linux-audio-dev] Notation program.
To me it seems like you do not have to have an application aware of pitches (unless you feel uncomfortable using conventional notation for custom-assigned pitches -- i.e. c is c, c# is a bit flat, d is more like c# etc. so you'd need 2 conventional octaves for one 24-pitch microtonal octave). Many contemporary composers do this -- alter existing notation so that it can serve their purpose. Assuming from your e-mail is that you may be comfortable with modern notation, so I'd suggest simply using external midi module where you'd edit the sound patches to have this kind of detuning, or even better a sampler of some sorts. Then, you'd simply pass a conventional midi file to hear gamelan-like tunings that are produced by the external midi module (or any other tunings for that matter). That being said, I do agree with you that this would be a neat feature within a sequencer without continuously employing fixed pitch-bend wheel values. Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ [EMAIL PROTECTED] To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God One thing lacking on any platform is notation software with user adjustable pitch tables that supports midi tuning standard. I have a lot of experience working with altered tunings and pitch tables studying balinese gamelan, my C/C++ skills still suck right now, but I sent my girlfriend away for the weekend just so I can work my way through the rest of oreilly's practical c.
RE: [linux-audio-dev] a brief update and a request
Btw, any news about RTmix ? Best regards, == Dave Phillips The Book Of Linux Music Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://linux-sound.org Working on it as we speak :-). Should be releasing source code and the binary version 0.20 soon. Sincerely, Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ [EMAIL PROTECTED] To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God
RE: [linux-audio-dev] a brief update and a request
Hi Dave, Just a thought: A section on interactive electroacoustic music and its tools would be also interesting since that area is steadily growing in its popularity. Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ [EMAIL PROTECTED] To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God -Original Message- From: [EMAIL PROTECTED] [mailto:linux-audio-dev- [EMAIL PROTECTED]] On Behalf Of Dave Phillips Sent: Tuesday, July 16, 2002 2:56 PM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] a brief update and a request Andy Wingo wrote: 1) The use of jack to link together sound apps -- a universal transport control This area is not often explored in practice, so you might be on the cutting edge, so to speak. It does have a lot of promise, though; the trouble is that often, apps just connect directly to the sound driver. While that's a nice defaut behaviour, often it would be useful to have to option to leave ports disconnected. I digress. A few quicktoot-style tutorials on getting things done with the alsa seq and jack would be most useful. I agree. I'm following Ardour and JACK development, they will definitely get coverage. I like your example suggestion, so something like that will be added. 2) GStreamer Count on it. It's in the list... :) It's pretty amazing to look back over the last two years and see how much good software has evolved since the 1st edition. Very inspiring... Well, whatever you choose to include, I'm sure it will be a nice improvement on the already nice first edition. Thanks, Andy, and thanks for the suggestions ! Maybe a section on making the transition from windows or mac to linux? That would be neat. Another good idea. I certainly get a fair amount of mail from people looking to make the switch, I might as well codify my responses... ;) Best regards, == Dave Phillips The Book Of Linux Music Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://linux-sound.org
RE: [linux-audio-dev] Poll about linux music audio app usability
In reply to the 'not having the same sound as everybody else', I think this is a question of how you use software and not what you use. You can play a million things/styles etc on a guitar. The same goes for software synths etc. Yes, but guitar still sounds like a guitar (with the exception of the extended performance techniques and guitar preparation), acid loops still sound like acid loops, and DX-7 synth patches still sound like DX-7 patches. Keep in mind that software is not musical style (i.e. rondo vs. waltz vs. rap vs. rock etc.), but that software is an instrument. I am not trying to say that each person's music does not have that grain of individuality but rather that by using more-difficult-to-use software, I am likely to use tools that are less used by others, hence my music has a greater chance to sound unique. Try listening to some of the academic electronic music and see just how different it is from everything else out there. The truth is we will never have all the apps that are available for windows ( unless commercial software becomes a happening thing ). But if we are prudent we can focus on the core type apps and frameworks. I disagree. Time works for us, not against us. Open source apps have the great advantage over the commercial offering in that they can be updated indefinitely by a huge number of developers -- and every time they get updated, they become [mostly] even better. Commercial apps do not have a secure life span and a lot of developers have to reinvent the wheel due to closed-source nature of commercial software. For instance look at opcode's Vision DSP (one of the first versatile pro Midi/Audio Studio solutions), it's dead now since the company is out of business, and all their effort and money spent for it is now completely useless, since app will never have its source code released nor ported into anything beyond OS 9). What we really need in Linux is already happening, and that is a dedicated group of developers working on versatile tools within an open-source framework. Ico
RE: [linux-audio-dev] Poll about linux music audio app usability
I read: What tools are you talking about? I mean, I own both PCs and Macs, and except Digital Performer I don't know about any other major package that only exists on the Mac. max/msp supercollider regards, x Except that max/msp is coming to Win platform this fall (and besides there are better alternatives to this app on Linux/win platforms i.e. Mix24 (or something like that, forgot the name), Eyesweb, Glame, pd, jmax, Visual Orchestra etc.), and Supercollider has gone open source so it should be available on Linux platform (and possibly Win platform as well) rather soon (for alternatives see Rtcmix, Csound etc.). Ico attachment: winmail.dat
RE: [linux-audio-dev] Poll about linux music audio app usability
However, forgot to mention, that it would be still nice to see user-friendliness become a standard in Linux ;-) -Original Message- From: Ivica Bukvic [mailto:[EMAIL PROTECTED]] Sent: Monday, June 10, 2002 1:42 AM To: '[EMAIL PROTECTED]' Subject: RE: [linux-audio-dev] Poll about linux music audio app usability What I think is that this is great since there is less likelihood that someone else will be using the same tools I do and hence less likely will my music sound like thousands of others :-) Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ [EMAIL PROTECTED] To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God -Original Message- From: [EMAIL PROTECTED] [mailto:linux-audio-dev- [EMAIL PROTECTED]] On Behalf Of Juan Linietsky Sent: Monday, June 10, 2002 1:10 AM To: [EMAIL PROTECTED]; linux-audio- [EMAIL PROTECTED] Subject: [linux-audio-dev] Poll about linux music audio app usability I thought this may be of interest to the list. In a k5 poll about usability of linux audio apps, ( http://www.kuro5hin.org/poll/1023512126_OSelOkZS ) So far, out of 38 answers the results are: -How do you like music software for Linux? 2 % - Great! It has everything I need. 13 % - Good, but i wish apps were more userfriendly (Like Reaktor or SoundForge) 31 % - Could be better, I think the apps are not yet mature enough for my needs. 15 % - It's unusable, the apps plain suck. 10 % - Dont care about composing on computers 26 % - Dont care about composing. I think this raises some questions.. My feeling is that most people aiming to write music on this OS is expecting to have apps with super easy and intuitive interfaces, where you only go trough displays, knobs, sliders and paintabe areas. Why we dont have apps such as Reason, Reaktor, Sonar, Sound Forge, etc? I dont mean full apps, but at least projects aiming for that kind of thing. We do have very powerful tools, but i have to admit that for most of them we have to learn some script programming. Do we lack good APIs? Alsa MIDI api is the best I have seen for it's kind. Also, sould linux apps really take this windows approach of making huge bloated interfaces with lots of eye candy, or should we try to improve on making our apps intercommunicate between eachother, while still giving some importance to ease of use? What do you think about this issue? Juan Linietsky
RE: [linux-audio-dev] softwerk binary available for testing
Hi Paul, can you hook me up with a tarball so I can beta-test it. Also, if you can describe it in one sentence, since I've not been keeping up with the LAD list lately. Too busy :-( Thanks! Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ [EMAIL PROTECTED] To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God -Original Message- From: [EMAIL PROTECTED] [mailto:linux-audio-dev- [EMAIL PROTECTED]] On Behalf Of Paul Davis Sent: Sunday, June 02, 2002 10:09 PM To: [EMAIL PROTECTED] Subject: [linux-audio-dev] softwerk binary available for testing I have an initial binary release of softwerk available for testing by some hardy souls. Its statically linked against all C++ libraries, so all you need installed is GTK+ and glibc. That's the theory anyway. If you'd like to try it out, send me email. I have only minimal docs for this release at this point, but I want to check that the binary build will at least work for other people before moving toward RPM, deb and so forth. Note: you do not need ALSA installed. --p
[linux-audio-dev] icube question
Hi all, a couple of days I posted a question regarding icube and Paul's controller, but at this point I am not sure whether it had even reached LAD mailing list since I did not see it on the archives, nor did I get any response. So, I apologize if I am sending this for the second time: My problems is that icube controller for linux simply does not want to compile with current ardour's libs (which were originally found in the Quasimodo package). So I am just wondering if there is anyone out there who actually was successfully at compiling this one and if so, if they would be kind to give me some pointers. I have currently Ardour installed on a MDK 8.1 box which runs ok (it's one of the at least 2 month old cvs builds). So, I know for a fact that I have successfully compiled the libs that are required by the icube app, but somehow icube app at the configure time complains about either lack of those libs or them not being sane. So my other question is what does it mean to have a sane lib? Anyhow, any help is utmostly appreciated! Sincerely, Ico
[linux-audio-dev] [OT] Can RME HDSP Multiface be used for 5.1 Dolby or 7.1 DolbySurround output?
Hi all, I was just wondering if RME Hammerfall can be used for Dolby surround output via its optical (SPDIF) output going into an AC-3 decoder. Is this something that is supported in the current drivers (in Win/Mac obviously since Linux drivers are not ready yet)? I am asking this since I am wondering whether it is cheaper to buy one of those ac-3 decoder sets that come with speakers or buy speakers separately (i.e. 8 powered speakers or 4 powered stereo pairs). If this is not the case, then what is the most cost-effective way of getting 8 (preferrably powered) speakers so that the Multiface can be used for making/listening to 8-channel music. I looked so far at Roland MA8 speakers (which are $80 per pair) and Roland MA110's which are $120 per pair on the internet. Is there a better solution for this kind of arrangement if I wanted to have 8 speakers that are not necessarily high quality (but are acceptable) and do not require separate amplifiers (cost is what matters the most, but also the quality to an extent where they are still relatively cheap)? Your suggestions/thoughts on this topic would be utmostly appreciated! Ico
RE: [linux-audio-dev] SuperClonider
Now OS-X really is a great OS, maybe the best commercial OS now available. It's stunning, how they build an intuitive Desktop on a Unix-core, something that neither in Gnome nor KDE really worked (I'm still prefering the command line over those) While OS X certainly has its strengths, I consider it far from being the best commercial OS. Maybe in terms of eye-candy. I find both XP and KDE much more user-friendly desktops than Aqua in terms of productivity: both Win and Linux OS's much more responsive (primarily due to hw architecture they run on). The thing with both KDE and Gnome is that they are not pretty out-of-the-box, but one can create very nice desktop environment with them with a bit of tweaking. Yet, my desktop is relatively plain since I simply look for productivity (i.e. virtual desktops rather than transparent windows). Aqua is rather over-bloated. Case-and-point, try to run one of the developer OpenGL examples (even simple ones, like rotating cube) and once the window is created, try to move it behind the transparent dock and you'll lose approx. 60% of the window's framerate, needless to mention up to 100% CPU utilization every time you do that pretty minimize-window animation... Also, in terms of being Unix, well it's not quite fully Posix compliant since (just to give an example) shell does not distinguish between capital letters and small letters, i.e. make a folder foo, and you can cd into it by typing cd FOO, foo, FoO etc. This has resulted in several Apache security loopholes that Apple had to patch up and only Lord knows how many more remain due to this kind of implementation... So, it's not Unix, it's not old Apple, it's not BSD, and it's not NEXT, so what the heck is it? ;-) Ico
[linux-audio-dev] [OT?] Yet another question regarding RME HDSP driver status
I guess this question is geared mostly towards Paul Davis and potentially Guenter Geiger. I was just wondering how was the Linux driver progressing (if at all) and if we should have something working any time soon. I offered a while ago my help to Paul (although my driver knowledge is as good as flying Space Shuttle :-) I would be more than willing to provide my humble assistance), but it seems like he has it all under control. I am primarily interested in Alsa version of this driver, but if there is an OSS one already working I'd be interested to test-drive that one until Alsa becomes available. So, my apologies for pestering everyone over and over with the same question, but I was just wondering to see whether there is any chance of getting my Multiface to work with my Linux laptop any time soon (i.e. before summer)? Any info would be appreciated! Sincerely, Ico
[linux-audio-dev] low-latency and pre-emptible patches in coexistence... check out this interesting article!
Slashdot just posted an interesting article on preempt and low-latency patches and their performance. It seems the best results are when both of them are applied. This might be old news for some of you, but I still feel that many will benefit from this article. Check it out here: http://www.linuxdevices.com/articles/AT8906594941.html Enjoy! Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ [EMAIL PROTECTED] To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God
[linux-audio-dev] [OT] urgent question regarding qwt widget set -- any help would be greatly appreciated!
I apologize for the somewhat off-topic question, but I've been struggling with this issue for the past week and am on top of that in a rather big time crunch, so I would greatly appreciate any help I can get on this one. I am in a need of a graphing widget that is capable also of taking in the input. I am also interested in developing strictly under qt. So, naturally qwt widget (http://qwt.sf.net) was my choice. But, the problem is as follows: I've tried both 0.3.0 and 0.4.0 versions and both have the same problem. I've tried them on RH 7.1, RH 7.2, and MDK 8.1 distros on different machines using different hardware. I am using KDE desktop, so I even tried different themes and styles thinking that could be the source of the problem. All of these issues pretty much eliminate the possibility that it is something to do with a particular distro or a hardware. The only thing that was semi-constant on all three tested machines use Qt 2.3.x (RH 7.1 x=0, while RH 7.2 and MDK 8.1 x=1). Anyhow, the problem is that all examples compile flawlessly and qwtplot looks just fine, but any other widget (i.e. radio buttons or sliders) using those tick marks and values have those parts of the widgets completely black! I have no clue as to what is the problem, but no errors have been reported and the widgets do work, just that the tick marks and their respective numbers do not show in all of the widgets except for the QwtPlot which has these as a part of the widget. I have no clue as to why is this happening, and I even tried disto-specific RPM's with no success. I am hoping that some of you had some experience with this one so that you may be able to help me. I would greatly appreciate any help I can get on this issue. Thank you very much! Sincerely, Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ [EMAIL PROTECTED] To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God
RE: [linux-audio-dev] one for the C++ gurus
Hi Dave, This may be a bit off-topic solution to your problem, but there is a more look-alike port of Rt done by Doug Scott. It uses a Vievkit and looks identical to the old Rt. If you want to contact him, here's his e-mail: Netdscott at netscape.net Ico
[linux-audio-dev] question regarding an alternative to the RME's PCI-to-Multiface card
Hi all, I was just wondering how could I cut the costs of obtaining one of these awesome multiface cards that could be used for both desktop and notebooks. So, I came to conclusion that I would need obviously PCMCIA HDSP and Multiface itself, but then when I looked into the PCI card for it, it seemed kinda expensive. So, I looked online and found this: http://www.amtron.com/reader/pc750.htm Could someone tell me whether this will be less efficient than the Rme's PCI solution and whether it will be even worse than notebook PCMCIA performance? Your help would be utmostly appreciated! Sincerely, Ico
RE: [linux-audio-dev] question regarding an alternative to theRME's PCI-to-Multiface card
Thanks for the reply. So, what you are saying is that if I buy one of the back-loading interfaces that support cardbus (32-bit) interface, I should have the same performance as on the notebook's pcmcia cardbus, right? Also, is there any solution out there that offers front-loading through 5.25 bay? My understanding is that the cardbus (32-bit cards with gold plating on the tip) cards cannot be utilized due to length of the IDE cable that connects the PCI card with the reader drive. But, what if the reader contained all the reading hardware so that the IDE cable would be theoretically then replaced by a faster interface (i.e. firewire) and connected to the on-board pci card? Is there such a thing that is still affordable? Ico -Original Message- From: [EMAIL PROTECTED] [mailto:owner-linux-audio- [EMAIL PROTECTED]] On Behalf Of Erik Walthinsen Sent: Monday, March 11, 2002 4:29 PM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] question regarding an alternative to theRME's PCI-to-Multiface card On Mon, 2002-03-11 at 12:38, Ivica Bukvic wrote: Could someone tell me whether this will be less efficient than the Rme's PCI solution and whether it will be even worse than notebook PCMCIA performance? This is a PCMCIA adapter card, whereas the RME card is guaranteed to be CardBus. PCMCIA 'is' ISA, whereas CardBus *is* PCI. CardBus adapter cards start at about $70 and go up from there. I know, I've been looking for *any* adapter that can take a 3.3v PCMCIA (not cardbus) card, and it seems that only CardBus adapters will do so (without hardware mods). http://www.amtron.com/reader/pcdrp101ce.htm Erik Walthinsen [EMAIL PROTECTED] - System Administrator __ / \GStreamer - The only way to stream! || M E G A* http://gstreamer.net/ * _\ /_
RE: [linux-audio-dev] ALSA vs OSS/free
Since we are talking about this [non]issue, again, I just realized that there is one thing I am still not able to comprehend completely, so I would greatly appreciate any thoughts on this one. It is no rocket science to figure out that Alsa is the way to go, and I am all for it. But one thing I do not comprehend is why is the user-space driver better than the kernel space one? Is it because this way kernel will eventually become more stable and more compact having all drivers loaded outside of the kernel space? (I'd assume yes, but please correct me if I am wrong) Also, in which case do you get better latency and overall system performance (I thought that if something is run in kernel-space that it gets higher priority, if so, won't this kind of move of making all drivers outside the kernel space, make Linux slower?)? Finally, is this because Linus wants to eventually get to the point where kernel won't require any more alterations, and where all the external modules will be developed and/or loaded as needed? (Again, I'd assume this is one of the important reasons, but please correct me if I am wrong) Any thoughts would be greatly appreciated! Sincerely, Ico
RE: [linux-audio-dev] ALSA vs OSS/free
Kernelspace is the worst possible place you can ever do that. Thank you for your thoughts regarding this issue. Still, you did not answer the most important part of the question: why is that so? Ico
RE: [linux-audio-dev] ALSA vs OSS/free
ALSA isn't a user space driver. Its a kernel space driver that comes with a user space library. The library has several purposes: 1) hide hardware specific details that are represented at the raw device level (i.e. via /dev/snd/...) 2) encapsulate common operations (e.g. rate, format, channel conversions) done by applications 3) provide high-level functionality, such as device sharing, channel mapping, and so forth 4) provide named identifiers that describe not just the hardware associated with a device, but various software characteristics. for instance, the hardware might have 3 different PCM outputs (e.g. analog, ADAT, S/PDIF) - the name might refer to just one of them. this avoids every ALSA program from developing its own way of having the user specify which attributes of a hardware device, or which configuration, they wish to use. when aplay is used with -D trident and jack is used with -d trident, the name trident refers to a centralized resource described in ~/.asoundrc (and/or the system-wide equivalent) You can use ALSA without using alsa-lib. If you do this, you lose all the functionality of alsa-lib, and are presented with a set of device drivers that mirror whatever the underlying hardware can (or cannot) do. You will not be able to deliver non-interleaved samples to consumer hardware. You will not be able to use 24 bit samples on 16 bit hardware. You will not be able to split a multichannel device into several fake devices. And so on. Very few people want to use this kind of interface, at least not by default. ALSA will allow you to be limited in this way if you wish, but it doesn't force it upon you. The reasons for moving so much functionality into user space (rather than putting it all in the kernel, so that /dev/snd/foo does everything all by itself) are: 1) allows use of floating point operations (not allowed in the kernel) 2) code runs with regular user scheduling, not kernel space scheduling (this affects a few parts of how the scheduler sees things) 3) avoids putting often tricky and buggy code in the kernel, where debugging it is much more complex. 4) allows upgrading and bugfixes without changing kernel versions (for people not using modular drivers) 5) the kernel is supposed to provide mechanism for things that require priviledge to do, not policy and not mechanism for things that can be done from user space. 95% at least of the code in alsa-lib is about simple mechanisms that are provided by the code's functionality (no priviledge needed). --p Thanks! This explanation did the trick for me. Now, I feel enlightened. ;-) Ico
[linux-audio-dev] Interesting info regarding RME Hammerfall DSP and Steinberg
Hi all, Just wanted to share some interesting news with all who are still waiting to obtain one of these beasts (Hammerfall DSP) and have been waiting for a long time (like myself). I just found out from talking to a RME US reseller that Steinberg sells exactly the same hardware for a lower price. Check this one out: http://www.nuendo.com/hardware/audiolink96.html This comes like a God-sent deal since RME has just decided without any prior notice to raise prices on their already hard-to-find and heavily backordered RME cards for the US market... One thing I am not sure of though, is what is the actual availability for these and whether they are affected by the same shortage like RME's cards are. This source also told me that the same drivers should work for both cards, and that the only difference is the sticker on the outside. DISCLAIMER: Since we live in a highly litigatious society I will have to bore you with the following paragraph: please understand that you should not make any rash choices based on what I've stated here, since I will not be held accountable for any kind of crap that could potentially result from your decisions. We are all grown-ups here (or at least I hope so ;-), and so we should all know better and do the research on our own before taking anything for granted... Now, that I've shielded myself from potential accusations, my suggestion is to research this thing before moving on any further. I honestly do not know if all this is 100% true, but the pictures on the above website surely do show tremendous resemblance... Ico
RE: [linux-audio-dev] OT: Need Help Making a List of the Linux Multimedia Community
Hi, I would greatly appreciate it if you would add my RTMix app, available on my site at http://meowing.ccm.uc.edu/~ico/ Thanks! Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ [EMAIL PROTECTED] To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God -Original Message- From: [EMAIL PROTECTED] [mailto:owner-linux-audio- [EMAIL PROTECTED]] On Behalf Of Charles Iliya Krempeaux Sent: Monday, March 04, 2002 7:50 PM To: [EMAIL PROTECTED] Subject: [linux-audio-dev] OT: Need Help Making a List of the Linux Multimedia Community Hello, I'm making a list of the Linux Multimedia Community (for a separate project). I'd appreciate it if the subscribers of this mailing list could help me find more communities/software/links/etc to add to the list. And make the list as complete as possible. I've put my current list at: http://matterial.ca/temp/linux-multimedia-community/ (The list is in alphabetical order.) Basically, if you could, please look to see if I'm missing any Linux Multimedia Software, Communities, Websites, etc. And if I am, please e-mail me, and let me know. (The easiest thing to check is to see if your own project... if you have one... is listed on the list.) TIA See ya -- Charles Iliya Krempeaux tnt @ linux.ca ckrempea @ alumni.sfu.ca 604-306-8909 __ Do you have your art matterials? http://www.matterial.org/
RE: [linux-audio-dev] OT: Need Help Making a List of the Linux Multimedia Community
Crap, sorry all for replying to wrong e-mail and cluttering your inboxes :-( Ico
RE: [linux-audio-dev] updated snd - where?
That version can be built from the sources. It's dependent on Motif (not LessTif), though Bill is working on a GTK version too. More information on prettifying Snd can be found here: http://linux.oreillynet.com/pub/a/linux/2001/10/05/snd_partone.html Some of that information has been outdated by recent development, so feel free to write to me if you're not sure how to set it up. Best regards, == Dave Phillips Thank you very much for the info! Ico
[linux-audio-dev] [OT] Problems with RME9652 (Hammerfall) -- I would greatly appreciate any help I can get
Hi all! I just finished installing the new RME Hammerfall in one of the studio's Linux boxes. The install went fine and I managed to load the driver. The problem is that I cannot get the mixer to have any elements (or elems as the alsamixer calls them) which thus makes it un-openable even with the alsamixer. Since some of you on this list have been using this card for some time (heck, Paul is the author of it, so who would be better to ask than him? :), I would greatly appreciate it if you could help me solve this issue. Here's the breakdown of the stuff I did, as well as logs of the current system's state and configuration: The most important thing is that I have rme9652 (Hammerfall) hooked-up to the two RME-brand AES/EBU 8i and 8o brackets which are mounted inside the computer. So, I am not using any kind of external D/A converter. From what I could understand from my previous correspondence, this should still work under Linux. So my first batch of questions is: 1) Is there anyone else out there using AES/EBU 8i/o brackets in combination with Hammerfall under Linux? 2) What are limitations of this kind of D/A conversion, as opposed to the external D/A converter? 3) My green led light on the additional bracket that has WC in/out (it came with the soundcard) is off. Is this ok? My system is Dell 4100 P3 933Mhz with 256MB RAM, Geforce 2MX, PCI 128 as my (temporarily) primary soundcard, rme9652 with 2 RME-brand brackets (Input and output, 8 channels each), 3com 10/100 network card, IDE HD etc. I am running MDK 8.1 (2.4.8-26 kernel without any modifications). Sound-wise, I am using latest Alsa (0.9beta10). Here's my alsa-related portion from the /etc/modules.conf: # ALSA portion alias char-major-116 snd alias snd-card-0 snd-card-ens1371 alias snd-card-1 snd-card-rme9652 # OSS/Free portion alias char-major-14 soundcore alias sound-slot-0 snd-card-0 alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-service-0-8 snd-seq-oss alias sound-service-0-12 snd-pcm-oss alias sound-slot-1 snd-card-1 alias sound-service-1-0 snd-mixer-oss #alias sound-service-1-1 snd-seq-oss alias sound-service-1-3 snd-pcm-oss #alias sound-service-1-8 snd-seq-oss alias sound-service-1-12 snd-pcm-oss (I have commented sequencer aliases for the RME since it has none, otherwise I get errors when modprob-ing the module). When I do: #alsasound restart (or start if it is stopped) both drivers install cleanly (no unresolved symbols or any other kind of garbage) here's the list of the lsmod: Module Size Used by snd-pcm-oss38320 0 (autoclean) snd-mixer-oss 9008 0 (autoclean) [snd-pcm-oss] snd-seq-midi3520 0 (unused) snd-seq-midi-event 3280 0 [snd-seq-midi] snd-seq37488 0 [snd-seq-midi snd-seq-midi-event] snd-card-rme9652 15792 0 snd-card-ens1371 10144 0 snd-pcm49888 0 [snd-pcm-oss snd-card-rme9652 snd-card-ens1371] snd-timer 9776 0 [snd-seq snd-pcm] snd-rawmidi12192 0 [snd-seq-midi snd-card-ens1371] snd-seq-device 4080 0 [snd-seq-midi snd-seq snd-rawmidi] snd-ac97-codec 23632 0 [snd-card-ens1371] snd27360 0 [snd-pcm-oss snd-mixer-oss snd-seq-midi snd-seq-midi-event snd-seq snd-card-rme9652 snd-card-ens1371 snd-pcm snd-timer snd-rawmidi snd-seq-device snd-ac97-codec] soundcore 4208 9 [snd] snd-rme9652_mem 2208 2 [snd-card-rme9652] agpgart26752 3 (autoclean) NVdriver 724720 14 (autoclean) nfsd 70464 8 (autoclean) nfs75072 1 (autoclean) lockd 51440 1 (autoclean) [nfsd nfs] sunrpc 66480 1 (autoclean) [nfsd nfs lockd] autofs4 9600 2 (autoclean) af_packet 12560 1 (autoclean) ip_vs 62000 0 (autoclean) usb-uhci 21232 0 (unused) usbcore50752 1 [usb-uhci] 3c59x 25952 1 (autoclean) ide-scsi8096 0 scsi_mod 91072 1 [ide-scsi] rtc 5600 0 (autoclean) (the reason midi is unused is because my PCI 128 is OEM version without a gameport, but having it loaded should not pertain to my problem -- please correct me if I am wrong) my /proc/asound/sndstat looks like this: Config options: 0 Installed drivers: Type 10: ALSA emulation Card config: Ensoniq AudioPCI ES1371 at 0xdf00, irq 11 RME Digi9652 (Rev 1.5) at 0xfd00, irq 3 Audio devices: 0: ES1371 DAC2/ADC (DUPLEX) 1: RME Digi9652 (Rev 1.5) (DUPLEX) Synth devices: NOT ENABLED IN CONFIG Midi devices: 0: ES1371 Timers: 7: system timer Mixers: 0: mixer00 1: mixer10 Here, I can see that the rme is loaded and supposedly has its own mixer (please correct me if I am wrong). My /proc/asound/card1/rme9652 looks like this: RME Digi9652
RE: [linux-audio-dev] [OT] Question regarding multi-channel capable apps in Linux
Hi all, again. First off, thank you all for generously offering your suggestions. I do need, however to clarify a couple of things before this thread goes completely the wrong way. I am linux-literate, and I will gladly install Ardour because I know it's probably the best solution for my problem, but I am currently in a time crunch and am hoping there is something easier out there to install (I've received a reply Max Kovgan who said that Ardour is now available as a tarball. Is this true? About a month and a half ago, I spent 4 days trying to get Ardour working, just to end-up with a flashing window, followed by a segfault :-( (no pun intended, my assumption is that it was probably the compiler I am using -- 2.96). I am simply not aware what other apps are out there capable of similar things, and besides, I would like to provide a variety of multi-channel apps so that the students using the workstation have a choice. Let me try to clarify what I mean by things. I am simply looking for an app that can do somewhat similarly what Cool Edit Pro does, but ONLY in its multitrack mode (i.e. no sound processing stuff is needed). I understand I am aiming high, but I am just giving this as an example. Now, support for LADSPA would be a wonderful extra but is not a must, since in my studio students mostly do their sound processing prior to mixing when writing electronic music, so what they would use this app for is to mix all the pre-processed sounds in a final mix -- this means they need a relatively nice gui where they can use mouse for a most of the stuff (i.e. move sounds back and forth and into different tracks), possibly having visual representation of pan/volume envelopes. Mixmagic for linux is kinda close to this but I am pretty sure it does not support anything beyond Stereo spread (please correct me if I am wrong). I don't think this is off topic. It's my belief that a lot of musicians have this problem. You can shit on windows as much as you like, but it is very easy to use, and to install software on. It's time to start working on a LAD (Linux Audio Distribution :) or something like that. I know there is an initiative based on ?debian? but I don't know what the it's status is. It's called Demudi, it is currently in Alpha/Beta stage (visit http://www.demudi.org) and is currently waiting for people to commit themselves to maintaining audio-related packages. It's nice that we make great tools that can withstand the competition with commercial (windows) products (like Ardour), but what's the use if there is no easy 'framework' for the potential users? Such programs are pretty much unusefull if they can only be installed by people that are Linux expierenced. Paul Davis will (I am assuming shortly after Ardour is complete) start selling linux workstations with Ardour preinstalled on it, offering tech support as well. So, just wait for a couple more months and we'll be there... I can only illustrate this with my own experience: I have pretty extensive computer knowledge, and any windows platform is a piece of cake (not much credit to be taken there)... but Linux still requires quite some intelligence from my part. And I'm running RedHat, which is (I presume) one of the most easy distro's around. I would tend to say that MDK is maybe even more user-friendly when it comes to the desktop stuff. But, this is obviously only a personal opinion... I didn't apply the low latency patches yet, and I expect that when I do, I will need at least half a day to get things working. Not because patching is that difficult, but because I will have to learn about various other aspects of Linux first. This issue is becomming more important as we speak because Apple, being the artists favorite, has released MacOS X. I have no expierience with MacOS X but from what I hear, it's pretty good. For the moment it still lacks the nescessary programs, but that won't take long. It lacks a lot more though. The development environment is primarily based on a cludgy objective C, printer support is awful, driver support is rather limited (many problems with third-party SCSI cards), the machines are generally overpriced, and the list goes on... We still have time, albeit not a lot... Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ [EMAIL PROTECTED] To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God
RE: [linux-audio-dev] [OT] Question regarding multi-channel capable apps in Linux
Yes, but I need it to be multi-channel in order to harness the power of Rme Hammerfall :-). Ico -Original Message- From: [EMAIL PROTECTED] [mailto:owner-linux-audio- [EMAIL PROTECTED]] On Behalf Of Steve Harris Sent: Monday, January 28, 2002 9:44 AM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] [OT] Question regarding multi-channel capable apps in Linux On Mon, Jan 28, 2002 at 09:33:19 -0500, Ivica Bukvic wrote: Let me try to clarify what I mean by things. I am simply looking for an app that can do somewhat similarly what Cool Edit Pro does, but ONLY in its multitrack mode (i.e. no sound processing stuff is needed). I Have you tried audacity? It only outputs to stereo (or it did last time I looked) but it handles multitracking quite well and is easy to install. The cvs version has some ladspa support. - Steve
[linux-audio-dev] [OT] Question regarding multi-channel capable apps in Linux
Hi all! I am in the process of installing brand-spanking-new RME Hammerfall on one of the studio's Linux workstations (which is making me rather happy :-), and am wondering what current apps are out there that are capable of supporting multi-channel mixing without any hacks/patches and are easy to install (no cvs stuff -- I'd love to get Ardour working, but I simply don't have the time right now to mess with it). So, what I am looking for are simple multi-track editors (no LADSPA or any other sound processing capabilities needed, although they would be more than welcome, obviously) that are stable (this is very important) and usable in their current form, have multi-channel capability, are relatively easy to install (relatively meaning that it can compile after minor tinkering with it), and have usable gui editor. Some of them I presume are Snd and Mxv, but from there on I am not sure if any other are multi-channel capable (beyond stereo spread), such as Mixmagic and Rt etc. So, I would greatly appreciate your assistance in compiling the list of stuff so that I can more easily determine what to give initially the highest priority to have installed on that machine, so that the studio users can... well, use it :-). Any help would be greatly appreciated. Also, since this is somewhat off-topic, you can simply e-mail me rather than posting it on this board (unless you obviously have a burning desire to do so :-). E-mail is [EMAIL PROTECTED] Thank you! Sincerely, Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster computer consultant http://meowing.ccm.uc.edu/~ico/ [EMAIL PROTECTED] To be is to do - Socrates To do is to be - Sartre Do be do be do - Sinatra I am - God
RE: [linux-audio-dev] Another stupid question: Linux MIDI Interfaces
There are already several supported USB external MIDI interfaces whose driver can be found here: http://member.nifty.ne.jp/Breeze/softwares/unix/usbmidi-e.html I have read about this somewhere a while ago and then also posted it on this list wondering whether any of these worked well and whether anyone had problems with any of the supported devices and/or driver. Due to fact that I am yet to find out more about this one, I have no clue how well they work in comparison with the serial-port devices (but if the driver proves to be stable, my assumption is that it should be far better than the serial port counterpart). Ico
RE: [linux-audio-dev] The fastest desktop environment?
Personally, I stuck to the KDE primarily due to its extremely well-implemented RAD toolkits and extremely versatile widget toolkit (qt). I use it on my laptop on a daily basis (granted, my laptop is a 1 GHz monster, so maybe that is why I do not notice its bloatedness), and have yet to experience sound clipping due to gui manipulation (granted if I move full-size 1600x1200 window with an OpenGL animation/application in it, while playing 10 streams of sound, I am bound to get some kind of a sound-loss, but then again, I do not call that a normal way of doing a real-time performance either... Ico -Original Message- From: [EMAIL PROTECTED] [mailto:owner-linux-audio- [EMAIL PROTECTED]] On Behalf Of Dan Hollis Sent: Wednesday, January 02, 2002 5:18 PM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] The fastest desktop environment? On Wed, 2 Jan 2002, DeMeo, William wrote: David Gerard Matthews Jr. wrote: I run a really stripped-down Blackbox when doing audio work. For general tasks (websurfing, etc.) I usually use Gnome, but as you pointed out, it's way too bloated for audio (and KDE is even worse). Some people also like XFCE or IceWM. Could someone please elaborate on why KDE is too bloated for audio. Musicians usually use laptops, KDE tends to be a bit of a resource hog in the constraints of your typical laptop. It runs great on desktops though. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
RE: [linux-audio-dev] [OT?] first RME hammerfall dsp's (multiface versions) are slowly trickling in... Any news on development of Linux driver for these beasts?
a device is being shipped to me. once it arrives, work on the driver will commence. i announced this on alsa-devel, where other subsequent announcements will follow. the pcmcia version is slated for at least the end of january, since there is at least one more h/w rev needed before RME considers it ready to go, at least from a linux point of view. Does this mean that I should hold-off until updated h/w revision gets shipped or is this type of a firmware update where I can update the pcmcia card via some kind of a software-update util? If I need to wait then that sounds very weird since I could not understand why would RME start shipping stuff that is not yet ready to work with Multiface interface... Thanks for your help! Ico
[linux-audio-dev] [OT?] first RME hammerfall dsp's (multiface versions) are slowly trickling in... Any news on development of Linux driver for these beasts?
I guess this is somewhat OT, and probably matters Paul Davis more than anyone else (unless someone else is planning on developing driver for this beast of a sound card). Is there any news on the development of the driver as of yet? Any info would be greatly appreciated since I put myself down on the backorder list... Thanks! Ico
RE: [linux-audio-dev] Still I cannot understand why...
care != contribute According to the English dictionary, you are right. But analyzing a brick out of the buiding perspective is what gets you in trouble: if you were more sensitive to the context and realized that this discussion is being held in the Linux audio DEVELOPMENT list, it would be easy then to assume that both you and I ARE contributing to the Linux community by developing/coding. So, if you don't have anything better then providing a thesaurus to this list, please either use LAU list, or start using that free time churning code (or even better providing ports to all of your alternative OS's that you so dearly care for). BTW2 I mostly use intel pc, I care for other platforms for reason hinted above... Well then you surely have a lot to care for. Good luck! Designing a well implemented driver/app is one thing, while porting it is other, and as such they should be held separate. Design should always take precedence, obviously, while porting should be a project of the benefactor [at least in the non-paying world], not of provider, and as such, again should be separate. Thus, not caring for the porting part of the endeavors simply means that this should not be my priority or something I need to worry about. People who ported first audio apps to Linux (i.e. Mxv), were simply persons who HAD some interest in Linux and thus did so, regardless of OSS. Case and point: RT which is originally Paul Lansky's creation that ran on SGI and had nothing to do with OSS since SGI's audio architecture is/was way better than the OSS's -- its port was done by both Mike Peterson and Doug Scott, people who actually cared about/used Linux and worked out their own ways of porting it to Linux architecture using whatever they had at their disposal in terms of audio API). Paul Lansky, according to your messed-up view, should be then proclaimed selfish [or whatever that means for you] for not providing ported app to the Linux OS [both architectures are *nix, after all, right? -- even more so nowadays, since SGI is switching/ has already switched to Linux]... Quite on the contrary, my friend, Paul Lansky provided a great tool that is still being used nowadays (and should be under no circumstances called selfish for doing so), and thanks to Mike and Doug are we able to enjoy the same app on our favorite OS. Since you are so well versed in the usage of your thesaurus, next time be more careful in the usage of the words within the given context... Ico
[linux-audio-dev] was Still blabla...
Once more, apologies to everyone on this list for cluttering your inboxes. Best wishes to all for the Holidays! Ico
RE: [linux-audio-dev] Still I cannot understand why...
1) Poor documentation That's why we should put some effort to change this. 2) Difficult installation and configuration (not for me, but for users of my software) Of course! This is because Alsa is not a part of the kernel. Once it becomes a part of kernel, it will be the same like OSS in this respect. 3) Constantly changing API (required lots of changes to my code 0.5 - 0.9) Again, if you have been reading up on the past couple posts in this topic, you'd realize that the API is rather close to the 1.0 release (something that I learned by participating in this thread as well), and as such is not prone any more to dramatic changes, as was the case in the past. 4) Currently supports only Linux. (required: FreeBSD, OpenBSD, NetBSD, Solaris, HP-UX, AIX and IRIX (I know, OSS doesn't support IRIX either)) I _don't_ like to support single OS API's, it reminds me too much about Win... One of the main reasons for writing support for ALSA was that QNX has ALSA API. So it's not single platform API, but almost. I have to completely disagree with your statement here. I could not care less for BSD, Solaris or any other flavor or *nix. I use Linux and that is all I care for. Neither do I see any similarity with Windows since I find this aspect to be a rather weak basis for comparison, as well as irrelevant argument in respect to Alsa/Linux audio. Besides this is a typical issue of quantity vs. quality, and right now with OSS we got all the quantity we could possibly get with very little or no quality. On top of that, if Alsa proves to be all that is supposed to be, it will set the standard, and there will be an initiative from the other OS camps to port the architecture. So I see no point in doing their homework. OTOH I do understand there is the issue of cross-platform compatibility, but then it all boils down again to the issue of quantity vs. quality: do I want to make an audio app that will compile even on a palm pilot that will thus be capable of only producing different-pitched bleeps, or do I want to work for a specific platform and make an Ardour-like monster app? I would much rather see Alsa developers invest their time into perfecting Alsa's architecture, than use the same time for porting an API that is yet to be completed/widely used to other OS's. Ico
RE: [linux-audio-dev] Still I cannot understand why...
I think you're lacking a bit in historical perspective. For quite a long time, *most* of the actually useable apps we had came from other unices. When I first came here (1997?), the best soundfile editors I could find were DAP, MiXViews, and Snd. IIRC, *all* of those were developed on SGI or some other non-linux system. And it wasn't really so long ago that we had no sound at all. Considering that Linus originally thought that Linux would never run on anything very different from the particular x86 hardware he had, I don't think we should fault him too much for agreeing to an expedient general solution at a time when there was nothing but a few unrelated drivers for a few soundcards. What was, was. Leave it alone, let it be. Our lesson of the day is that OSS is past its prime (it arguably never had one, but that is beside the point), and as such should be replaced by a better counterpart, in this case Alsa. Defending OSS's historical merits (or lack there of) has nothing to do with OSS's current state and its effect on the LAD community. It might have provided useful things to Linux (and did), but if we here on LAD are not prepared to do away with the primary stalling mechanism of the further Linux audio revolution, then who will? I would say lack of *desire* to do anything else on the part of all but a very small group... most of whom are here and/or on the alsa lists. So does this mean that we should just build what is barely enough to keep the OS running and leave it at that (and then waste countless days trying to hack the lousily implemented audio architecture trying to convince it to do something it was never designed to do)? Kernel devel people are constantly pushing envelope and working on improving the linux kernel, even though it is already probably the most efficient kernel out there, and even though 70% of the kernel features will not be used by most users. Yet they keep on improving upon it (granted not every time with a positive result, but this is again beside the point)... We here are concerned with linux audio, and even though most of the regular users out there will not notice the difference between a 50ms and 2ms audio latency, we will still make linux do 2ms. Why? Because we can, and because we need it, while at the same time everyone else benefits from it, even if they are not necessarily aware of it. This is what makes [should I say will make?] Linux so great... Ico
RE: [linux-audio-dev] Still I cannot understand why...
that's very shortsighted. also selfish (in contrast to sharing ideas that are behind linux). I do not see it being that way since there is no way that I could, for instance, write a good Alsa port for crapple architecture when I do not even own one. I see nothing selfish or shortsighted about that, neither do I think it contrasts with the idea behind Linux. Linux never stood for selected few should write a driver for everything and everyone, while the rest of us should then just use it and complain how the implementation sucked. It stands for here's my code that works for me, hack away and port it so that it works for you and others who use architecture like you, and while doing so, ask them to help you, just as people who have architecture like me have helped me. Ico
RE: [linux-audio-dev] Still I cannot understand why...
if we get everyone to switch to alsa, then everyone can share audio interfaces. if we teach everyone how to use LD_PRELOAD and they accept it, then everyone can share audio interfaces without even switching to ALSA. Well this sounds like a win-win situation and we should advertise it as such, and I mean advertise it BIG TIME. I think that the idea of not having to worry about polling sound signals to the dsp resource sounds so appealing, since that makes one less thing for a programmer to worry about :-). if we get everyone to switch to alsa, and they use the poll interface via ALSA to control their workflow, and/or only read/write avail_min chunks of data, then they'll be ready for their app to work in a synchronous execution system, of which JACK is an example. Just to keeps things complex... When the benefits are so great, the complexities are easy to overcome :) Ico
RE: [linux-audio-dev] midi not professionally used - you're joking right was Still Icannot understand why
-Original Message- From: [EMAIL PROTECTED] [mailto:owner-linux-audio- [EMAIL PROTECTED]] On Behalf Of Allan Klinbail Sent: Saturday, December 15, 2001 3:02 AM To: [EMAIL PROTECTED] Subject: [linux-audio-dev] midi not professionally used - you're joking right was Still Icannot understand why It's not all in midi. On the contrary, very few professional electronic music artists use midi for anything more than some kind of external controller. On the other hand, while Ardour is going to be the app of all multitrack apps, currently there are plenty for non-real-time mixing out there which do job more than adequately (obviously including snd). Ico (the man who made D in LAD stand for Discussion ;-) Hey ICO I have to highly disagree with this statement just about every studio that isn't a mastering studio is using MIDI to one degree or another.. My studio ... which is professional in that I do make money out of my music is highly MIDI oriented with over 8 individual devices all being sequenced or affected by MIDI (this doesn't include my MOTU 8 in 8 out MIDI rack ... all of my colleagues bar one or two have MIDI driven setups... it is really only in the non electronic based or computer only systems which don't use MIDI ... generally as soon as any electronic device (synthesiser, drum machine, FX units) is plugged in to a computer MIDI is going to make use of that instrument much easier.. take for example my Yamaha An-200 . without MIDI it would be impossible to edit all parameters of a sound as many are only accessible via MIDI sysex instructions. This is even more true for the Nord Modular series. Okay there are people working with non electronic music formats using their computer as a multitrack recorder but if MIDI weren't relevant at a professional level it would not be include in professional audio hardware and it would not have become part of the mLan protocol... Well, I'll try my best to clear your misconception about my statement without stimulating an outright flame war. It seems to me like you have some serious misconceptions about the modern art music. Let me elaborate: In my studio where I teach electronic music, we have 2 studios: one for intro to electronic music, loaded with midi stuff and rack-mountable midi modules (something you'd call your type of pro-studio), and the one we call advanced where the only midi we use (if we use it at all) is for some kind of real-time controller hooked-up to control real-time changes in the sound processing or something similar. I must admit that I live in a somewhat isolated non-profitable educational community (where we like to see ourselves as making art for art's sake, since we have no commercial stimuli to poison or limit our inspiration or our artistic output), but if you do a little of research, you'll realize that from this exact community comes the most radical [bleeding-edge] electronic art music (at least in the U.S.) (here, I am referring to electronic music in very strict terms, where it stands for a very specific type of acousmatic art [coming from the Greek word akousma and meaning sound that is removed from its source], and thus by stating this I am NOT trying to exclude or undermine other forms of electronic art, but rather make a clear-cut distinction for the point-making sake). You'll also realize that most of them do not do midi, unless, as I said, it has to do with some kind of an external controller (i.e. pd or jmax/max-msp). Again, this does not mean that the people such as yourself do not use the same apps for your creations, but you use them with completely different goal in mind (i.e. I could use jmax to build a granular synthesis patch that could have its parameters controlled through midi, while you could use jmax to trigger bunch of sequenced stuff on a Kurzweil 2500 module). While most of us (in my community) do know how to do midi, and do it well, we resort to a more abstract art that is not limited by the click-track's resolution, neither by the commercial soundbanks (which could potentially make all of our music sound similar, as is the case with the commercial industry), nor limitations of the synths as to how many oscillators we can mix at the same time without choking the equipment. While you say that midi offers control over the equipment, you are missing the point that most of that equipment that you control with it is commercial, and as such poses a great problem of sounding the same regardless who uses it (i.e. every piece using enchant DX-7 patches will have that common, recognizable sound), and on top of that offers a lot less flexibility than a raw sound data that can be manipulated and processed until the sound morphs into a completely new and unique entity (i.e. your effects processor will offer you only as much flexibility as the manufacturer decides to provide, while in my case, I design my own effects processor that is tailored to my
RE: [linux-audio-dev] Still I cannot understand why...
Please, no more half-way compromises with OSS... kill it, do not even consider backwards compatibility for old OSS apps! Are there any worthwhile salavaging in light of newer developments ? Every ounce of effort towards maintaining (crappy) backwards compatibility for old OSS mainly/only systems takes away effort from enhancing true ALSA apps. The reason why I am so hung-up on backwards compatibility is because this is one of the unique traits of linux. Both winhose and especially crapple, change their architecture every five minutes both for profit sakes and because their architecture inherently sucks. On top of that, when an OS exemplifies in an extreme backwards-compatibility streak, that means that that OS has a good foundation and as such instills consumer's confidence. Now, I am not saying that the OSS is a good foundation, but at least having a small part of the code that could not be addressable by the new programming endeavors, but rather to keep the backwards compatibility, would make sure that the existing apps/commercial software runs and runs good (i.e. Loki games, and older audio stuff that might not be developed any further, yet is extremely good, such as RTMix). I think we would want to be inclusive, not exclusive, and if the daemon was built properly this part of the OSS backwards compatibility would not be even noticed or possible to address in the new apps (if the docs were carefully implemented), and as such would not pose a threat of prolonging OSS's sloppy reign over linux audio. You also have to keep in mind that here we are talking about burying 80+% of one commercial company's sales (4fronttech, author of the OSS, needless the mention other commercial companies who depend on OSS, such as Loki games), and as such it will be extremely hard to do, without an extreme opposition from the company who has the bucks to spend in order to counter our move with propaganda. Thus, I think we need to do this transition as smoothly as possible, not stepping on anyone's toes, so that we encounter the least possible amount of friction along the way and make the transition as fast as possible. That's part of the deal with open source and personal development. Who wants to really work on someone else's project when you can do yer own ! And that is exactly what makes us weak. Everyone re-inventing their own version of wheel will ensure that we all stay in the stone age and not move even one inch from that point on the evolution scale... Why don't we make it everyone's project then :-) ? Anything strictly ALSA based (particularly so newbies don't get confused by two seperate code paths) and the smaller and finishable the better, lot's of people have big grand plans for larger projects but getting usable (good demonstration) apps in a timely manner would also be beneficial for a lot of LAD fringe-dwellers. Again, if the daemon code and docs were implemented carefully, oss apps would be extremely discouraged, if not impossible.
RE: [linux-audio-dev] Still I cannot understand why...
And I'm pointing out again: that will not work! Low latency sharing isn't of much value by itself if the data from different sources is not in sync. The data can only be in sync with a model that: 1) periodically waits idly for every process using the daemon to have the correct amount of data - this will lead to dropouts at low latency settings. OR 2) periodically and actively tells each process using the daemon that its time to produce (or consume) a the correct amount of data. If you or anyone else knows another way, please tell me, Steinberg, MOTU, Digidesign, Apple, Propellerheads, and Emagic about it. I also say again, and this REALLY IMPORTANT for people to understand and know: ALSA *already* has a sound server daemon, 1 per declared-and-used PCM shared device. ALSA apps need do *nothing* except be correctly written to use the daemon - there is no difference in using it to using a PCM hw device or any other kind of ALSA device. The problem is that most people are running OSS-API apps, and getting those apps to use a shared PCM device is, while not particularly complex, not what you'd call trivial (it requires an LD_PRELOAD hack) --p So what you are saying is if we get everyone to switch to alsa and use alsa properly, (i.e. writing apps which send buffered audio data to the alsa-server in a timely fashion) the need for a separate sound daemon will disappear. Right? If that is so, let's tout and advertise Alsa for what it is -- a God-sent thing to all Linux Audio users, and make a lot of noise around it. I don't know about you, but I am pretty convinced that having a lot of advertising works, free market is the best proof of that, so I suggest: let's advertise the crap out of Alsa, write Alsa-specific apps and contribute our alsa-related useful code chunks to a some kind of code repository/docs site, while the docs are catching up. On top of that, it seems that 2.5 kernels will already come equipped with them, so we're surely on the right track. Ico
RE: [linux-audio-dev] Still I cannot understand why...
1) Majority of current audio apps aren't realtime-safe 2) Combining JACK and ALSA? 3) A lowpriority frontend server? aRts and JACK? All of these sound fine to me. Older OSS apps would not have the low-latency, but at least the sound server would offer compatibility with them (which would just stimulate people to use alsa even more, if they wanted low-latency), so at least everything should work, and the newly developed stuff should work great! 4) The big API debate... I agree, this is probably the biggest hurdle. And the only way to overcome it is to advertise and convince the competition to switch over (kinda like a sleazy long-distance telephone company hehe). Anyway, at the same time, _majority_ of both audio app developers and users are not part of these groups, and just know about the kernel API, and that's OSS. Even if ALSA gets integrated to linux-2.5.x, the OSS API is still there. So whom do we have to beat up to get rid of the oss :-)? Ico
RE: [linux-audio-dev] Still I cannot understand why...
so which apps are you wanting to use in an integrated way? note: i know that you can make some interesting experimental noise with linux (i've done it). but i don't know of anyone who could use it for producing the kinds of sonic arrangements most people would call music unless you're a bleeding edge muse or ardour developer/user, and likely not even then at this point. --p Ok, I do agree there is no single ubiquitous app on the linux audio scene that one could call complete or even remotely perfect, but on the other hand I tend to strongly disagree with your statement that there are no good apps that are capable of producing professional-sounding performances. Heck, I've gotten my Masters degree in composition by using RTCmix in real-time environment (with my own arbitrary front-end built to control the whole performance), and so far all the critiques of my work were nothing but positive. Did the samples get out of sync? Probably. But neither did I get to notice that, nor is that the point. The point is that the piece sounded as good as any other professionally produced work (here I am NOT speaking about the work's artistic value, but strictly about the production value -- just to make sure you understand I am not trying to kiss my own behind :-), and that is all I care for (plus the obvious latency issue and the sharing of audio resources so that I can simultaneously run jmax, pd and rtcmix or some kind of crazy combination of that sort). If you also check the pd and jmax lists, you'll get to hear every so often a great success story using linux in live performance. That's why I believe that you are seriously undermining the linux art scene. It's not all in midi. On the contrary, very few professional electronic music artists use midi for anything more than some kind of external controller. On the other hand, while Ardour is going to be the app of all multitrack apps, currently there are plenty for non-real-time mixing out there which do job more than adequately (obviously including snd). The apps are out there. Maybe not as strong as protools and similar commercial stuff when compared as individual entities (and certainly still lacking in the midi department), but when used in combination, they pose (IMO) as the most powerful audio platform available. If I didn't believe in this, I wouldn't be here writing this, or using linux for my own creative work... Ico (the man who made D in LAD stand for Discussion ;-)
RE: [linux-audio-dev] Still I cannot understand why...
the problem is: go ahead and produce that exciting and wonderful live performance, and then, assuming it was so great you'd like to make a CD from it ponder: how do i record it? how do i edit all the tracks? etc. ... the gaps start to appear fairly immediately, as i'm sure you know. To be honest I only burned data cd's in Linux so far (oops! there goes my whole argument down the drain :-), but from what I've seen with XCD-roast and Gnome Toaster, it shouldn't be that far-fetched at this point. I agree, there are a lot of holes to be plugged, but even in this state, linux sure beats crapple and winhose experiences. If i *did* believed that, i would be sitting here at 4am working on developing apps that can bring ease and power to working with gobs of audio data, recording it, editing it, arranging them, mixing and processing them :) Well, if this makes you feel better, it's 6 am over here, and I am finally getting ready to crash (although for all the wrong reasons) :-). Keep me posted when you start shipping those linux machines of yours loaded with audio stuff, so that I can get my studio to purchase a couple :-) Ico P.S. Any thoughts as to what distribution will use the linux machines you'll be selling? Also, any plans to soup 'em up with a powerful video editing capabilities?
RE: [linux-audio-dev] Still I cannot understand why...
-Original Message- From: [EMAIL PROTECTED] [mailto:owner-linux-audio- [EMAIL PROTECTED]] On Behalf Of Paul Davis Sent: Friday, December 14, 2001 3:59 PM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] Still I cannot understand why... all multitrack apps, currently there are plenty for non-real-time mixing out there which do job more than adequately (obviously including s nd). yes and no: do you think you could do even just a 16 track edit and mixdown with snd, or any other available tool? Slab, ecasound, ... what's the problem? sorry, i wasn't precise enough. by edit and mixdown i am including the notion of operations performed according to musical time and operations performed on entities with musical semantics. Not all serious music requires this kind of approach. Electronic music does not rely on tempi (unless it has something to do with real-time performance with a live performer reading conventional score), neither it requires any kind of musical time reference (in most cases, where the whole idea behind creative work is a creation of, what I like to call, a sonic landscape). Such compositional work is heavily based on intuition and creativity, not on time-measuring tools (although there is no reason why it couldn't be). last time i looked, neither slab nor ecasound had any clue about tempo, meter, and so forth, and neither operated in a way that let you define a chunk of audio (other than a complete file) that could be manipulated, repositioned, duplicated etc. Mixmagic can cut, paste, and reposition sounds (or chunks of them) without having to create a new soundfile. It is a rather formidable mixer, unfortunately it is yet another example of (for some odd reason) frozen project. Check it out at http://mixmagic.sourceforge.net screenshot at: http://mixmagic.sourceforge.net/screenshot.php The same is the case with Rt. Ico
RE: [linux-audio-dev] Still I cannot understand why...
Thanks for shedding some light on this issue. As a matter of fact this kind of info should be posted on the front page of LAD, so that the newcomers and the more adept users/programmers (such as myself), would know exactly what to seek and how to contribute to Linux audio community, since not many people nowadays have the luxury of time to browse the endless posts (and for that matter neither do we programmers have time to chat as we do right now re-discussing something that is important enough to be posted and summarized in some kind of Linux audio current limitations log, right? :). You have said it the best: Linux overall, is acutely suffering from lack of coherent documentation, and if someone is not able to contribute code, maybe they can contribute to this, long overlooked problem. If people are made aware of the issue, they will be more likely to contribute... Otherwise we are playing a game of hide and seek with blind men... As far as the deprivation from decent sound support in Linux is concerned, I know exactly what you mean, I was there -- maybe not as long as yourself, but certainly long enough for the problem to manifest itself through this kind of frustration. Apologies to all for cluttering your mailboxes with something that is turning out into an OT subject. Sincerely, Ico
[linux-audio-dev] Big Qthread vs. pthread and usleep problem
Hi all! I am in a process of fixing the resource usage of my app, since right now it is an outright system resource hog. This is due to fact that my pthread has an infinite loop constantly checking elapsed time, so that it can accordingly update the gui display of the timer (chrono-like display). In order to fix this I've tried 2 approaches: 1) I tried changing over to Qthreads, but the problem is whenever I declare a new clas: class foo : public QThread this yields syntax error due to QThread (if it is any other qt class, this line reports no syntax error. What is wrong wit this? I am using MDK 8.1 with Kdevelop 2.0 and qt 2.2 or 2.3 (whichever came packaged with the MDK 8.1), and there is QThread annotated in the qt docs, and even the example code contained in the docs yields the same compile error. Could it be that I should do ./configure --enable-mt in order for my code to compile properly? So this option right now remains to be explored, but since I am in a time crunch and I chose option 2 (described below) after being stuck at this one, I am looking for a possible solution to my problem using pthreads, also since I will have to use the similar method regardless of which type of thread I use. 2) I am using pthread_create right now (everything works), but since the loop within the thread is infinite, it poses as a serious resource hog. So, what I decided to do is to add usleep(1) value which would give me 10ms sleep sessions in between the counting, since my timer only uses two decimal points for subdivisions of the second. But whenever I do this and compile the program, the application's timer runs SLOWER, no matter what is the usleep value (even if it is 1!), and only speeds up to what it is supposed to be when I move/wiggle the mouse over the main app's widget, and/or click with the mouse. Why the heck is this happening? It is obvious that the usleep() is causing this kind of unusual behavior in combination with the qt gui, but why, that is a mystery to me. Is there a more elegant way of making the pthread sleep using sub-second time values? Can someone explain why is this the case? It seems almost that due to fact that there are no events coming from the mouse/keyboard, the qt-gui app is being bogged down by the utilization of usleep. If this is the case, can I somehow force fake events onto the gui in order to make sure that the app runs smoothly? Changing the pthread priority to SCHED_RR or SCHED_FIFO did not fix this problem either. I would greatly appreciate any help I can get on this issue. Thank you! Sincerely, Ivica Bukvic
RE: [linux-audio-dev] Big Qthread vs. pthread and usleep problem
You can't just sleep for less than 20ms. The system timer has that resolution (at least, by default on x86; its different on other architectures and it can be changed at kernel compile time), and it is what is used to wakeup processes that call sleep/usleep/nanosleep. see below for more. Well, the way I've been doing stuff so far is that there's a thread that is created before even the main widget is shown, and it depends on a value from the main widget which designates the playback state (i.e. stopped, playing, paused, etc.). When the playback state becomes playing, the if condition within the thread is fulfilled, and thus begins the time counting, and it seems to work fine (considering the fact that usleep, as you have pointed out, does minimum 20ms counting, which is twice the resolution I am looking for), and that is ok for now since the app is designed for rt performance (interaction between performer and computer, and as such anything less than tenth of a second is pretty much an overkill, but is there nonetheless). I originally made an infinite loop checking through ftime the passage of milliseconds, but since it was an infinite loop checking as fast as possible (in order to avoid inaccuracies, and at the same time I was unable to use sub-20ms usleep function to ease the load on the cpu), it left a huge footprint on my system resource usage (~97% on a 1Ghz P III laptop). Now, that I am using usleep, with this 20ms limitation, I have between 0 and 1%. This is crucial for my app, since it is only a front-end for other sound-oriented processes (i.e. rtcmix, csound etc.), so my app needs to have smallest footprint possible, and right now seems to be doing ok in that department, thanks to usleep. Still, the question remains, how to get better than 20ms resolution without hogging the cpu? Usleep seems out of question if I want to go beyond the 20ms threshold. As far as my code is concerned, well it's so messy that I am honestly embarrassed to show it until I make serious improvements, esp. due to fact that app still does pretty much nothing :-). In another words, I am still exploring the best ways of doing things. Hope you'll understand. Thank you for your ongoing assistance and support! Sincerely, Ivica Bukvic P.S. It seems to me that the author of usleep should make sure that the usleep man page reflects this important limitation, since there is no mention of usleep being limited by the 20ms threshold, although it is quite possible that the limitation is not in the usleep code, but rather in the kernel architecture, as you have pointed out.
RE: [linux-audio-dev] Big Qthread vs. pthread and usleep problem
why would you count the passage of time from within a dedicated thread? whatever delivers audio data to your audio interface is also counting time, though you may not realize it. Yes, I am aware of this, but my program will not handle audio directly. It will be only the front end which will execute system calls to the audio processes as needed, thus the timer I need will be completely independent from any kind of audio data flow, or audio-related process. This is why I am looking for a separate timing thread, so that my front-end gui does not freeze due to infinite timer loop (if it were executed within the same thread which manages gui), if this makes any sense :-). I am not sure whether this is the most sane/efficient approach, but this being my first audio-related gui app, I am using it to learn as I go :-) Thanks to all of you who responded to this question, I did finally solve the problem with the QObject::startTimer() call which has 10ms resolution (exactly what I need) and results in 0.00 cpu usage when running (according to the Process Manager). Big thanks to all of you who generously offered your help! Sincerely, Ivica Bukvic
