Pete Bessman wrote: Nice attitude. While this ethic is understandable it doesn't help progressions very much. Maybe now you've had a couple of days to think rationally about it you have changed your mind anyway. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide Http://www.djcj.org/gigs/ - Gigs guide Korea ======================================== Apparently upon the beginning of the barrage, the donkey broke discipline and panicked, toppling the cart. At that point, the rockets disconnected from the timer, leaving them strewn around the street. Tethered to the now toppled cart, the donkey was unable to escape before the arrival of U.S. troops. United Press International Rockets on donkeys hit major Baghdad sites By P. MITCHELL PROTHERO Published 11/21/2003 11:13 AM

On Saturday 21 February 2004 22:42, Patrick Shirkey wrote: I disagree. By avoiding black-hole "design projects" that put out PR and never go anywhere, coders who are actually productive have more time available to bring other, more active projects up to speed, while preventing said black hole projects from projecting the illusion of active development and sucking in other developers. People say free software is a meritocracy, but really, it's a who-produces-the-most-working-code-ocracy. And it works. I'm not familiar with the Linux sampler project nor with Pete's program, so this is a general statement and not specifically about those two. I am involved with Gambas, though, a VB-like language for Linux, perhaps the only one you can use for real projects currently, and people have always made comments like "Why don't you merge your project with something more established like KBasic?" KBasic being another "get lots of press, design for 3 years and then never release any working code" black hole of a project. It's not a unique situation (remember how GNOME Office was gonna gut and then replace Openoffice?) and it's frustrating for any developer who actually produces code to hear. Rob

On Sun, 22 Feb 2004 12:42:31 +0900 Patrick Shirkey <pshirkey(a)boosthardware.com> wrote: Sorry Patrick, but I tend to agree with Peter. The projects that actually make progress are the ones where one or more people sit down and start cutting code with very little planning. That is the same for small projects like Peter's Specimen and larger projects like JACK, Ardour, ecasound or anything else. In the case of JACK, there was a whole bunch of talk on the LAD list about how it should be done. Paul contibuted to that, but then went away and wrote an implementation. Once there was something that at least worked, others joined the effort and Paul is now one of about 5 or 6 people contributing to it. I strongly believe that without Paul's implementation, we would still be discussing it on this list and there would be no working code. Another case in point is libsample: http://libsample.sourceforge.net/ I told Dominic Mazzonni (Audacity) that I was working on a sample rate converter quite early on and he suggested that I join the libsample effort which was also working on doing sample rate conversion. I looked at the web page and saw that they had the web page, a header file, a mailing list (with zero traffic) and some ideas along the lines of "lets use the JOS resample code". When I looked the page, the project had already been dormant for a number of months. I decided to press ahead with my own efforts which resulted in Secret Rabbit Code being released in Nov 2002. There has been zero progress on libsample since May of 2002. In the Free Software world code talks and bullshit walks. Working code, however simplistic, is worth 1000000 web pages with project plans. My guess is that if Pete wanted to take Specimen into more advanced areas he will get there long before the LinuxSampler project and along the way he will have a useful tool that he and others enjoy. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ Windows NT : An evolutionary dead end.

Mark Knecht wrote: Except JACK :) Yes. I just downloaded and installed it too. Also took some time to read the draft of the documentation. Hardly a draft IMO (23 pages). I guess people are just jumping to conclusions that Linux sampler is a dead project. After taking the time to do this I'm wondering if Linux sampler is the project for me. I could easily do some work on a gui. But I prefer to work with wavefiles and because I have no midi instruments maybe linxsampler is overkill for my needs. The concept is rock solid though. Buffer a small amount of the file into ram and then stream from disk. Lets see. I have alsaplayer which needs sample accurate playback and tX which needs to stream from disk instead of RAM. Maybe I'll work on those today instead. Although I do agree with Eric that written code is worth it's weight in gold. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide Http://www.djcj.org/gigs/ - Gigs guide Korea ======================================== Apparently upon the beginning of the barrage, the donkey broke discipline and panicked, toppling the cart. At that point, the rockets disconnected from the timer, leaving them strewn around the street. Tethered to the now toppled cart, the donkey was unable to escape before the arrival of U.S. troops. United Press International Rockets on donkeys hit major Baghdad sites By P. MITCHELL PROTHERO Published 11/21/2003 11:13 AM

