1) Elements sucks. Really, it does. Or you have to pay for good plugins anyway, so what's the point. OTH, if all you're doing is touching up digital pictures, I'd recommend it.
2) Save-disabled demo? Useless. The idea is to get PhotoShop into your workflow. It's only useful if you already have a copy and what to see what changed.
That being said, I use GIMP. I've pirated PhotoShop now and then, and because of that, I appreciate it. If I ever was in a situation where I _needed_ Photoshop, I'd buy it. And that's thanks to ease of pirating, not 1) or 2) above.
Thank you for clearing this up. It wasn't making sense until now.
So MonsterPatterns is going to have to pony up a little money to pay someone to recreate "not-to-scale" drawings of the the patterns they sell for significant mark-up.
at least around here the local authorities have the decency to look the other way when would-be home-improvement types take a few sheets of discarded particle board or what-not.
Just do it on a weekend, and the sub-cons don't care. They'd only be mad if you did it while they're on site, as you present a liability if you get hurt. That's about it.
is extended ext2 attributes (google for the kernel patch and userland utils) It allows you to give attributes to files, (like "category") I understand there's also gnome support.
can be solved with a sophisticated enough upsampling DAC. By upsample, it means to fill in the detail (recreated by truncated sinc function approximations) so the simple fitler in the DAC (much lower order, operating at high bitrate now) can have enough headroom to track.
These are not uncommon in higher-end CD players (not the one in your PC, that's for sure).
You do have a point however that a lot of research is being done on higher dynamic ranges and higher sampling frequenties, but as I understand it, this is mostly because higher sampling rates seem to work better with more then stereo sound (5.1 and stuff).
(this is me repeating something I heard awhile back, feel free to correct me if I am wrong.) I believe you are quite right. It appears humans can hear phase difference even at frequencies above 8kHz, which at bitrates of 44.1 kHz become more difficult to resolve spatially (you get down to 6 discrete wavefront angles). Hence a 96kHz stereo recording sounds a bit more lively, even if it sounds the same as 44.1 through a monoural speaker.
that after the 20th press of a master into the substrate, the signal will no longer bear any resemblance to a 44kHz square wave, and you'll probably not be within of the original 6dB at the 2nd (or is that actually the 3rd?) harmonic.
1) Analog vs. discrete amps have nothing to do with analog vs. digital signals.
2) Digital signals when played do not have "breaks" or "steps" or any such nonsense. The information in the stream is used to drive a D/A converter, which uses specially designed filters to provide an approximation of the recorded signal to within the quantization noise floor (depending on bit depth and D/A quality), and reproducing frequencies up to half the sampling rate. Due to the imperfections in design, (both purposeful and physically unavoidable), the resulting signal is quite smooth, continous, and (should be) devoid of undesriable components. A crappy consumer CD player or amp is often at fault for this effect, but I doubt they will "harshen" the sound with high frequencies (near or above Nyquist) as the cheap components are "loose" and inaccurate. It'll just sound for shit.
A warm recording played back from a CD through a diligently accurate reproduction device will sound just as warm.
At the worst, the channel capacity of a CD may be to narrow, lending a somewhat less lively sound, or not enough dynamic range (if 90dB is not enough for you). So that's what SACD is for.
I am suspicious of a website with only a flash intro and no mention of:
1) Chosen site 2) Plans 3) Who's paying for the construction costs 4) Pictures
etc.
I mean, if you're going to hype it up, give us something to be hyped about. I'm not buying plane tickets 2 months in advanced if I can't be sure to see a spectacle.
On the recent thinkpads, there's a BIOS option that says: "Boot default display: {CRT, LCD, both}".
It works like a charm. There's no reason to not select "both" unless you need an extra 10 min. on your battery. And Fn-F7 toggles (wow, another one), if needed.
Works in Windows, Linux, et. al without fuss. You may have to add a monitor driver in Windows the first time it gets used (but I never saw that message... maybe it was autodetected during install as Generic XGA or some such)
He's sent copies of his "exploits" around the world through his friends. Everyone who matters to him knows, and the rest of the world can use the google cache.
especially since OSS is often (and arguably most useful) used to augment existing systems, with no expectation of redistribution. It is up to the project managers to make a product that delivers; forget about NSTISS or the GPL.
And most COTS systems in use don't have the certs anyway, and no one gets in a tizzy. It's only if you wanted to hook it up to SIPRNET or something (and then it gets reviewed independantly anyway).
This is just some stuff to make the guys funding the projects (Congress) feel better.
- Install generic postscript printer in Windows. Try the Lexmark C9xx series.
- Get a windows version of ps2pdf (free).
- Print to file using fake printer from first step, then convert said file into pdf using ps2pdf.
- Profit!
You can also try getting Aladdin Ghostscript for Windows which gives you a nice interface to do the PDF conversion, but while free, it's a bit heavy handed. You should never have to pay for Adobe Distiller, that's for sure.
If you are uber cool, you will use a text-editor like emacs or somesuch and just type the XML that describes all your elements, and then import, and wallah!
All you have to do is move the traces around if you don't like how it looks.
Personally I haven't done that but I've shot through one such document making local/global changes and it's veeeerrryy useful. Fuck Visio!
Creating a game is more than creating a nice story or idea.
You have to design the mode of gameplay. Rules, potential interactions, outline a potential game engine. Technologies that might be used, etc.
Game designers have lots of ideas that could be made into games. But the games are incredibly difficult to create, so they are not in need of ideas. What they really need is talent to turn those ideas into something fun.
In order for an idea to be considered, the specification document must read like the game manual to a paper-based RPG with all the little details, and preferably storyboards, sketches, etc, not to mention a requirements document as well. Basically, the amount of detail required goes above and beyond the idea of a movie script.
You have to probably have already coded some test environments in an existing game engine just to see if your ideas could hold water.
At this point you could probably pitch it to someone if they were in a slump.
I used to sketch out ideas for games in boring classes. So did all my friends. Are any of them going to see the light of day? Hell no! If some of us were good game coders, then maybe they might have a chance. Otherwise they're just ideas. Anyone who plays games has tons of them, and most aren't original.
Let me revise my comments on the idea of a cdda-filesystem. I realized I don't disagree really with what you said.
It would make sense if it was implemented as follows:
Mounting the cdrom through cddafs presents the user with a listing of.wav files (or.raw files, depending on mount options), both with information from the TOC and possibly CDDB.
Each file is a character device that when read begins extracting the data via CDDA from the appropriate track AND reading other tracks simultaneously engages some complex locking and wait-queueing to prevent contention and increase performance.
Each character device allows it to receive ioctls similar to/dev/cdrom which allow it to seek within the track, etc. A mount option would transform them into block files capable of seeking but only reading in sector sized chunks.
File oriented-software wouldn't choke on that (but the driver wouldn't have to work too hard)
OR... a pipe or socket. But as to not being seekable, etc: that's why we have the distinction in the first place! For things that aren't like a file, they shouldn't be a file. We need appropriate metaphors for things that are not flat and seekable. Duh character devices aren't seekable, that's the POINT. In fact, upon further reflection: the reason why a CD-filesystem is a bad idea is because only one process can use it at a time!!! (^_^;;;) Making some resource a filesystem implies that it can deal with at least concurrent access, right? I'm not saying you can't do it, but I don't think it's a good idea because it doesn't really get you anything special. After further reflection, the cd-extraction "device" almost begs to be a character file. Send it an ioctl (with a silly little command line util), then start slurping it into oggenc. The "cdparanoia" device... you might use it like this:
In this case, cdda:scd0.raw is the file that accepts the ioctls, and cdda:scd0.a is a magically created char device corresponding to your request to read a range from the CD, and data will only start appearing from there once all other requests have been fulfilled (otherwise you get EAGAIN on read()). I pretend that uld is a filesystem exported by a magic kernel module that allows user-space libs to do some grunt work and provide device files as needed.
Perfect way to queue up a bunch of jobs; just spawn a bunch of oggencs in parallel on the file requests, and let the kernel wake up the right process to do it.
And whatever happened to STREAMS? That would be a perfect way to take cdparanoia + ogg and roll it into a OS abstraction.
I'm talking about generic "uber-character devices" for asyncronously and syncronously available data, and a way to get at their individual ioctls without having to write whole C programs.
Some kinda standard for that would kick a large amount of ass, especially if its easily accessible from user space.
Slashdot Mirror
1) Elements sucks. Really, it does. Or you have to pay for good plugins anyway, so what's the point. OTH, if all you're doing is touching up digital pictures, I'd recommend it.
2) Save-disabled demo? Useless. The idea is to get PhotoShop into your workflow. It's only useful if you already have a copy and what to see what changed.
That being said, I use GIMP. I've pirated PhotoShop now and then, and because of that, I appreciate it. If I ever was in a situation where I _needed_ Photoshop, I'd buy it. And that's thanks to ease of pirating, not 1) or 2) above.
I'm glad people like you let us know slashdot is still humming.
Thank you for clearing this up. It wasn't making sense until now.
So MonsterPatterns is going to have to pony up a little money to pay someone to recreate "not-to-scale" drawings of the the patterns they sell for significant mark-up.
at least around here the local authorities have the decency to look the other way when would-be home-improvement types take a few sheets of discarded particle board or what-not.
Just do it on a weekend, and the sub-cons don't care. They'd only be mad if you did it while they're on site, as you present a liability if you get hurt. That's about it.
is extended ext2 attributes (google for the kernel patch and userland utils)
It allows you to give attributes to files, (like "category")
I understand there's also gnome support.
48 or 96 kHz, 24-bit (or 16-bit), straight from the equipment masters, on CD-R (for singles) or DAT (for LP). Who said anything about Red-Book...
The technically inclined would know what to do with a dangerous format like that.
Check my journal in a few hours, I've got a standard brewing.
IHBT! IHL, and IHBD.
can be solved with a sophisticated enough upsampling DAC. By upsample, it means to fill in the detail (recreated by truncated sinc function approximations) so the simple fitler in the DAC (much lower order, operating at high bitrate now) can have enough headroom to track.
These are not uncommon in higher-end CD players (not the one in your PC, that's for sure).
You do have a point however that a lot of research is being done on higher dynamic ranges and higher sampling frequenties, but as I understand it, this is mostly because higher sampling rates seem to work better with more then stereo sound (5.1 and stuff).
(this is me repeating something I heard awhile back, feel free to correct me if I am wrong.)
I believe you are quite right. It appears humans can hear phase difference even at frequencies above 8kHz, which at bitrates of 44.1 kHz become more difficult to resolve spatially (you get down to 6 discrete wavefront angles).
Hence a 96kHz stereo recording sounds a bit more lively, even if it sounds the same as 44.1 through a monoural speaker.
that after the 20th press of a master into the substrate, the signal will no longer bear any resemblance to a 44kHz square wave, and you'll probably not be within of the original 6dB at the 2nd (or is that actually the 3rd?) harmonic.
Unless the master is made of tungsten. Christ.
1) Analog vs. discrete amps have nothing to do with analog vs. digital signals.
2) Digital signals when played do not have "breaks" or "steps" or any such nonsense. The information in the stream is used to drive a D/A converter, which uses specially designed filters to provide an approximation of the recorded signal to within the quantization noise floor (depending on bit depth and D/A quality), and reproducing frequencies up to half the sampling rate. Due to the imperfections in design, (both purposeful and physically unavoidable), the resulting signal is quite smooth, continous, and (should be) devoid of undesriable components.
A crappy consumer CD player or amp is often at fault for this effect, but I doubt they will "harshen" the sound with high frequencies (near or above Nyquist) as the cheap components are "loose" and inaccurate.
It'll just sound for shit.
A warm recording played back from a CD through a diligently accurate reproduction device will sound just as warm.
At the worst, the channel capacity of a CD may be to narrow, lending a somewhat less lively sound, or not enough dynamic range (if 90dB is not enough for you). So that's what SACD is for.
Cheers.
I am suspicious of a website with only a flash intro and no mention of:
1) Chosen site
2) Plans
3) Who's paying for the construction costs
4) Pictures
etc.
I mean, if you're going to hype it up, give us something to be hyped about. I'm not buying plane tickets 2 months in advanced if I can't be sure to see a spectacle.
On the recent thinkpads, there's a BIOS option that says: "Boot default display: {CRT, LCD, both}".
It works like a charm. There's no reason to not select "both" unless you need an extra 10 min. on your battery.
And Fn-F7 toggles (wow, another one), if needed.
Works in Windows, Linux, et. al without fuss. You may have to add a monitor driver in Windows the first time it gets used (but I never saw that message... maybe it was autodetected during install as Generic XGA or some such)
Computer scientists, you know, the ones who write operating system code, and develop new crazy shit yeah, them... they use
1) Linux
2) OSX
3) WinNT
4) FreeBSD
5) Solaris
6) OpenBSD
7) other {Tru64, AIX, Plan9, custom}
in that order.... (pretty close anyway, that's from my random sampling around the grad/undergrad dept.)
So why again does using Windows help you embrace Computer Science? Or windowsity... made up words... zughhhhhh!!!
ARRRGHHH MODS ARE INSANE!~!!!!!!!!@@!@!@
that he can't wrestle with that judge... for now.
He's sent copies of his "exploits" around the world through his friends. Everyone who matters to him knows, and the rest of the world can use the google cache.
... and it didn't crash often, it'll get approved. Or if it has "Microsoft, SGI, or IBM" in the name (almost forgot).
Typical, eh?
especially since OSS is often (and arguably most useful) used to augment existing systems, with no expectation of redistribution. It is up to the project managers to make a product that delivers; forget about NSTISS or the GPL.
And most COTS systems in use don't have the certs anyway, and no one gets in a tizzy. It's only if you wanted to hook it up to SIPRNET or something (and then it gets reviewed independantly anyway).
This is just some stuff to make the guys funding the projects (Congress) feel better.
PPC970 (or a derivative)
I don't think there should be a problem (cackles evilly)
Plainsboro residents always were a bit off. I think it's the WSJ plant.
- Install generic postscript printer in Windows. Try the Lexmark C9xx series.
- Get a windows version of ps2pdf (free).
- Print to file using fake printer from first step, then convert said file into pdf using ps2pdf.
- Profit!
You can also try getting Aladdin Ghostscript for Windows which gives you a nice interface to do the PDF conversion, but while free, it's a bit heavy handed. You should never have to pay for Adobe Distiller, that's for sure.
This looks like a job for...
DIA!
If you are uber cool, you will use a text-editor like emacs or somesuch and just type the XML that describes all your elements, and then import, and wallah!
All you have to do is move the traces around if you don't like how it looks.
Personally I haven't done that but I've shot through one such document making local/global changes and it's veeeerrryy useful. Fuck Visio!
Creating a game is more than creating a nice story or idea.
You have to design the mode of gameplay. Rules, potential interactions, outline a potential game engine. Technologies that might be used, etc.
Game designers have lots of ideas that could be made into games. But the games are incredibly difficult to create, so they are not in need of ideas. What they really need is talent to turn those ideas into something fun.
In order for an idea to be considered, the specification document must read like the game manual to a paper-based RPG with all the little details, and preferably storyboards, sketches, etc, not to mention a requirements document as well. Basically, the amount of detail required goes above and beyond the idea of a movie script.
You have to probably have already coded some test environments in an existing game engine just to see if your ideas could hold water.
At this point you could probably pitch it to someone if they were in a slump.
I used to sketch out ideas for games in boring classes. So did all my friends. Are any of them going to see the light of day? Hell no! If some of us were good game coders, then maybe they might have a chance. Otherwise they're just ideas. Anyone who plays games has tons of them, and most aren't original.
Let me revise my comments on the idea of a cdda-filesystem. I realized I don't disagree really with what you said.
.wav files (or .raw files, depending on mount options), both with information from the TOC and possibly CDDB.
/dev/cdrom which allow it to seek within the track, etc. A mount option would transform them into block files capable of seeking but only reading in sector sized chunks.
It would make sense if it was implemented as follows:
Mounting the cdrom through cddafs presents the user with a listing of
Each file is a character device that when read begins extracting the data via CDDA from the appropriate track AND reading other tracks simultaneously engages some complex locking and wait-queueing to prevent contention and increase performance.
Each character device allows it to receive ioctls similar to
File oriented-software wouldn't choke on that (but the driver wouldn't have to work too hard)
OR... a pipe or socket.
/dev/uld/cdda:scd0.raw /dev/uld/cdda:scd0.a
/dev/uld/cdda:scd0.a
/lib/modules/streams/vorbisenc.so -oq=5,oggwrap /dev/uld/cdda:scd0.a
/dev/uld/cdda:scd0.a > "KMFDM - Waste.ogg"
But as to not being seekable, etc: that's why we have the distinction in the first place!
For things that aren't like a file, they shouldn't be a file. We need appropriate metaphors for things that are not flat and seekable.
Duh character devices aren't seekable, that's the POINT. In fact, upon further reflection: the reason why a CD-filesystem is a bad idea is because only one process can use it at a time!!! (^_^;;;) Making some resource a filesystem implies that it can deal with at least concurrent access, right? I'm not saying you can't do it, but I don't think it's a good idea because it doesn't really get you anything special.
After further reflection, the cd-extraction "device" almost begs to be a character file. Send it an ioctl (with a silly little command line util), then start slurping it into oggenc. The "cdparanoia" device... you might use it like this:
$ cddactl --extract 1[1:30]-3[4:00]
oggenc [ some stuff ]
In this case, cdda:scd0.raw is the file that accepts the ioctls, and cdda:scd0.a is a magically created char device corresponding to your request to read a range from the CD, and data will only start appearing from there once all other requests have been fulfilled (otherwise you get EAGAIN on read()). I pretend that uld is a filesystem exported by a magic kernel module that allows user-space libs to do some grunt work and provide device files as needed.
Perfect way to queue up a bunch of jobs; just spawn a bunch of oggencs in parallel on the file requests, and let the kernel wake up the right process to do it.
Or you could do something evil like this:
$ streamctl --push
Then:
$ cat
That is definitely in the spirit of Unix!
And whatever happened to STREAMS? That would be a perfect way to take cdparanoia + ogg and roll it into a OS abstraction.
I'm talking about generic "uber-character devices" for asyncronously and syncronously available data, and a way to get at their individual ioctls without having to write whole C programs.
Some kinda standard for that would kick a large amount of ass, especially if its easily accessible from user space.
It's written in a weird bastardized version of C (not unlike Objective C) that is used internally by the OS and compiler groups.
Wolfram Research took a similar approach when creating Mathematica.
Anyway, you didn't hear this from me.