"In 2003, French companies received over seven billion US dollars more foreign investment than USA companies. In the past few years, Airbus have overtaken Boeing in sales and shipments. If France isn't innovating, how come people are investing in French companies more than in USA companies?"
It is true that FDI in the U.S. dropped pretty dramatically during 2000-2003, and I think that tracks pretty closely with the drop in currency value of the dollar against the euro. Similarly, you can see that FDI tanked in 2004 for france, as the price of the dollar started rising again.
"The French are not afraid to use nuclear power, making them the most energy independent Western nation. France pollutes less than the USA, CO2 in particular. As far as energy goes, they are beating the USA."
I can't argue with that, it's a shame that such a clean method of power generation goes unused because of political pressure from the left in the U.S.
"Reporters Without Borders ranked France as 30th in the world when it comes to freedom of the press. The USA languishes down at 44th. So much for freedom of speech."
Can't really argue that either. Reporters without borders is free to use whatever arbitrary criteria they choose to determine this.
"France has a 99% literacy rate. The USA has a 97% literacy rate. So much for education."
"Yes, I know you didn't state that you are from the USA, but experience tells me only one country produces idiots like you in mass quantities. The rest have idiots too, but there's less of them, and they say where they are from."
People want larger displays. To make larger displays look good, it helps to make them higher resolution. An NTSC DVD has a resolution of 640x480, which is not really all that great. Additionally NTSC displays only support interlaced display. Since a lot of the content that people watch are movies, shot on film running at 24 frames per second, it would be nice if you could display progressive content so that it would more closely match the source content. Yes, most DVD's are actually 24p, but to display this content on a NTSC television, your DVD player actually has to perform a pulldown on the content to turn it into interlaced.
Enter some sort of HD media to solve some of these problems. Both HD formats support progressive and interlaced content in a variety of resolutions (720p, 1080p, 1080i, etc). Both HD formats also support MPEG4 compression which is significantly more efficient and can produce images with a lot less artifacts than the MPEG2 that is on DVD's. Heck even DV video which is very compressed and color space constrained (4.1.1) loses a LOT of information when you encode it with MPEG2. Think how much detail you are losing when watching your typical Hollywood movie (probably scanned from film at 4K line resolution, and maybe edited RAW uncompressed).
In terms of raw resolution, going from SD to HD is the difference between playing your favorite FPS at 640x480 or running at 1024x768 (or 1280X1024).
For one thing, you can brace the camera much better using the viewfinder than you can holding the camera at arms length gawking at the LCD display. Most LCD displays are not really large enough to assess focus, where a viewfinder is usually a much larger effective viewing area.
There are exceptions of course. An LCD would be pretty handy if you want to take a picture at ground level.
It sounds like the problem you are having is fairly simple. You are creating audio content, but you have lost control of your distribution! I suggest you get together with other likeminded content producers and form an association to help control your distribution.
I suggest something like The Podcaster Industry Association of America. As a member of The Podcaster Industry Association of America, or PIAA, you could pool resources and even lobby state and federal legislature to assist you in recovery of your content. Perhaps someday, in the not so distant future, you might even successfully prosecute individuals who did not obtain your content via your distribution network. What a glorious day that will be for the PIAA!
"With HD sets starting at $500, my recommendation is to "jump onboard" to get a progressive scan picture. Walmart had a 42" plasma for $999 with an HD tuner built-in, though the display was technically EDTV, it's still better than interlaced and will look fantastic with digital broadcasts."
I was under the impression that most HD broadcasts were interlaced (1080i) You have more resolution but it is still interlaced. I think that perhaps ABC might broadcast in 720p?
My admittedly very unscientfic test. While perl is signifigantly faster, I think you would have to admit that the startup time difference between these four interpreters is fairly meaningless.
$ time ruby hello.rb Hello, World Ruby
real 0m0.120s user 0m0.077s sys 0m0.031s
$ time python hello.py Hello, World Python
real 0m0.126s user 0m0.093s sys 0m0.062s
$ time java -cp . hello Hello, World Java
real 0m0.127s user 0m0.015s sys 0m0.015s
$ time perl hello.pl Hello World Perl real 0m0.047s user 0m0.062s sys 0m0.015s
"RME Hammerfall and HDSP series (26 channels), M-Audio Delta 1010 (10/12 channels), AudioScience (8 channels) and at least 4 others fully and well supported on Linux are at least equal to the quality of ProTools HD. In fact are generally up with the best you can buy (for all digital interfaces, quality is most defined by your A/D + D/A converters, which have nothing to do with what you install in the computer. They cost significantly less than PT HD hardware. I leave it up to you to figure out why that is."
While I agree that RME gear is excellent, comparing it to ProTools HD is totally an apples and oranges comparison. Most people do not realize that ProTools HD and ProTools LE systems are entirely different beasts. Not everyone really needs this much DSP, but when you need it, you need it and there is very little else that can deliver. I think it would be more useful to compare a ProTools LE interface to something like RME (excluding of course that ProTools hardware includes ProTools software).
You may also not be aware that Digidesign now owns M-Audio, and they now produce a version of ProTools LE that works with basically all M-Audio gear.
Basically, total weight needs to be under 12 pounds. Most people try to keep it under 4-5. The FAA would like you to file in advance and inform them when you launch.
I bought a Dual 1.8 last night at the Apple store and they actually weren't going to let me have it because it had a copy of tiger stuffed in the box. Since I cannot use it with my hardware currently I managed to convince them to pull it out and give me the $9.95 coupon instead.
Very few people would have the proper system (most likely Pro Tools HD) to open up the real session, not to mention owning the various plugins. It seems like releasing a bunch of submixes like he did is the proper way to go.
It's not like you can't get someone to open the project in GarageBand and export it to whatever format you can use.
In theory the idea is that the "configuration" can be changed at runtime by some person who has the job "Application Deployer". So the developer maintains a n external config file.
In practice, this "Application Deployer" does not exist, and the developer is the only person who knows what the hell any of the stuff does. This makes the developer grumpy because he/she has to go digging thru a gross XML file to keep it in sync with their code. Whereas with XDoclet, the config information is right there with your code, so no hunting around, no maintaining external files.
In the case of using Hibernate, it's really a moot point, since you can use XDoclet to generate your XML file for you and still have the ability to change the XML file at runtime.
As an additional comment, EJB3 (And Hibernate3) address this metadata/config issue by using Java Annotations. I think this will pretty much kill off XDoclet.
Yes, but what magically puts it in the database? Nothing, the developer has to do this. Again the whole point is that this is not a zero configuration system, you are just offloading the configuration somewhere else.
"No, RoR's models don't come from maintained SQL files. I believe it uses reflection to dynamically build the models."
I understand that RoR is not literally reading some sql file containing DDL. My point is merely that the database schema does not magically appear from nowhere. You as the developer have to create and maintain this DDL somehow. Most developers would probably maintain this as one or many sql files that they would blow into the database as needed.
No. You can use the other components of Rails (ActionPack and the Web Service portion) without using ActiveRecord."
Developing a database web application using RoR would be a bit pointless without the ActiveRecord portion now wouldnt it? I think I was fairly clear ly discussing the persistence portion of RoR.
Please correct me if this is a mis-characterization, but RoR replaces maintaining long detailed XML configuration files with maintaing long, detailed database specific sql files.
Using RoR, you create a table and let Ruby dynamically determine a bunch of information about relationships and data types and then you access various properties of this data. You are also forced to use RoR's Object model (You have to extend ActiveRecord, correct?)
Using something like Hibernate, you write an object, then do something do describe it (Java Annotations, XDoclet markup, tedious XML configuration file) and It can create the DDL/alter tables on the fly for you, and you are not forced to extend any object.
To me each approach seems to have merit, as well as inherent drawbacks.
"Ruby has already inspired a few efforts to duplicate the technology in Java and in.NET. Since the core technology behind RoR is open classes, and the ability to add accessors and functionality on the fly, the other languages just don't cut it."
I can't speak about.NET, but the ability to add methods on the fly has been available in Java for quite some time, and the metadata features added in 1.5 enhance this by providing a language hook for tools that do this (as opposed to using XML config files). This is essentially how the popular and mature persistence framework Hibernate works (and the upcoming EJB 3.0 which is essentially Hibernate ).
The examples seemed very simple and straightforward, but I didn't care for them putting the queries essentially on the pages, since I find that very tedious and error-prone in the long run. I would assume Rails would make it easy enough to have methods which do the queries for you and simply return collections to be used on the page.
I see they have added support for a few more databases recently. Still no Oracle however:)
Lots of musicians are afraid of/confused by computers, and find an all-in-one solution like this keyboard much friendlier. There are quite a large number of dedicated hardware products available (disk based recorders, samplers, etc) that are easily duplicated with a PC or Mac and software.
This product is also (presumably) building on the legacy of the Korg Triton, which is a almost as much a fixture in large studios as an MPC or a Neve preamp.
In terms of input, the oxygen8 is cute and cool, but it is really more of a midi controller than a keyboard replacement. I would be hard pressed to do some real playing on that. On the other hand, when I want to do some real playing, I walk over to my 6'1 grand piano, which is the ultimate in portable:)
I think you entirely missed the point of my post, which was that the Gumstix is a fantastic, featureful and inexpensive SBC. I'm sure the (in your opinion) superior NetBSD would run on it just fine, considering how common the arch is.
If you are in the market for something like this, try a Gumstix (www.gumstix.com). They are 200/400 mhz xscale boards with 4 meg of flash and 64 meg of ram, running 2.6 linux kernel. They have 2 serial ports, usb client, bluetooth, MMC card, GPIO. I believe the new versions with ethernet and CF slots are getting close to competion. They are also TINY and consume around 100mw going full blast (at least that is my experience). They also provide a toolchain and everything needed to build your own kernel. Very cool.
"The defect of Java I feel most is its lack of flexibility. There's one paradigm and that's what you have to use. There are no macros, and the recently introduced generics are but a poor substitute."
I agree that java is somewhat inflexible, but macros? come on! The whole point of eliminating macros is to eliminate confusion and reduce complexity.
"The vanilla runtime environment is a huge download, and the development environment is even worse. The VM takes up a lot of memory, and the startup time basically rules out efficient little programs (think Unix commands). AFAIK, neither the runtime nor the development environment come with a run-time debugger. There's no such thing as incremental compilation or a read-eval-print loop."
I just downloaded the Ruby-all-in-one enviornemt for windows and it clocked in at around 14 meg, so its hardly "light". I suspect that most of this is various cygwin crud needed to get it to work, but the point remains. Since this is supposed to be a thread about J2ME, I would point out that I have a JVM running on arm-xscale that clocks in at about 500K (i am lazy and it is statically linked) + whatever libs I decide to include. If you can convince people to put Ruby or Lisp on a phone, more power to ya:)
I agree that Java is probably not the best enviornment for what would essentially be command line utilites due to VM overhead (at least the Sun VM anyway).
I'm not sure when you last used Java, but it has come with a debugger for ages, check out "jdb" In fact it has had support for remote debugging and profiling of JVM's for quite some time.
AFAIK you can't do a read-eval-print loop in Ruby either, but somehow it is more elegant? (feel free to prove me wrong)
"Some things exist in Java, but are a pain to use. For example, anonymous methods (useful, for example, for mapping over a sequence), need to be wrapped in classes. Iterators exist, but are clumsy. Containers like List and Vector store Objects, which is practically never what you really want."
If you dont like Iterators, there is a simple foreach syntax
for(int i: ints)
doSomething(i);
Not sure what the beef with the container classes is, but they autobox primitives for you if that is what you need. If your concern is the overhead of the boxing, well then perhaps you should be writing in C.
"Benchmarks tell me my Radeon 9800 is horribly out of date and imply its too weak to play any modern games. But I know from experience, that's bullshit."
Slashdot Mirror
"In 2003, French companies received over seven billion US dollars more foreign investment than USA companies. In the past few years, Airbus have overtaken Boeing in sales and shipments. If France isn't innovating, how come people are investing in French companies more than in USA companies?"
5 _fs_fr_en.pdf5 _fs_us_en.pdf
_ HDI.pdf
Not according to U.N. Figures
http://www.unctad.org/sections/dite_dir/docs/wir0
http://www.unctad.org/sections/dite_dir/docs/wir0
It is true that FDI in the U.S. dropped pretty dramatically during 2000-2003, and I think that tracks pretty closely with the drop in currency value of the dollar against the euro. Similarly, you can see that FDI tanked in 2004 for france, as the price of the dollar started rising again.
"The French are not afraid to use nuclear power, making them the most energy independent Western nation. France pollutes less than the USA, CO2 in particular. As far as energy goes, they are beating the USA."
I can't argue with that, it's a shame that such a clean method of power generation goes unused because of political pressure from the left in the U.S.
"Reporters Without Borders ranked France as 30th in the world when it comes to freedom of the press. The USA languishes down at 44th. So much for freedom of speech."
Can't really argue that either. Reporters without borders is free to use whatever arbitrary criteria they choose to determine this.
"France has a 99% literacy rate. The USA has a 97% literacy rate. So much for education."
Again, according to the U.N.
http://hdr.undp.org/reports/global/2005/pdf/HDR05
This is seems to be untrue.
"Yes, I know you didn't state that you are from the USA, but experience tells me only one country produces idiots like you in mass quantities. The rest have idiots too, but there's less of them, and they say where they are from."
Anonymous Coward? Heh.
People want larger displays. To make larger displays look good, it helps to make them higher resolution. An NTSC DVD has a resolution of 640x480, which is not really all that great. Additionally NTSC displays only support interlaced display. Since a lot of the content that people watch are movies, shot on film running at 24 frames per second, it would be nice if you could display progressive content so that it would more closely match the source content. Yes, most DVD's are actually 24p, but to display this content on a NTSC television, your DVD player actually has to perform a pulldown on the content to turn it into interlaced.
Enter some sort of HD media to solve some of these problems. Both HD formats support progressive and interlaced content in a variety of resolutions (720p, 1080p, 1080i, etc). Both HD formats also support MPEG4 compression which is significantly more efficient and can produce images with a lot less artifacts than the MPEG2 that is on DVD's. Heck even DV video which is very compressed and color space constrained (4.1.1) loses a LOT of information when you encode it with MPEG2. Think how much detail you are losing when watching your typical Hollywood movie (probably scanned from film at 4K line resolution, and maybe edited RAW uncompressed).
In terms of raw resolution, going from SD to HD is the difference between playing your favorite FPS at 640x480 or running at 1024x768 (or 1280X1024).
For one thing, you can brace the camera much better using the viewfinder than you can holding the camera at arms length gawking at the LCD display. Most LCD displays are not really large enough to assess focus, where a viewfinder is usually a much larger effective viewing area.
There are exceptions of course. An LCD would be pretty handy if you want to take a picture at ground level.
It sounds like the problem you are having is fairly simple. You are creating audio content, but you have lost control of your distribution! I suggest you get together with other likeminded content producers and form an association to help control your distribution.
I suggest something like The Podcaster Industry Association of America. As a member of The Podcaster Industry Association of America, or PIAA, you could pool resources and even lobby state and federal legislature to assist you in recovery of your content. Perhaps someday, in the not so distant future, you might even successfully prosecute individuals who did not obtain your content via your distribution network. What a glorious day that will be for the PIAA!
"With HD sets starting at $500, my recommendation is to "jump onboard" to get a progressive scan picture. Walmart had a 42" plasma for $999 with an HD tuner built-in, though the display was technically EDTV, it's still better than interlaced and will look fantastic with digital broadcasts."
I was under the impression that most HD broadcasts were interlaced (1080i) You have more resolution but it is still interlaced. I think that perhaps ABC might broadcast in 720p?
My admittedly very unscientfic test. While perl is signifigantly faster, I think you would have to admit that the startup time difference between these four interpreters is fairly meaningless.
$ time ruby hello.rb
Hello, World Ruby
real 0m0.120s
user 0m0.077s
sys 0m0.031s
$ time python hello.py
Hello, World Python
real 0m0.126s
user 0m0.093s
sys 0m0.062s
$ time java -cp . hello
Hello, World Java
real 0m0.127s
user 0m0.015s
sys 0m0.015s
$ time perl hello.pl
Hello World Perl
real 0m0.047s
user 0m0.062s
sys 0m0.015s
"RME Hammerfall and HDSP series (26 channels), M-Audio Delta 1010 (10/12 channels), AudioScience (8 channels) and at least 4 others fully and well supported on Linux are at least equal to the quality of ProTools HD. In fact are generally up with the best you can buy (for all digital interfaces, quality is most defined by your A/D + D/A converters, which have nothing to do with what you install in the computer. They cost significantly less than PT HD hardware. I leave it up to you to figure out why that is."
While I agree that RME gear is excellent, comparing it to ProTools HD is totally an apples and oranges comparison. Most people do not realize that ProTools HD and ProTools LE systems are entirely different beasts. Not everyone really needs this much DSP, but when you need it, you need it and there is very little else that can deliver.
I think it would be more useful to compare a ProTools LE interface to something like RME (excluding of course that ProTools hardware includes ProTools software).
You may also not be aware that Digidesign now owns M-Audio, and they now produce a version of ProTools LE that works with basically all M-Audio gear.
The FAA permits these types of launches provided they meet certain criteria.
http://www.eoss.org/pubs/faaball.htm
Basically, total weight needs to be under 12 pounds. Most people try to keep it under 4-5. The FAA would like you to file in advance and inform them when you launch.
If you feel strongly, you could just contact your senator yourself. http://www.senate.gov/general/contact_information/ senators_cfm.cfm/
I'm sure that a letter/email/fax from an actual constituent would carry a lot more weight than a bulk fax from some guy with a website.
I bought a Dual 1.8 last night at the Apple store and they actually weren't going to let me have it because it had a copy of tiger stuffed in the box. Since I cannot use it with my hardware currently I managed to convince them to pull it out and give me the $9.95 coupon instead.
:)
A bit lame
Very few people would have the proper system (most likely Pro Tools HD) to open up the real session, not to mention owning the various plugins. It seems like releasing a bunch of submixes like he did is the proper way to go.
It's not like you can't get someone to open the project in GarageBand and export it to whatever format you can use.
I'll take a shot.
In theory the idea is that the "configuration" can be changed at runtime by some person who has the job "Application Deployer". So the developer maintains a n external config file.
In practice, this "Application Deployer" does not exist, and the developer is the only person who knows what the hell any of the stuff does. This makes the developer grumpy because he/she has to go digging thru a gross XML file to keep it in sync with their code. Whereas with XDoclet, the config information is right there with your code, so no hunting around, no maintaining external files.
In the case of using Hibernate, it's really a moot point, since you can use XDoclet to generate your XML file for you and still have the ability to change the XML file at runtime.
As an additional comment, EJB3 (And Hibernate3) address this metadata/config issue by using Java Annotations. I think this will pretty much kill off XDoclet.
Yes, but what magically puts it in the database? Nothing, the developer has to do this. Again the whole point is that this is not a zero configuration system, you are just offloading the configuration somewhere else.
"No, RoR's models don't come from maintained SQL files. I believe it uses reflection to dynamically build the models."
I understand that RoR is not literally reading some sql file containing DDL. My point is merely that the database schema does not magically appear from nowhere. You as the developer have to create and maintain this DDL somehow. Most developers would probably maintain this as one or many sql files that they would blow into the database as needed.
No. You can use the other components of Rails (ActionPack and the Web Service portion) without using ActiveRecord."
Developing a database web application using RoR would be a bit pointless without the ActiveRecord portion now wouldnt it? I think I was fairly clear ly discussing the persistence portion of RoR.
Please correct me if this is a mis-characterization, but RoR replaces maintaining long detailed XML configuration files with maintaing long, detailed database specific sql files.
Using RoR, you create a table and let Ruby dynamically determine a bunch of information about relationships and data types and then you access various properties of this data. You are also forced to use RoR's Object model (You have to extend ActiveRecord, correct?)
Using something like Hibernate, you write an object, then do something do describe it (Java Annotations, XDoclet markup, tedious XML configuration file) and It can create the DDL/alter tables on the fly for you, and you are not forced to extend any object.
To me each approach seems to have merit, as well as inherent drawbacks.
1. Sign up for "secret NSA mailing list" at http://www.biometrics.org/html/listserv.html
2. Read archives
3. Super haxxor!
You are right J2EE does not scale
http://www.eweek.com/article2/0,1759,1640234,00
I did not grok the example properly, it looks like the finder(s) are safely tucked away behind the controller, which is good.
"Ruby has already inspired a few efforts to duplicate the technology in Java and in .NET. Since the core technology behind RoR is open classes, and the ability to add accessors and functionality on the fly, the other languages just don't cut it."
.NET, but the ability to add methods on the fly has been available in Java for quite some time, and the metadata features added in 1.5 enhance this by providing a language hook for tools that do this (as opposed to using XML config files). This is essentially how the popular and mature persistence framework Hibernate works (and the upcoming EJB 3.0 which is essentially Hibernate ).
:)
I can't speak about
The examples seemed very simple and straightforward, but I didn't care for them putting the queries essentially on the pages, since I find that very tedious and error-prone in the long run. I would assume Rails would make it
easy enough to have methods which do the queries for you and simply return collections to be used on the page.
I see they have added support for a few more databases recently. Still no Oracle however
Lots of musicians are afraid of/confused by computers, and find an all-in-one solution like this keyboard much friendlier. There are quite a large number of dedicated hardware products available (disk based recorders, samplers, etc) that are easily duplicated with a PC or Mac and software.
:)
This product is also (presumably) building on the legacy of the Korg Triton, which is a almost as much a fixture in large studios as an MPC or a Neve preamp.
In terms of input, the oxygen8 is cute and cool, but it is really more of a midi controller than a keyboard replacement. I would be hard pressed to do some real playing on that. On the other hand, when I want to do some real playing, I walk over to my 6'1 grand piano, which is the ultimate in portable
I think you entirely missed the point of my post, which was that the Gumstix is a fantastic, featureful and inexpensive SBC. I'm sure the (in your opinion) superior NetBSD would run on it just fine, considering how common the arch is.
If you are in the market for something like this, try a Gumstix (www.gumstix.com). They are 200/400 mhz xscale boards with 4 meg of flash and 64 meg of ram, running 2.6 linux kernel. They have 2 serial ports, usb client, bluetooth, MMC card, GPIO. I believe the new versions with ethernet and CF slots are getting close to competion. They are also TINY and consume around 100mw going full blast (at least that is my experience). They also provide a toolchain and everything needed to build your own kernel. Very cool.
Check them out!
"The defect of Java I feel most is its lack of flexibility. There's one paradigm and that's what you have to use. There are no macros, and the recently introduced generics are but a poor substitute."
:)
I agree that java is somewhat inflexible, but macros? come on! The whole point of eliminating macros is to eliminate confusion and reduce complexity.
"The vanilla runtime environment is a huge download, and the development environment is even worse. The VM takes up a lot of memory, and the startup time basically rules out efficient little programs (think Unix commands). AFAIK, neither the runtime nor the development environment come with a run-time debugger. There's no such thing as incremental compilation or a read-eval-print loop."
I just downloaded the Ruby-all-in-one enviornemt for windows and it clocked in at around 14 meg, so its hardly "light". I suspect that most of this is various cygwin crud needed to get it to work, but the point remains. Since this is supposed to be a thread about J2ME, I would point out that I have a JVM running on arm-xscale that clocks in at about 500K (i am lazy and it is statically linked) + whatever libs I decide to include. If you can convince people to put Ruby or Lisp on a phone, more power to ya
I agree that Java is probably not the best enviornment for what would essentially be command line utilites due to VM overhead (at least the Sun VM anyway).
I'm not sure when you last used Java, but it has come with a debugger for ages, check out "jdb" In fact it has had support for remote debugging and profiling of JVM's for quite some time.
AFAIK you can't do a read-eval-print loop in Ruby either, but somehow it is more elegant? (feel free to prove me wrong)
"Some things exist in Java, but are a pain to use. For example, anonymous methods (useful, for example, for mapping over a sequence), need to be wrapped in classes. Iterators exist, but are clumsy. Containers like List and Vector store Objects, which is practically never what you really want."
If you dont like Iterators, there is a simple foreach syntax
for(int i: ints)
doSomething(i);
Not sure what the beef with the container classes is, but they autobox primitives for you if that is what you need. If your concern is the overhead of the boxing, well then perhaps you should be writing in C.
"Benchmarks tell me my Radeon 9800 is horribly out of date and imply its too weak to play any modern games. But I know from experience, that's bullshit."
Freecell is not a modern game.
"I been called ugly, fugly, pug fugly but never ugly ugly" - Moe Sizlak