Mark Knecht wrote: IIUC it' basically a list of the calls available to a python or other script language programmer. It wouldn't be difficult to figure out the functions but a more complete description ala jack docs would make things even easier. I have some ideas. I'm hoping Pete will start the ball rolling though. I wouldn't want to code an clone when his work is already there. Oh I didn't know this. Will look into it some more. I can see how it could based on the info above. Think of tX with multiple columns and rows of samples running off the linux sampler engine. (basically Ableton pro but not loading to RAM). There is another app that Fred Gleason started awhile back for radio work which could probably benefit from it too. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide Http://www.djcj.org/gigs/ - Gigs guide Korea ======================================== Apparently upon the beginning of the barrage, the donkey broke discipline and panicked, toppling the cart. At that point, the rockets disconnected from the timer, leaving them strewn around the street. Tethered to the now toppled cart, the donkey was unable to escape before the arrival of U.S. troops. United Press International Rockets on donkeys hit major Baghdad sites By P. MITCHELL PROTHERO Published 11/21/2003 11:13 AM

At Sun, 22 Feb 2004 12:42:31 +0900, Patrick Shirkey wrote: ^^^^^^^^^^^^ The progressions of what? My attitude may be *indirectly* detrimental to Linux Sampler (which I doubt, because Specimen is the first program above 500 lines I've ever written; I would just hinder those guys). It is _not_ detrimental to the Linux Audio Scene, and it is beneficial to Specimen. And I daresay that by devoting myself to Specimen I am improving the LAS, but perhaps I'm an egomaniac. If what I'm doing does hurt LinuxSampler (yeah, right...), I can't say I feel any remorse. If that makes me a jerk in your eyes, so be it. Apart from Evil Laughter(TM), which I thought was funny, I couldn't see one thing irrational about my statement. The gist of it was "It makes more sense to improve a living project than to have maintainers of said project contribute to the creation of what is currently a castle in the sky." Asking me to pool my efforts with SimSam's author makes sense to me(until you account for the fact that I don't know QT and hate C++, hence Specimen), but I don't see why I should drop my project and work on LinuxSampler. And if you took offense to my intent to whore their code, remember that this is a two way street and they can just as easily (and I encourage it) whore my code. The absolute number one reason I started writing Specimen was because I couldn't find anything that did what I wanted already (and at the time I thought SimSam was dead, plus the aforementioned reasons for not working on that). Whatever produces the best tool for the job is fine by me. Naturally I want that to be my tool, and I obviously think it will or else I wouldn't be doing this, but it's not like my opinion of LinuxSampler is anything but my honest-to-dog pragmatic evaluation. And who knows, maybe I'm helping LinuxSampler more by being pessimistic than by contributing my incompetence? Perhaps Steve Harris, upon reading my prior message, launched into a raging ninja coding fury, adding feature upon feature to LinuxSampler (including a explode-competition's-head button), until it is poised, ready to strike and crush all who oppose it. [pb] P.S. Bwahahaha! P.P.S. Mark: I'm amazed that what I thought was merely an expression of a negative opinion is considered "going off." Puh-lease.

Mon frer, I don't think you're ever gonna like me. At Sun, 22 Feb 2004 14:40:25 +0900, Patrick Shirkey wrote: Reasons I like specimen, in descending order: 1) It works, has a solid user interface, and can make good music *right now* with ease. 2) It is rapidly improving, and there is a high correlation between my desire for a feature and its sudden appearance. 3) I wrote it, and everything I touch turns to gold. The astutue reader will wonder how I ever manage to "change the oil," to which I respond that I can't, and hence tend to blow up with vitriol and venom, fulminating ad infinitum against everything in site, in response to the slightest provocation. You obviously think I'm an idiot (that's ok, I do to). How could I claim to be cool because of Specimen? Maybe relative to my classmates who are still learning the mechanics of C++, but I don't think for a second that my program amounts to much more than a Labrador's red rocket on a list whose members include the authors of Ardour, swh-plugins, libsndfile, etc... I agree. In my evaluation, I'm making the best use of said energy. You think I'm wrong, I think I'm right, oh well. I'm not hurting anyone or anything, and if I do turn out to be wrong and LinuxSampler tears my fool skull from my head, you can piss on my grave. No point in raising a fuss. I didn't mean to imply that it was dead, bad use of the word "living" in oppostion to LinuxSampler. Last I checked, it was nearly 10,000 LOC (about twice as big as Specimen). However, I don't consider it to be useable. If you disagree with me there, then once again, there's not much to be done, but I would like to tempt you yet again with the possiblity of smugly desecrating my final resting place if I'm wrong, so you might as well just let me keep on digging. Technically correct. As Mark pointed out, his comment which sent me into a raging fury wasn't for me. I misinterpreted it, and got the impression that he was suggesting that my effort would be better spent contributing to LinuxSampler. And I'm merely suggesting that I am doing *more* good on my own. In retrospect, I should have sugar coated it more, since it obviously rubbed folks the wrong way, but that wasn't the intention. Parse error. Damn. Burned. Patrick - 1 Pete - 0 Anyway, I have known about LinuxSampler since they got the site at linuxsampler.org, but I got sick of waiting, and I couldn't figure out what was going on well enough to contribute. I still can't. Their lock-free ring buffer code is something on the order of 300 lines. Mine is about 30. As I said before, I am an *extremely* inexperienced coder, and I think I would hamper their style more than help the project. In light of all this, I don't see anything wrong with me writing Specimen, and I don't see anything wrong with me not liking LinuxSampler. I do see the light, however, about controlling my temper, and I promise to never let it get the best of me again, lest I find myself stranded in that place where people go when they "go off," wishing to dog that I had a powerbar and some gatorade. [pb]

On Sun, 22 Feb 2004 17:15:11 +0900 Patrick Shirkey <pshirkey(a)boosthardware.com> wrote: The specimen GUI is written in C/GTK+. It is my understanding that LinuxSampler is C++/QT. Peter already said that he doesn't like QT and he doesn't like C++. That is more then enough reason for Pete to say away from LinuxSampler. You are drastically understating the complexity of what you are suggesting Pete should do. Patrick, please don't take this the wrong way, I'm really not trying to be offensive, but you, as someone who doesn't code (please correct me if I'm wrong) it seems a little strange for you to be handing out this advice. Like i said, I wasn't trying to be offensive with that statement. I do know that you make large contributions to documentation, evangelisation and probably also things like bug reporting. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ Everything that I've learned about computers I have boiled down into three principles: PC/Windows: You think it won't work, and it won't. Macintosh: You think it will work, but it won't. Unix: You think it won't work, but if you find the right guru, you can make it work.

