Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
--- quote from s3000xl manual, pg. 261 --- Start: Here, you can set the method by which a take will commence playback. The options are: IMMEDIATE - This will cause the take to commence playback as soon as you press PRME - F8. MIDI NOTE - This will cause the take to playback when it receives the MIDI note number set in the note: field described below after PRME is pressed. --- end quote --- From my memories of working with akais I think this means they were pre-chaching for playback. You can set the start postion in mm:ss:ff. I haven't read the patent, but if someone can veryify this (I don't have an akai at the moment) I think we have enough grounds to defend any prechaching we might want to do. the quote above doesn't seem to me to provide any indication whatsoever that precaching was being used. companies like akai were/are quite free and easy with what they mean by immediate and as soon as. its quite possible that they did do precaching - i just don't think this provides any evidence of that. to overturn a patent, you need evidence not just that somebody had a way to do the same thing, but that somebody had used the same method. --p
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
Yes, that rings a bell. I think it was on the S3000 at least, it was only stereo+monophonic, but if it had instant start it must have chached (the scsi controller in the 3000 was very slow). The Akai S1100 and S3200 (and S3000 with an upgrade) could play back recordings from hard disk. I'm pretty sure there was no caching as there was always a delay - you could set what you wanted the delay to be, but the minimum depended on the hard disk access speed. Mine was around 50ms (even if the controller was slow, it always knew in advance where on the disk it was going to be reading from). I think you could crossfade between two recordings, but only if you set it up in a playlist in advance. The Akai S5000 and S6000 do have cached-start sample playback from disk, but I don't think these models pre-date Gigasampler. I doubt they are paying giga/conexant any license fees though - maybe there are other Akai devices worth looking at, as they did all sorts of audio-for-video editing stuff nobody knows about. Paul. _ m a x i m | digital audio http://mda-vst.com _
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
On Sat, 19 Jan 2002 07:27:36 +1100 Erik de Castro Lopo [EMAIL PROTECTED] wrote: On Fri, 18 Jan 2002 17:03:55 - Tony Lambley [EMAIL PROTECTED] wrote: Back in the 80's people were using the Synclavier for audio on video productions. I know they were serious beasts, but I doubt they would have kept all that data in RAM. The latter Fairlights were probably similar. Anyone have any first hand experience of them? I used to work at Fairlight (long after the CMI days). I still have friends there and one in particular knows the guts and implementation of the CMI very well. I'll quiz him on this subject. Ok, I got word from my friend at Fairlight. He says: I remember Fairlight talking about such a sampler technique when I started c1989, but we never made such a product. The Fairlight Series II/III loaded the whole sample into ram before playback could begin. I guess the Fairlight also loads cached the sample before playback - it is just that the cache is the whole lot. The patent must exclude this case. You could check-out Akai. I think they had a product post S1000 which could play very long samples using this technique (was it the S1500?). I am not sure about the Synclavier Not what we had hoped for but anyway Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ Windows NT - How to make a 100 MIPS Linux workstation perform like an 8 MHz 286 -- Christopher B. Browne
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
For smaller sample sets that would indeed be an easy way around the patent with almost identical capability. Even though SDRAM is up in price from 2 months ago it's still pretty cheap. My sources in Korea tell me that the price of RAM will plummet again in February/March. The reason for the sudden increase in December appears to be connected to the end of the university year in Asia when happy parents start giving electronics to their dilligent children as rewards for studying so hard. I'm waiting to test this theory, hopefully I have been told the truth and can pick up where I was in November. -- Patrick Shirkey - Boost Hardware Ltd For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.boosthardware.com/LAU/Linux_Audio_Users_Guide/ _ Want a new web-based email account ? --- http://www.firstlinux.net
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
On 20 Jan 2002 18:43:00 +1100 Allan Klinbail [EMAIL PROTECTED] wrote: Just a quick history lesson that maybe relevant. Fairlight (an australian company) folded because the company The story is more complicated than that. failed to patent the technology (hard disk recording), Don't you mean Fairlight's failure to patent sample playback synthesis? Fairlight mark 1 went under in about 1987. They were working at that time on the very first Fairlight disk recorder, MFX1, but the majority of sales were coming from the CMI and CVI (Computer Video Instrument). Part of their demise was due to companies like Akai and Roland releasing samplers with 90% of the features and 10% of the price of the CMI. which pro-tools was later to adopt and bring about the demise of this company. Fairlight was resurected in 1989 and still exists today: http://www.fairlightesp.com.au/ Use of this by multiple vendors meant that the technology can be used by anyone. (got friends who worked there in the 80's) Worked there myself for 5.5 years (1995-2001) and have friends who work there now :-). Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ I hack, therefore I am.
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
In any case, preload in multitrack editor is totally different from a disk sampler. why do you think that? The multitrack has its samples arranged to fixed positions. By pressing the play button, that one arrangement starts playing, and it won't stop when the play button is released or won't play infinitely in a loop when the button is hold down. The disk sampling synth can play multiple samples at arbitrary times, and loop them infinitely if necessary. There are no prearrangements. -*- In multitrack editor, we could allow key-bindings to individual arrangements (i.e., multiple edit works) or individual tracks so that they start playing when the keys are pressed, and stops when keys are released. This means we allow multiple distinct play heads in the multitrack tape player. Loops can be handled too by allowing callbacks for presses and releases. So, multitrack editor could be turned to imitiate the disk sampling synth but it would then be the disk sampling synth -- if they patented the basic idea of sampling synth reading the samples from disk, then it doesn't matter how it is implemented, and we are not safe. In any case, I would add those key-bindings, callbacks, loops and multiple play heads to a multitrack editor because they would be useful even not used for a disk sampling synth. Best regards, Juhana
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
The Mellotron reference was a (poor) pun. As in read + head. --- I don't know what technology Synclavier used, but Mellotron wasn't digital at all. It used strips of magnetic tape; when you pressed a key it pressed the appropriate idler wheel against one of the tape strips, which dragged it under a read head. Then when you released the key a weight pulled the tape back to its original position. That's right, you couldn't hold a note for longer than eight seconds -- that's how long the tape was. Dr. Who's foley work was mostly (I've read ``completely'' but I simply don't believe *that*) done with a Mellotron. Good grief -- getting ready to post this, I discover they're back in production. http://www.mellotron.com/
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
Dan Hollis writes: On Tue, 15 Jan 2002, Joe Pfeiffer wrote: IANAL, but as near as I can tell the USPTO has almost completely given up on their responsibility to actually evaluate patents before granting them. The philosophy seems to be that they'll let anything go through, and if somebody doesn't like it let the courts sort it out. IMHO the individual examiners should be held liable if the patent is found invalid due to prior art. A good idea in principle, but given the amounts of money involved you'd never be able to hire another examiner... Something else I should mention -- it's also my understanding that, as you'd expect, patent law varies a lot from country to country. So even if I'm right in my recollections of how things work, that's limited to US law, and a Lithuanian (picked because I don't think the list has anyone from there) could very well remember things completely opposite and also be correct. -- Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605 Department of Computer Science FAX -- (505) 646-1002 New Mexico State University http://www.cs.nmsu.edu/~pfeiffer Southwestern NM Regional Science and Engr Fair: http://www.nmsu.edu/~scifair
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
On Fri, 18 Jan 2002 17:03:55 - Tony Lambley [EMAIL PROTECTED] wrote: Back in the 80's people were using the Synclavier for audio on video productions. I know they were serious beasts, but I doubt they would have kept all that data in RAM. The latter Fairlights were probably similar. Anyone have any first hand experience of them? I used to work at Fairlight (long after the CMI days). I still have friends there and one in particular knows the guts and implementation of the CMI very well. I'll quiz him on this subject. Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ A sufficiently advanced programming error is indistinguishable from the Windows 95 Operating System.
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
juhana writes: In any case, preload in multitrack editor is totally different from a disk sampler. why do you think that? --p
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
On Fri, 18 Jan 2002, Joe Pfeiffer wrote: Dan Hollis writes: On Tue, 15 Jan 2002, Joe Pfeiffer wrote: IANAL, but as near as I can tell the USPTO has almost completely given up on their responsibility to actually evaluate patents before granting them. The philosophy seems to be that they'll let anything go through, and if somebody doesn't like it let the courts sort it out. IMHO the individual examiners should be held liable if the patent is found invalid due to prior art. A good idea in principle, but given the amounts of money involved you'd never be able to hire another examiner... Ok, dock their pay, slash their benefits, whatever. They need to be penalized for sloppy work. Right now there is NO INCENTIVE for them to do good work, and it shows. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
RE: [linux-audio-dev] EVO status...was: (open-source like hardware)
Err ... perhaps I missed something, is there some place where the latest (whatever that means) EVO could be retrieved ? (for us EU citizens ...) Thanks !
RE: [linux-audio-dev] EVO status...was: (open-source like hardware)
On Thu, 2002-01-17 at 10:08, xfm wrote: Err ... perhaps I missed something, is there some place where the latest (whatever that means) EVO could be retrieved ? (for us EU citizens ...) Thanks ! www.linuxdj.com/evo Marek
Re: [linux-audio-dev] EVO status...
On Wed, Jan 16, 2002 at 03:28:53PM +0100, Tobias Ulbricht wrote: On Tue, 15 Jan 2002, Paul Davis wrote: Thats actually a good point... I guess the answer is if 2 GB is enough RAM to have enough channels to overload the CPU and IO bandwith of the host. Things like GigaSampler allow you to layer and a bunch of instruments into one channel. It would still limit you when using things like GigaPiano which has a _huge_ sample size for each piano. What about dynamic sampling? i.e. different samples for different velocity ranges? Is that already included in *one* .gig-sample? I've never played with GigaSampler, so I dunno how they look like. At least I can imagine, that you will always be able to increase the throughput proportional to the sound quality (by higher quality samples, layering of multiple samples, and younameit.), so I'd like to see the cached HD sampling. Yes, this is done, there are different velocity layers possible. Actually, you can have lots of layers in different dimensions, for example creating samples with both the sustain pedal up and down. Actually, I know of at least one project where a piano was sampled and the result didn't fit in a .gig, because of the 2GB filesize limitation imposed by windows. I believe 8 velocity layers with and without sustain were used. thanks for reminding me of the other 2 reasons why just use lots of RAM doesn't work in the general case. --p
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
Hi! Halion does use the smae technology BUT steinberg have shown that they have been using an equivalent algorithm before the patent have actually been granted to Nemesys. Where? will you ask? Well, in cubase of course! Every audio sequencer I know of have to do read ahead of audio data if they want to be useable! So for exemple if Paul have been using an equivalent scheme in Ardour I believe he has the right to create a sampler using this algorithm without any problem. Being radicaly optimistic, let's say that ardour being a community work, every people working in the community may have the right to use a technology that have been using prior to the patent. I'm far from being an atorney but i'd really like to get the insights of one on this specific view of the problem. Sebastien PS: ho , and yes, I'm pretty sure about the reason why Steinberg didn't have any problem with the pattent because one friend of mine actually worked on Halion... - Original Message - From: Paul Davis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 15, 2002 7:54 PM Subject: Re: [linux-audio-dev] EVO status...was: (open-source like hardware) I have also been in contacted by Nemesis and they have indicated that if I were to do anything that infringes on thier patent(s) they _WILL_ litigate. My initial inquiries with a patent attorney indicates that a typical patent fight runs about a Million dollars. A little more than I can afford currently. i wonder what's going on with steinberg. halion clearly uses the same technology; i seem to recall a story on harmony central about a lawsuit, or maybe it was in sound on sound. not sure though.
Re: [linux-audio-dev] EVO status...
Hello. We have prior art for keeping beginnings of samples in memory for instant play in context of multitrack audio. People have also written jingle players which keeps the start in memory and loads the rest from disk. My first Linux program (at 1995) was a sample player which with I could assign samples to keys and play the samples by pressing the keys --- by pressing a key multiple times, the same sample was played with multiple instances (i.e., the previous instance was not turned off). The design was also to keep beginnings of samples in memory, and read the rest directly from the disk, but I just were not able to implement it with my programming skills. No public documentation either Best regards, Juhana
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
It's my understanding that if a patented technology is proved to have been in use by someone other than the holder of the patent, before the patent was filed, then the patent itself is void. I could be wrong - it may indeed just be that whoever was using the technology before the patent was filed gets to keep using it. I'm too lazy to look it up. :) I do, however, know that in either case, that claim has to be proven. And that takes a court. And a lawyer. And money. So just because you're in the right, even if you have the means to prove it, doesn't mean you won't escape any patent dispute without a hefty legal fee. I have no idea why I typed all that. You guys all already know this. :P I'm new here, by the way. Hi. :D Sage - Original Message - From: Sebastien Metrot [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 17, 2002 2:14 PM Subject: Re: [linux-audio-dev] EVO status...was: (open-source like hardware) Hi! Halion does use the smae technology BUT steinberg have shown that they have been using an equivalent algorithm before the patent have actually been granted to Nemesys. Where? will you ask? Well, in cubase of course! Every audio sequencer I know of have to do read ahead of audio data if they want to be useable! So for exemple if Paul have been using an equivalent scheme in Ardour I believe he has the right to create a sampler using this algorithm without any problem. Being radicaly optimistic, let's say that ardour being a community work, every people working in the community may have the right to use a technology that have been using prior to the patent. I'm far from being an atorney but i'd really like to get the insights of one on this specific view of the problem. Sebastien PS: ho , and yes, I'm pretty sure about the reason why Steinberg didn't have any problem with the pattent because one friend of mine actually worked on Halion... - Original Message - From: Paul Davis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 15, 2002 7:54 PM Subject: Re: [linux-audio-dev] EVO status...was: (open-source like hardware) I have also been in contacted by Nemesis and they have indicated that if I were to do anything that infringes on thier patent(s) they _WILL_ litigate. My initial inquiries with a patent attorney indicates that a typical patent fight runs about a Million dollars. A little more than I can afford currently. i wonder what's going on with steinberg. halion clearly uses the same technology; i seem to recall a story on harmony central about a lawsuit, or maybe it was in sound on sound. not sure though.
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
Sebastien Metrot writes: Halion does use the smae technology BUT steinberg have shown that they have been using an equivalent algorithm before the patent have actually been granted to Nemesys. Where? will you ask? Well, in cubase of course! Every audio sequencer I know of have to do read ahead of audio data if they want to be useable! So for exemple if Paul have been using an equivalent scheme in Ardour I believe he has the right to create a sampler using this algorithm without any problem. IANAL (as always) but my understanding is that any use -- even use before the *filing* of the patent -- becomes subject to royalties when the patent is granted. Of course, if you used the idea before the patent-holder came up with the idea, that would invalidate the patent. It's my understanding that under US patent law, the ``race to the patent office'' to determine precedence doesn't really happen -- who wins is based on who can document having had the idea first, regardless of who files first. -- Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605 Department of Computer Science FAX -- (505) 646-1002 New Mexico State University http://www.cs.nmsu.edu/~pfeiffer Southwestern NM Regional Science and Engr Fair: http://www.nmsu.edu/~scifair
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
On Wed, 16 Jan 2002, Richard Smith wrote: I have also been in contacted by Nemesis and they have indicated that if I were to do anything that infringes on thier patent(s) they _WILL_ litigate. I'm sure it had nothing to do with the fact that in an e-mail conversation with one of the managers I refered to thier patents as totally bogus. The reply e-mail after that got a little ;) ... this is probably redundant as most of you read slashdot, but this was just too close to our patent topic: Scientific American - the four worst patents granted http://www.sciam.com/2002/0202issue/0202patents.html -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
On Wed, 2002-01-16 at 01:20, Paul Davis wrote:
as i said, unix-like operating systems have done disk readahead for almost
as long as unix-like operating systems have existed (and multics
before them, i believe). we cannot allow nemesys/conexant to steal
this technology by pretending it was invented explicitly for audio. if
the USPTO doesn't understand this (and they probably {d,w}on't),
Why not?
because in general, one can characterize a great deal of human
invention as the process of taking an idea from one domain and
applying it to another.
It's important to know whether this is a legal definition or just a
decision of the USPTO(see also sect.282 US pat. act: presumption of
validity). Would be useful to check on precedents set by previous courts
decisions..
almost every software patent is covered by
this description (those that are not probably deserve their awards
IMHO). the patent office has shown absolute willingness to issue
patents to people who take a technique applied to problem domain A and
use it in problem domain B. despite it being simple to show a complete
abstract isomorphism between the two techniques, the fact that one of
them is about operating systems and files in general and the other is
about audio and samplers and musical response times convinces the
patent office time and time again that real innovation has
occured. the idea of an abstract algorithm doesn't seem to strike the
USPTO as a compelling idea. so when someone figures out a way to
preload part of an x-ray image so that its quicker for a doctor to
display them, or preload the start of a video stream to help with
response to the play button, they will accept these as legitimate
innovation-by-crossing-domain-boundaries.
i think this is idiotic, but its absolutely, undeniably the way they
see the world.
Seems it's time to change that... Don't ask me how :)
what nemesys/conexant did was clever, and good. it was not, and should
never have been patentable.
I guess fraunhofer was much more creative with it's MP3(from techincal
point of view).
Marek
Re: [linux-audio-dev] EVO status...
On Tue, 15 Jan 2002, Paul Davis wrote: Thats actually a good point... I guess the answer is if 2 GB is enough RAM to have enough channels to overload the CPU and IO bandwith of the host. Things like GigaSampler allow you to layer and a bunch of instruments into one channel. It would still limit you when using things like GigaPiano which has a _huge_ sample size for each piano. What about dynamic sampling? i.e. different samples for different velocity ranges? Is that already included in *one* .gig-sample? I've never played with GigaSampler, so I dunno how they look like. At least I can imagine, that you will always be able to increase the throughput proportional to the sound quality (by higher quality samples, layering of multiple samples, and younameit.), so I'd like to see the cached HD sampling. thanks for reminding me of the other 2 reasons why just use lots of RAM doesn't work in the general case. --p
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
Paul Davis wrote: I would like to code up a proto of the interface though. I was planning on trying to do it with python and something like wxPython. Mostly because Python is my new favorite language and I need a good graphics project to work on. any chance you'd consider using pyGTK and python? --p Or pyqt? (I know Paul loves KDE so much 8-) WxWindows feels heavy. It seems to have quite a large footprint when running on Linux boxes. That's why I gave up using it. N/
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
Or pyqt? (I know Paul loves KDE so much 8-) heh. i love it as much as i love GNOME :) --p
[linux-audio-dev] EVO status...was: (open-source like hardware)
On Mon, 14 Jan 2002 20:43:16 -0500, Paul Davis wrote: Benno's disk sampler evo? would be cool :) yeah, it would, except that all of its developers have vanished off the face of the earth and nothing has happened to it in at least 6 months. not to mention that the hard part - designing and building a GUI - wasn't even started. at least we could get inspiration from Well being one of those people I guess I should speak up and debunk the nasty rumor that I have vanished off the face of the earth before it spreads. I'm just happen to be in lurker mode now. Since we are on the subject guess now is a good time to yap about the current status. Or lack of current status perhaps. My last contact withs benno (who has the sampler code) was last summer when I help provide him with some samples for demo he did at LinuxTag. He mentioned that he has worked on the sampler code and has improved it some but hasn't made another release yet. Further on the sampler side. I have purchased the patent and challenge history for both of the patents held by Conexant and Nemesis for a computer/disk based sampler. The patents are very broad and IMHO very bogus. I have also been in contacted by Nemesis and they have indicated that if I were to do anything that infringes on thier patent(s) they _WILL_ litigate. My initial inquiries with a patent attorney indicates that a typical patent fight runs about a Million dollars. A little more than I can afford currently. There is an option where you can request the patent to re-evaluate the patent. However, if they still don't find any problems then you just made the patent _much_ harder to invalidate. Better to actually challenge it. Just more $$ Originally I was all about messing with the sampler stuff despite the patents. But after all the stuff with the Dmitry Sklyarov case I am a little leery of any public involvement with the sampler code. There were several people on this list that thought they had references to prior art. If you have that please send it to me. At some point I would like to challenge the patent(s) but not unless I have lots of evidence that its invalid. As far as the GUI goes... There actually was some initial work done. Just no code. I have lots of prototype interface screens that my buddy Mike Bailey designed using Word 2000. Its actually quite impressive what he was able to do. The screens are all graphic images he built and they are linked together so that if you click on a button it actually brings up another screen. I despise MS products but never-the-less I was impressed. I would post it somewhere but its huge like 50 Megs or so and the conversion to html mucks it all up. (Thats MS for you) The GUI stuff pretty much stopped right after he did that. Mike got a new baby, and a new job. And turns out that the new GigaStudio does just about everything he was asking for in the EVO system. So with lack of time and lack of motivation very little movement happened. I would like to code up a proto of the interface though. I was planning on trying to do it with python and something like wxPython. Mostly because Python is my new favorite language and I need a good graphics project to work on. Gonna be a while before I mess with it though. Lots of other projects with much higher priority. Anyway if any one else wants to mess with the GUI proto stuff that I have let me know and I'll see about getting some sort of description on what's what and set it up for download somewhere. -- Richard A. Smith Bitworks, Inc. [EMAIL PROTECTED] 501.846.5777 x204 Sr. Design Engineerhttp://www.bitworks.com
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
Well being one of those people I guess I should speak up and debunk the nasty rumor that I have vanished off the face of the earth before it spreads. I'm just happen to be in lurker mode now. sorry for seeding misinformation. I have also been in contacted by Nemesis and they have indicated that if I were to do anything that infringes on thier patent(s) they _WILL_ litigate. My initial inquiries with a patent attorney indicates that a typical patent fight runs about a Million dollars. A little more than I can afford currently. i wonder what's going on with steinberg. halion clearly uses the same technology; i seem to recall a story on harmony central about a lawsuit, or maybe it was in sound on sound. not sure though. There is an option where you can request the patent to re-evaluate the patent. However, if they still don't find any problems then you just made the patent _much_ harder to invalidate. Better to actually challenge it. Just more $$ Originally I was all about messing with the sampler stuff despite the patents. But after all the stuff with the Dmitry Sklyarov case I am a little leery of any public involvement with the sampler code. this is definitely a problem. let me make two suggestions. 1) i will try to arrange a time to talk to fairly good friend of mine who is a patent attorney, and see if i can flush out the options a little more. 2) i can see no reason not to write EVO so that it doesn't explicitly do anything like the patent's claim. this can be done very easily by the most obvious (yet inapplicable prior art): use the kernel's own disk caching. let me expand on (2) just a little bit. the main reason why the patent should not have been granted is that it takes a generic method (readahead with a cache) and applies it to a specific domain without actually changing or improving the generic method. we can use this to our advantage. instead of writing code that infringes on the patent, simply write code that uses the facilities of the OS to do the same thing completely transparently. there are a couple of easy ways to do this. to infringe the patent, my recollection is that it will be necessary to explicitly read the data from disk, keep it in a special location, and use that location at the onset of audio synthesis. it might be enough to just read the data and throw it away. a clever patent attorney might be able to argue that this was infringing because we knew that the kernel would keep the data around and we still read the data. in this case, use mmap, and access the data via a pseudo-random pointer walk without any explicit pointer loading. it will be easy to point out that a change in the behaviour of the kernel will break the readahead behaviour, and therefore it cannot be true that readahead is being done by the program. i cannot see how a lawyer could possibly argue that we are infringing the patent when there will be no code in the program that does anything like what the patent describes. the fact that our OS of choice happens to do readahead, using a methodology that predates the patent by at least 25 years, seems to me be unimpeachable. its true that we will still be left with code whose only purpose is to initiate readahead by the kernel. that then raises tricky legal questions about infringement: since we don't do the readahead, we aren't infringing, but since we initiate the readahead, perhaps we are. the result of both methods are that the kernel will have stuffed a certain amount of data into the buffer cache, and the next time we go to read it, although access will not be as fast as it being in user space already, it won't be much different (and will definitely be orders of magnitude faster than it coming from the disk). the only problem is that over an extended period of time, the kernel might throw away the data from the buffer cache. i think there may be ways to deal with that, but i will need to think about them carefully. i will also discuss this strategy with my patent lawyer friend to see just how watertight or pathetic it may actually be. As far as the GUI goes... There actually was some initial work done. Just no code. I have lots of prototype interface screens that my buddy Mike Bailey designed using Word 2000. Its actually quite impressive what he was able to do. The screens are all graphic images he built and they are linked together so that if you click on a button it actually brings up another screen. I despise MS products but never-the-less I was impressed. I would post it somewhere but its huge like 50 Megs or so and the conversion to html mucks it all up. (Thats MS for you) the problem with demos like this is that represent only a tiny fraction of the real work, and once the working version is operational, many changes typically become necessary from testing. writing complex GUIs like this is a huge amount of work, and prototyping screen transitions is a tiny part of that in my
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
Sorry, I've obviously missed the start of this issue. Are you saying that sampling to HD is patented and no one can develop software that has this functionality? --- On Mon, 14 Jan 2002 20:43:16 -0500, Paul Davis wrote: Benno's disk sampler evo? would be cool :) yeah, it would, except that all of its developers have vanished off the face of the earth and nothing has happened to it in at least 6 months. not to mention that the hard part - designing and building a GUI - wasn't even started. at least we could get inspiration from Well being one of those people I guess I should speak up and debunk the nasty rumor that I have vanished off the face of the earth before it spreads. I'm just happen to be in lurker mode now. Since we are on the subject guess now is a good time to yap about the current status. Or lack of current status perhaps. My last contact withs benno (who has the sampler code) was last summer when I help provide him with some samples for demo he did at LinuxTag. He mentioned that he has worked on the sampler code and has improved it some but hasn't made another release yet. Further on the sampler side. I have purchased the patent and challenge history for both of the patents held by Conexant and Nemesis for a computer/disk based sampler. The patents are very broad and IMHO very bogus.
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
Sorry, I've obviously missed the start of this issue. Are you saying that sampling to HD is patented and no one can develop software that has this functionality? No. The patent is about reading samples *from* HD and compensating for the slowness of the initial HD seek by buffering the first few msec of all samples in ram, allowing for immediate playback while buying time for the hd to find the sample and stream the remainder. Prior to this, all samplers (that I know of) had to have the entire sample library in ram. This raises a question. Now that desktop computers can contain 2 GB of ram, has the window of opportunity closed for this technology? It might be easiest to flow around this rock. Tom
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
* Paul Davis ([EMAIL PROTECTED]) wrote: I would like to code up a proto of the interface though. I was planning on trying to do it with python and something like wxPython. Mostly because Python is my new favorite language and I need a good graphics project to work on. any chance you'd consider using pyGTK and python? Why do you recommend this in favor of wxPython, when wxPython buys you two extra platforms for free (and an easier, better documented API)? Full Disclosure: I have experience with wxWindows (C++), and only one short experience with pyGTK. I've been frightened away from trying GTK in C by looking at existing code and the scant API reference. Joshua -- Joshua Haberman [EMAIL PROTECTED]
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
On Tue, 15 Jan 2002 13:54:40 -0500, Paul Davis wrote: Well being one of those people I guess I should speak up and debunk the nasty rumor that I have vanished off the face of the earth before it spreads. I'm just happen to be in lurker mode now. sorry for seeding misinformation. No worries. I can see where you would get the idea though. From an onlookers viewpoint the project does seem to have vanished. I have also been in contacted by Nemesis and they have indicated that if I were to do anything that infringes on thier patent(s) they _WILL_ litigate. My initial inquiries with a patent attorney indicates that a typical patent fight runs about a Million dollars. A little more than I can afford currently. i wonder what's going on with steinberg. halion clearly uses the same technology; i seem to recall a story on harmony central about a lawsuit, or maybe it was in sound on sound. not sure though. Hmm.. Dunno. I have to look into this some more. Maybe they are paying a royality? this is definitely a problem. let me make two suggestions. 1) i will try to arrange a time to talk to fairly good friend of mine who is a patent attorney, and see if i can flush out the options a little more. Excellent. Thanks for your help. 2) i can see no reason not to write EVO so that it doesn't explicitly do anything like the patent's claim. this can be done very easily by the most obvious (yet inapplicable prior art): use the kernel's own disk caching. That would be good. However, Benno lives in Italy where he in unencumbered by US software patent balony. And its his intentions to write his sampler code in such a way as to provide the best performance regardless of US patents. Which IMHO is probally the best policy for him. (At least unless Italy decides to honor software patents) I imagine that leaving the stream buffer management to the OS involve a lot of code rework from his base. I haven't dug into his code too deep so I don't really know. Maybe it won't. In either case it will involve duplicate effort. WRT the proto GUI Work the problem with demos like this is that represent only a tiny fraction of the real work, and once the working version is operational, many changes typically become necessary from testing. writing complex GUIs like this is a huge amount of work, and prototyping screen transitions is a tiny part of that in my experience. Amen brother. Your preaching to the choir here. I do GUI stuff at the day job and I know exactly what you mean. But, I'm a coder and not a UI designer. Having someone else design the UI and present to me how they want it to work is so much better than a nebulus idea of what they want. Mike B. has lots of experience with lots of different packages and what seemed to me to be some really good ideas on a UI. If you tell me straight up I want this screen to to this, with these options, I can consume raw materials, (pizza caffiene) crunch away, and kick out code which does just that. Ask me to design you a UI and things get messy. I'm good at code. I suck at dreaming up UIs. Having a clear target template even if it is just pictures, is a large first step at not creating a monster. So far Python is awesome. It's such a wondful thing to not have to deal with memory mangement issues. And the built in list/tupil data types are really a time saver. I'm still pretty green on python code but I think once I got going I could really start rocking. (Assuming I actually carve out the time to work on it) I would like to code up a proto of the interface though. I was planning on trying to do it with python and something like wxPython. Mostly because Python is my new favorite language and I need a good graphics project to work on. any chance you'd consider using pyGTK and python? Sure. Although I'm partial to the cross-platform ability of Tkinter and wxWindows. As proficency in those frameworks would help me a lot with my day job which involves code running on both MS and linux. Tkinter has served me well so far but I really don't like the look of the non-native widget set with Tkinter. Do you have a specific reason for wanting pyGTK over wxWindows? -- Richard A. Smith Bitworks, Inc. [EMAIL PROTECTED] 501.846.5777 x204 Sr. Design Engineerhttp://www.bitworks.com
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
On Tue, 15 Jan 2002 12:30:29 -0800, Tom wrote: This raises a question. Now that desktop computers can contain 2 GB of ram, has the window of opportunity closed for this technology? It might be easiest to flow around this rock. Thats actually a good point... I guess the answer is if 2 GB is enough RAM to have enough channels to overload the CPU and IO bandwith of the host. Things like GigaSampler allow you to layer and a bunch of instruments into one channel. It would still limit you when using things like GigaPiano which has a _huge_ sample size for each piano. Dunno. Perhaps you could store the audio in ram compressed with one of the non-lossy audio comprssion algos? Those can get 2:1 can't they. That would make it 4 gigs which would probally do for all but really demanding stuff. For smaller sample sets that would indeed be an easy way around the patent with almost identical capability. Even though SDRAM is up in price from 2 months ago it's still pretty cheap. -- Richard A. Smith Bitworks, Inc. [EMAIL PROTECTED] 501.846.5777 x204 Sr. Design Engineerhttp://www.bitworks.com
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
* Paul Davis ([EMAIL PROTECTED]) wrote: I would like to code up a proto of the interface though. I was planning on trying to do it with python and something like wxPython. Mostly because Python is my new favorite language and I need a good graphics project to work on. any chance you'd consider using pyGTK and python? Why do you recommend this in favor of wxPython, when wxPython buys you two extra platforms for free (and an easier, better documented API)? because wxWindows is restricted to being the lowest common denominator of the toolkits it wraps. i also don't agree that the API is better documented. there are 2 excellent books on GTK+ programming (both online), and an almost complete API reference manual online. there are things i have wanted to do in ardour that wxWindows would make exceedingly painful because it involves deep messing around with the GUI internals, something wxWindows cannot allow (since it has no single set of internals). a simple example: when you click on a record enable button, it cannot turn on directly from the click handler/callback/whatever. with an MVC (Model-View-Controller) programming model, the click is simply a request made using the button as a controller. when the state of the model changes (i.e. a track is actually record enabled), the button is used as a view, and its state is changed to represent this. now, in GTK+, its fairly easily to subvert the usual handling of button clicks and so forth. but the alternative to this is to make every widget with this kind of behaviour (i.e. most of them in an MVC system) into a generic drawing area where you either dump a pixmap or draw some text and lines and stuff. this means that you are basically back to Xlib and don't actually have a toolkit working very hard at all to make your life easier. i don't believe you could possibly carry out this subversion with wxWindows in a portable fashion. i may be wrong. finally, i'm not sure what the 2 extra platforms are. MacOS is the only significant one I can think of. GTK+ for win32 seems to exist and be pretty effective. GTK+ also provides support, like Qt, for direct framebuffer systems, making it effective in embedded systems that do not run X Window, which wxWindow does not do correctly, i am told. --p
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
Thats actually a good point... I guess the answer is if 2 GB is enough RAM to have enough channels to overload the CPU and IO bandwith of the host. Things like GigaSampler allow you to layer and a bunch of instruments into one channel. It would still limit you when using things like GigaPiano which has a _huge_ sample size for each piano. thanks for reminding me of the other 2 reasons why just use lots of RAM doesn't work in the general case. --p
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
This raises a question. Now that desktop computers can contain 2 GB of
ram, has the window of opportunity closed for this technology? It might
be easiest to flow around this rock.
this is a very important point.
however, people with only 128 or 256 or 512MB of RAM won't find much
comfort from it when they are unable to use the GigaPiano samples, for
example. i think that telling people they need 2GB (or even 1GB) or
RAM to get decent sampler performance isn't really very friendly, or
necessary.
as i said, unix-like operating systems have done disk readahead for almost
as long as unix-like operating systems have existed (and multics
before them, i believe). we cannot allow nemesys/conexant to steal
this technology by pretending it was invented explicitly for audio. if
the USPTO doesn't understand this (and they probably {d,w}on't), then
we need to harness the power of the OS to circumvent the patent.
--p
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
There is an option where you can request the patent to re-evaluate the patent. However, if they still don't find any problems then you just made the patent _much_ harder to invalidate. Whoops I guess I should read more carefully next time. :)) Still, with those arguments Paul stated, it's very likely to achieve this. Marek
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
as i said, unix-like operating systems have done disk readahead for almost
as long as unix-like operating systems have existed (and multics
before them, i believe). we cannot allow nemesys/conexant to steal
this technology by pretending it was invented explicitly for audio. if
the USPTO doesn't understand this (and they probably {d,w}on't),
Why not?
They should..(?) Or there's lots of $$$ floating around...
Marek
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
On Tue, 15 Jan 2002, Richard A. Smith wrote: Further on the sampler side. I have purchased the patent and challenge history for both of the patents held by Conexant and Nemesis for a computer/disk based sampler. The patents are very broad and IMHO very bogus. I have also been in contacted by Nemesis and they have indicated that if I were to do anything that infringes on thier patent(s) they _WILL_ litigate. My initial inquiries with a patent attorney indicates that a typical patent fight runs about a Million dollars. A little more than I can afford currently. Recording audio to disk? Didn't Max Matthews / Laurie Spiegel and friends at the Bell Telephone Labs invent that? The GROOVE system? Back in the 1960s or 1970s?? Check Laurie's web page :-). -- M. Edward Borasky [EMAIL PROTECTED] The COUGAR Project http://www.borasky-research.com/Cougar.htm How to Stop A Folksinger Cold # 1 Home, home on the range, where the deer and the antelope play... The antelope cheats.
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
as i said, unix-like operating systems have done disk readahead for almost
as long as unix-like operating systems have existed (and multics
before them, i believe). we cannot allow nemesys/conexant to steal
this technology by pretending it was invented explicitly for audio. if
the USPTO doesn't understand this (and they probably {d,w}on't),
Why not?
because in general, one can characterize a great deal of human
invention as the process of taking an idea from one domain and
applying it to another. almost every software patent is covered by
this description (those that are not probably deserve their awards
IMHO). the patent office has shown absolute willingness to issue
patents to people who take a technique applied to problem domain A and
use it in problem domain B. despite it being simple to show a complete
abstract isomorphism between the two techniques, the fact that one of
them is about operating systems and files in general and the other is
about audio and samplers and musical response times convinces the
patent office time and time again that real innovation has
occured. the idea of an abstract algorithm doesn't seem to strike the
USPTO as a compelling idea. so when someone figures out a way to
preload part of an x-ray image so that its quicker for a doctor to
display them, or preload the start of a video stream to help with
response to the play button, they will accept these as legitimate
innovation-by-crossing-domain-boundaries.
i think this is idiotic, but its absolutely, undeniably the way they
see the world.
what nemesys/conexant did was clever, and good. it was not, and should
never have been patentable.
--p
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
* Paul Davis ([EMAIL PROTECTED]) wrote: * Paul Davis ([EMAIL PROTECTED]) wrote: I would like to code up a proto of the interface though. I was planning on trying to do it with python and something like wxPython. Mostly because Python is my new favorite language and I need a good graphics project to work on. any chance you'd consider using pyGTK and python? Why do you recommend this in favor of wxPython, when wxPython buys you two extra platforms for free (and an easier, better documented API)? [...] there are things i have wanted to do in ardour that wxWindows would make exceedingly painful because it involves deep messing around with the GUI internals, something wxWindows cannot allow (since it has no single set of internals). Would messing with the GUI internals even be possible from Python without modifying the bindings? a simple example: when you click on a record enable button, it cannot turn on directly from the click handler/callback/whatever. I'm not sure what you mean by this. with an MVC (Model-View-Controller) programming model, the click is simply a request made using the button as a controller. when the state of the model changes (i.e. a track is actually record enabled), the button is used as a view, and its state is changed to represent this. now, in GTK+, its fairly easily to subvert the usual handling of button clicks and so forth. but the alternative to this is to make every widget with this kind of behaviour (i.e. most of them in an MVC system) into a generic drawing area where you either dump a pixmap or draw some text and lines and stuff. this means that you are basically back to Xlib and don't actually have a toolkit working very hard at all to make your life easier. i don't believe you could possibly carry out this subversion with wxWindows in a portable fashion. i may be wrong. Audacity (which uses wxWindows) currently uses two custom widgets which have capabilities not provided by the corresponding wxWindows classes: mainly, that they use custom images for drawing. Each of these widgets is a class that derives from wxWindow (which acts as the generic drawing area you describe), and both are between 100 and 150 lines. I don't think that's unreasonable. finally, i'm not sure what the 2 extra platforms are. MacOS is the only significant one I can think of. GTK+ for win32 seems to exist and be pretty effective. I wasn't aware that GTK+ on windows is a usable port. Well, if you count MacOS 9 and X, then you have 2. :-) GTK+ also provides support, like Qt, for direct framebuffer systems, making it effective in embedded systems that do not run X Window, which wxWindow does not do correctly, i am told. That's a good point. It seems that this should be possible with wxWindows since it wraps GTK, but maybe wxWindows' other dependencies prevent this. My primary object to wxWindows is that it's so big, which would be understandable if you use their logging, IPC, networking, printing, DnD, Database, and threading functionality, but for just the GUI it seems overkill. Also, wxWindows doesn't yet have the ability to load interfaces from a resource file (ala GLADE) though I believe they're working on it. Also, though the resulting code is portable to several platforms where wxWindows has been ported, it's *extremely* non-portable to others, because wx-isms seep into every part of your code. I think this question of cross-platform toolkit or not will become more significant as the toolkits become better and as OS use diversifies (more people are using Mac and Linux all the time). What I've done with my most recent project is write as much as possible in portable C++. For the rest, I use small cross-platform libraries (as opposed to a monolithic beast like wxWindows), and small abstract classes to encapsulate the platform-specific functionality. Porting to a new platform will hopefully be as simple as implementing these classes. Joshua -- Joshua Haberman [EMAIL PROTECTED]
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
Marek Peteraj writes:
as i said, unix-like operating systems have done disk readahead for almost
as long as unix-like operating systems have existed (and multics
before them, i believe). we cannot allow nemesys/conexant to steal
this technology by pretending it was invented explicitly for audio. if
the USPTO doesn't understand this (and they probably {d,w}on't),
Why not?
They should..(?) Or there's lots of $$$ floating around...
IANAL, but as near as I can tell the USPTO has almost completely given
up on their responsibility to actually evaluate patents before
granting them. The philosophy seems to be that they'll let anything
go through, and if somebody doesn't like it let the courts sort it out.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
Southwestern NM Regional Science and Engr Fair: http://www.nmsu.edu/~scifair
Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
* Paul Davis ([EMAIL PROTECTED]) wrote: Also, though the resulting code is portable to several platforms where wxWindows has been ported, it's *extremely* non-portable to others, because wx-isms seep into every part of your code. right. in my experience, you can't avoid this. thats why i think toolkit wrappers are really rather silly. you're just trading in one set of isms for another, with possible changes in portability. I can see why they would be silly for something like Ardour, but for a project: 1. whose target audience spans several platforms 2. that utilizes a significant portion of the wrapper's functionality 3. whose requirements don't significantly exceed the wrapper's capabilities ...they could be just what the doctor ordered. Especially with one as well-maintained as wxWin. Not to mention that I'd take native widgets over foreign-looking ones any day (I especially dislike Tk). I think this question of cross-platform toolkit or not will become more significant as the toolkits become better and as OS use diversifies (more people are using Mac and Linux all the time). What I've done with my most recent project is write as much as possible in portable C++. For the rest, I use small cross-platform libraries (as opposed to a monolithic beast like wxWindows), and small abstract classes to encapsulate the platform-specific functionality. Porting to a new platform will hopefully be as simple as implementing these classes. i find it almost impossible to imagine rewriting ardour/gtk in a different toolkit, let alone wrapping the functionality i rely on from GTK+ and/or gtkmm in a small abstract class. the GUI code is more or less as complex as the internal engine code in ardour, and it relies on its toolkit isms heavily. Hah, I wouldn't dream of suggesting the small abstract class approach for something like Ardour! I should have mentioned that the project I'm testing this theory on is infinitely smaller, and an approach I would never consider for software of significant size. i have grown fonder of the idea of a pyGTK version of ardour/gtk, just to cut down on compile times, but i doubt that it will ever happen. Are their cons to this approach? How much work is it to write bindings? What are the performance penalties? Would the overhead of an interpreter rule out embedded systems? I appreciate your comments. I don't mean to be antagonistic, just trying to gain perspective. Joshua -- Joshua Haberman [EMAIL PROTECTED]
[linux-audio-dev] evo status?
Hi, i am wondering what the status of evo is? is it still in development? the sourceforge page has nothing, and the last time anything was touched in http://www.linuxdj.com/evo/ (which i found from the LAD archive) was about a year ago... i am wanting a sampler equivalent to the A3k etc, and would like to lend a hand to any work in progress before i go off and start my own... bodhi
Re: [linux-audio-dev] evo status?
bodhi wrote: Hi, i am wondering what the status of evo is? is it still in development? the sourceforge page has nothing, and the last time anything was touched in http://www.linuxdj.com/evo/ (which i found from the LAD archive) was about a year ago... i am wanting a sampler equivalent to the A3k etc, and would like to lend a hand to any work in progress before i go off and start my own... bodhi last thing i saw was benno senoner demonstrating his disksampler on linuxtag. benno, could you comment on this ? regards, jörn -- Jörn Nettingsmeier home://Kurfürstenstr.49.45138.Essen.Germany phone://+49.201.491621 http://spunk.dnsalias.org http://www.linuxdj.com/audio/lad/
Re: [linux-audio-dev] evo status?
On Tue, 11 Sep 2001 12:20:33 +0200 Jörn Nettingsmeier [EMAIL PROTECTED] wrote: bodhi wrote: Hi, i am wondering what the status of evo is? is it still in development? the sourceforge page has nothing, and the last time anything was touched in http://www.linuxdj.com/evo/ (which i found from the LAD archive) was about a year ago... i am wanting a sampler equivalent to the A3k etc, and would like to lend a hand to any work in progress before i go off and start my own... bodhi last thing i saw was benno senoner demonstrating his disksampler on linuxtag. benno, could you comment on this ? regards, jörn iiwusynth (http://www.hanappe.com/iiwusynth.html) is a sound font based sampler. Its been integrated into MusE. Note to Benno and others who are interested in sound fonts. I'm currently working on a sound font library from the Smurf (http://smurf.sourceforge.net) code base which will contain sound font loading/saving/editing functions as well as a database protocol for sending patch updates to programs/drivers. This library will be the basis for many cool things to be done with Smurf including direct integration with iiwusynth; the SmurfJam project which will be an online protocol for sharing sound font patches and transmitting midi data for doing online jam sessions; and perhaps it will be useful for ALSA sound font support as well. An online sound font database would be cool too, where you could search by preset name and even have it create a sound font on the fly with a number of presets and let you download it :) This library is still in heavy developement, but I'm excited about the possibilities. In the future it might turn into a more general patch library (DLS, etc), but for now I'm sticking to sound fonts. If anyone wants to be a part of this project, join me on the smurf-devel mailing list, you can find it off of the project page. Heres to continuing the coding and using of free software, despite the rest of the greedy commercial monster at large, may the monster grow ever smaller. Josh