Erik de Castro Lopo wrote: Fair enough. But what he is implementing with specimen could be made significantly more powerful and be useful to a larger number of people if he did join forces. But that applies to anyone. And maybe Benno or someone else on the Linux sampler team will fuse the code for specimen themselves seeing as it has most of the basic things they need already designed. A useful thing about a gtk2 interface coded with glade-2 is that with a simple change of a config option the files will be built in c or c++. I saw it happen with jamin and it worked very well. And jackeq, jamin, alsaplayer, the php backend for the alsa-docs... But I haven't written a lib yet so I'm not a guru. However Pete has implemented what I consider a very good basis for a gtk2 frontend for Linux Sampler. If I was to start on a front end for linux sampler I would take the .glade file from specimen and use that. However if Pete was interested then he could extend the backend functionality of specimen by giving it the power that Linux sampler makes available. Eric. As a writer of multiple audio libraries you definitely understand the concept of having multiple apps use your code. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide Http://www.djcj.org/gigs/ - Gigs guide Korea ======================================== Apparently upon the beginning of the barrage, the donkey broke discipline and panicked, toppling the cart. At that point, the rockets disconnected from the timer, leaving them strewn around the street. Tethered to the now toppled cart, the donkey was unable to escape before the arrival of U.S. troops. United Press International Rockets on donkeys hit major Baghdad sites By P. MITCHELL PROTHERO Published 11/21/2003 11:13 AM

Dave Phillips wrote: Do you need this? If it is streamed straight from the hdd then it may be more efficient to use ardour or some other sample editor/sequencer which has already been written. Essential for interacting with midi instruments. Can't muse or rosegarden do this already? Ls has Jack support. It's fairly simple to add a new jack i/o. Sounds like an organ players wet dream ;) I add this Trigger any/multiple sample loops via mouse. As interfacing with Linux sampler is a matter of adding a few ascii calls to your app it appears to be a relatively straight forward process to add support to any one of the sequencers that are available. What's the catch? I'm trying to figure out the difference here between what ardour/muse/rosegarden do now and what Linux sampler is capable of. Anyone have more clues? From the advertising on the gigasampler site I get the impression that the sequencing and recording interfaces are mainly to provide an all in one app. Give the consumer something worth spending a large sum of money on. Probably also the proprietry market expects it. BTW I noticed Paul Davis did some work on adding midi tracks to ardour recently... -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide Http://www.djcj.org/gigs/ - Gigs guide Korea ======================================== Apparently upon the beginning of the barrage, the donkey broke discipline and panicked, toppling the cart. At that point, the rockets disconnected from the timer, leaving them strewn around the street. Tethered to the now toppled cart, the donkey was unable to escape before the arrival of U.S. troops. United Press International Rockets on donkeys hit major Baghdad sites By P. MITCHELL PROTHERO Published 11/21/2003 11:13 AM

Mark Knecht wrote: Not true Mark :) LS does not have this limitation: although the current implementation for now allows only ALSA MIDI input, Christian added a time stamped event system which was planned anyway for accuracy reasons and because it will allow LS to be turned into a VSTi or AU plugin. If some VSTi like standard and sequencers will arise under Linux, LS can support such features without needing many modifications to the engine. cheers, Benno http://www.linuxsampler.org

Jesse Chappell wrote: Hey guys, I ain't arguin', but I'll believe it when I see it. Please explain to me how any of this is supposed to work for the big world out there using Windows and Mac sequencer platforms. Today we are *all* using GSt on separate boxes for our sequencers. I just don't see it. These platforms are going to generate a MIDI event. They don't know a GSt MIDI event from an LS MIDI event. LS is going to play the note when it receives the MIDI event. How can it do anything differently? MIDI itself doesn't send a timestamp. How's that supposed to work? Even in the case of the VSTi wrapper on the Windows platforms (as has been discussed) I cannot understand that even if you can timestamp a MIDI event before you send it over Ethernet (and I'm not sure you can accurately enough in those environments) how are you going to do this when there is jitter in the clocking on those systems? I'll submit that on a Linux only set of boxes (well, possibly plural) it may be very possible to do something non-standard and get it to work, although I'd like to now what the latency overhead is going to be. If that's what you're going for then that could be cool for Linux only users. (Not the goal ofthe LS project I thought, but I've certainly been wrong before.) Anyway, it sounds great to me, and I'm here to test when it starts becoming real, but I just don't see it yet. - Mark

On Sun, 2004-02-22 at 08:44, Dave Phillips wrote: Hell yes! Things here that sound like differences wouldn't even raise an eyebrow in a bar discussion. Let me add - 'Compatibility with existing libraries that people have spent thousands of dollars on'. If a sampler won't play them then people have problems. (I see at the end you raised this point) I own it and use if almost daily. I currently have about 17GB of GigaSampler libraries. Keep in mind that GSt handles up to 64 instruments at the same time. You have a limit to how many notes can be played, but no limit about how many notes come from each instrument. I've also used Kontakt, Battery and Halion a bit. My thought is that there is a lot of room for a sampler player like Pete's in my life, most especially for samples that don't require much additional real-time processing. Drum sets, for instance. I have some great drum samples and just want to set up a GM drum device. I do this in GEdit for GSt. Specimen could be great for that. It's lightweight and probably very efficient. All I need is for it to possibly allow relative sample volumes into the mix so I can get a reasonable level between the samples. That would be a great tool. Please keep in mind that disk streaming is a requirement for certian libraries. My two good pianos are both >1.5GB worth of wave files. That's not going into DRAM any time soon. Beyond that, take the idea of micing a real drum set. Maybe I'm used to 4 mics - 2 overheads, a front kic and a low snare. Pretty standard. However I promise you that all 4 mics pick up the snare. Taking a program like Specimen to the level where it can 'create' four outputs with relative levels and timing of all the drums in the set could be pretty cool. That's what adds to a real drum sound in the studio and I don't get enough of that from simple wave file playback. Just a dream. - Mark

:} Or vice-versa: http://www.steinberg.net/en/products/vst_instruments/hypersonic/index.php?s… On Mon, 23 Feb 2004 07:47:45 -0800 "Ken" <renueden(a)earthlink.net> wrote: -- Though your brother's bound and gagged and they've chained him to a chair won't you please come to Chicago just to sing? In a land that's known as freedom how can such a thing be fair? Won't you please come to Chicago for the help that we can bring? {Graham Nash}

On Sun, 22 Feb 2004 02:55:52 -0500 Pete Bessman <ninjadroid(a)ml1.net> wrote: If we were all working for a company, then we would all be told that we are working on such and such a program and there would be as little overlap in projects as possible. In contrast, Free Software is an ecosystem; an ecosystem which can support many programs with largely similar features. The only times Free Software projects die is when they are not fit enough to survive. Lack of fitness in this case can mean any number of things, including: - The orignal developer loses interest and noone else could be bothered to keep it alive. - The code get too unmanageable to keep working and updating. Suggesting that someone drop their own project and join another project is just silly. However, when people see another project that they think would be something cool to work on, they may well be better off joining that existing project and should be encouraged to do so. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ The Earth is around 70% water. Fish rule the seas. Humans are over 90% water. It's only a matter of time.

On Sun, Feb 22, 2004 at 12:26:22 -0500, Pete Bessman wrote: Nor do I. I have no problem with a handful of sample players existing (though I've changed my mind about this a couple of times :) Different projects have different styles, and UIs, and having a couple for Developer Disinterest Insurance is a good idea. FWIW my input to LS has been pretty minimal - other than a bit of filter code its mostly been bribing and pestering Benno :) - Steve