Misunderstanding on your part when you use the word 'capture'.
"This is a windows only issues, but why is it that the DV manufacturers decided in their infinite wisdom to make it so you could only record in one format (DV)?"
DV is the format the recording is stored on the tape. There *is* no 'capture' method when you transfer to the PC. Now, what you want is a program that converts from the DV stream into your codec of choice *before* it is stored onto the drive.
Quicktime gives you leeway by letting you tell the system your bandwidth and instant on settings.
In the same way Safari2 would know too... "Oh, he's not using his bandwidth" or "Hmm, he's got crappy bandwidth"
So this has rambled. Let me reiterate, then:
Perhaps a drawer or a pane for tabs/views/links/bookmarks. Personally I like a row of horizontal 'tabs' over a row of vertical 'links' but that's a quibble over interface layout' like the difference between a text only toolbar and a window attached menubar:D
Clicking in 'smart' bookmarks has nigh instantaneous response because the system has 'preloaded' the page. It will periodically check for a delta, and download it, according to your tastes and your bandwidth.
As per screen real estate, these tabs/views/links/bookmarks collapse into the 'Window' menu if they are active, 'Bookmarks' if they aren't. Clicking on a Bookmark opens the site; if the site is already open, it refreshes it.
Closing a view opens up the next 'smart' bookmark in the stack, sorta like turning pages or popping a stack.
Opening a view puts a new page on the stack.
Closing the last view closes the window.
Double clicking on a view pops open a new window. Closing the window doesn't get rid of a view until it is removed from the stack, however.
iTunes only provides one playlist view at a time *unless* you double click on a playlist, and a new window opens up.
But clicking on each playlist brings up a different 'view' in the same window, so in that respect iTunes supports multiple views in one window.
In the *same* analogy sense, tabbed browsing, via tabs rather than playlists, supports multiple views in one window: Click on any tab, and a different view is presented.
So that's all I mean when I say that multiple views, one window, is workable for web browsing because it's already been implemented in iTunes, iPhoto, Mail, etc. One 'view' is active at a time, yes, but they do have a collection of alternative views switchable at any time. Does this sound like bookmarks? Perhaps, but implementation wise you can imagine that Safari2 precaches a select list of bookmarks so that when you click on the link it loads instantaneously. That is, theoretically, how tabbed view can be framed in a coherent and consistent interface, I believe.
How can I use the Dock? What I want is *one* HTML window with multiple HTML views.
The Dock gives me multiple HTML windows with one HTML view each, and one Moz icon with multiple Windows accessable via the menu.
An analogy would be how Mail.app keeps multiple emails but only provides one window, unless you double click on an email, and then giving you additional windows.
Mail's email list is ordered by date, since emails can logically be ordered by date received, though some people like to order them by priority, by sender, by subject, etc.
If we imagine a hypothetical web browser with a 'list' view, we could order sites by alphabet, date, user preference, or rank. Using this hypothetical web browser would not be any different than using Mail.app, theoretically.
What you would be doing *different* than the 1 window 1 view is that you are collapsing multiple sites into one 'browser'. The same way that iTunes is an mp3 browser, iPhoto is a photo browser, Finder is a file browser, Mail is an email browser, then Safari2 could be a 'website browser'.
Tabs are the implementation Mozilla uses, but it's not the only way. Having a drop down, having a list view, having a hierarchy, or a playlist view, etc, works. If you look at Safari, it already has this idea, in that bookmarks are available in a playlist like view. The difference is that, for performance reasons, Safari could 'preload' select special sites so that clicking on the bookmark would nigh instantaneously access the site, instead of loading off the web.
So I do believe the multiple website interface is workable, if only because iTunes, iPhoto, Finder, and Mail, as well as the Dock and Application Switcher, all seem to implement something structurally similar.
What you are describing can be thought of as a stack!
So you remember the OS 9 tearable Application Switcher?
What if, instead of apps, they had a Website Switcher. Which, functionally, is similar to tabs. The drawback to tabs, right now, is that you cannot arrange them and cycle through them, so there is inefficiency in actually mousing to them, and they *also* don't show up in the Window menu.
If, however, you make tabs 'collapsable', in that you can move a window onto a stack and have them 'share' real estate, I think that would work.
In the sens of a stack, hitting 'close' would close the topmost window; makes sense, since that is the one the viewer is looking at, and closing a window that is not visible is going to be very error prone.
Likewise, creating a new 'view' should appear on the 'top' of the stack, but with a simple opt-select, can be dragged anywhere in the stack (it's only superficially a stack).
So now you've got 'views' and 'windows'. You can actually close windows, and kill all the views, or you can kill the views on layer at a time.
Oh, another metaphor! The Photoshop 'layers'. Or, the way Photoshop stacks tabbed windows atop each other.
I see nothing wrong itself with tabs or MDI. You can imagine each tab akin to an icon in the Dock, and the Site Switcher is akin to the Dock or the Application Switcher. People are not unuse to the idea now. New window will always create a single view, and you can drag views in and out of windows, and a window can store multiple views, each view selectable from a tab or from the Window->view menu (multiple views separated by a separator line). Again, it's no more complicated or difficult than the implementation of the Application Switcher, the Dock, Photoshop Layers, Photoshop Palette Windows, or even the tabs you find at the Apple website.
I can't say this implementation is the *end all* of this type of file association filing system, but all your cases are handled by a more effective version.
Case 1: The average home user *does* remember attributes for each and every file. Meaningful file names and locations. Use those. Other users, who *don't* use meaningful file names and locations can instead use what *they* find meaningful. Perhaps date and content attributes, or sizes, or last modification time?
Case 2: So do a search for file Y in F/O. The neat bit about searching (like Google) is the ability to use the *least* amount necessary to discriminate the data. If Y, F/O is sufficient, you just saved yourself the time of navigating/O/BAR, or that extra typing. Tab complete, for example, is similar in that the system intelligently autocompletes for you. If you typed 'Y in F'-tab, and it autocomplete the path, would you complain?
Case 3: Excellent idea. This is how it *should* work. The system classifies the files for you, either via prompting, on the fly, or continuously while the document is updated.
Case 4: So you rolled your own solution because there is no existing solution. Congratulations. The next scientist down the hall, who is less computer savvy than you are will appreciate a system like this, rather than DIY.
Other positive cases where this product *like this* is useful:
Searching for emails by content. The idea, when abstracted away, is the same. Most email programs already do this, some better than others.
Google (exact same idea, but applied to the web, instead of the filesystem) releases a product to organize and itemize your computer. Fine a file by any attribute you can remember, not *just* path. Right now you can only use the path. A file has other attributes than path.
Finding photos according to date, location, theme. iPhoto already does this. I'm sure other programs do to. Google does this, in a mechanical manner.
Finding music according to artist, name, album, year released, genre, style, appeal. iTunes does this, I'm sure other programs do to.
Address book functionality. Finding a person's phone number by looking for their name! Finding a person's address by looking for their name!
Finding word documents by summaries. Office already allows you to do this.
See a theme? What a system like this, when abstracted away into the OS or an API, is to allow *all* programs this kind of functionality, without forcing developers to reinvent the wheel over, and over, and over, again. One set of bugs, one set of problems, one set of developers, one set of fixes, rather than 80 different sets of bugs for 80 different apps and 80 different search methodologies and 80 different information indexing methods and 80 different application interfaces.
You could get Photoshop Elements. Yeah, it's more expensive than graphic converter, but you get 90% of Photoshop for 15% of the price, and it still beats the pants of GIMP for most stuff:)
Um, decent value for cheap price, and at convenient locations?
I always thought the Apple strategy was like the Honda racecar strategy: Vet and hone technology in a serious environment, like a racetrack or a video production house, and release similar but less hardcore technology to the consumer world.
It can support MPEG4, MJPEG, and h.XXX out of the box, and has Ogg and MPEG2 components (for both encoding and decoding) and can decode MPEG1 without any special effort.
What, exactly, is your problem? Quicktime, I believe, *is* documented. The only thorn is the Sorensen codec... which is just a codec, and not a container and not a platform.
The point was that at 6gb a pound, a paper solution would outlast a magnetic media solution because it was optically readable and be able to survive much harder conditions.
But each of your 20k per page can easily encode a unicode value, which means you can cram 2 bytes per spot, or only 50 tons per terabyte.
But how about a 600dpi laser printer, 8"x10"?
For good readability, we can use:
*** ** *
*
** ***
For (1,0) which gives us 3 dots per bit, or 200 bits per inch. A square inch would then give us 40,000 bits, or 5,000 bytes. A sheet of 8x10 then gives us 400,000 bytes. Or if you tweak the margins, 400k per page. So that's already 20 times your density. Increase the resolution to 1200dpi, and you can increase the data density to 1600k per page.
We can also use different encodings: Right now we use 9 bits to encode 1 bit of information (really, really, redundant). We can probably safely use the following encoding to double our data density:
***
***
* * *
*
*
*
So this further gives us 2 bits of information in the same 3x3 square, which increases our data density another 2fold: 800k or 3200k per page. At 1200dpi, that's 3mb per page, so that 1gb == 333 pages, and 1tb == 333k pages. 67 boxes, or 134 pounds per terabyte.
There are more variations of course. We can increase density to 4 bits per 3x3 square. With a bit of thought, we can also increase the density up to the theoretical limit of 2^9 values in a 3x3 square, but we want to include some leeway for data redundancy...
So by doubling to 4 bits per square, we require only 70 pounds per terabyte. By doubling again to 8 bits per square, That's down to 35 pounds.
That much (little) paper... is actually lighter than a terrabyte of digital storage!
Hereforth thou shalt be known as the Far-sci, pronounced 'Far-see' and therefore a clever pun on Sci-Fi, far sightedness, Farscape, and of course the Persian language of Farsi
It does mean that the ISP can afford to dispense more bandwidth (excess supply means lower prices, after all, doesn't it?) at the same price (and will do so to keep competitive with other ISPs, see Intel vs AMD)...
Well, perhaps an oversight on my part, but I *was* talking about sound traveling through air (and thus rarefaction and compression), which does mean my (simplified) description of the interference between two frequencies causing an audible third frequency which also happens to be related to the beat frequency...
Here's what I understand: Two high frequencies interfere, and the interference of those frequencies create a third frequency. This is the effect you're prof is talking about.
Another point is that not only is there temporal interference, there is spatial interference. This allows for spatial placement of sound, IE, 3d positioning.
Finally, sound, by it's definition, is the compression and decompression (rarefaction) of the air. That is how sound travels and propogates. So it's not unusual that *compressed* air heats up, or rarefied air cools down, which is partially how sound heat pumps might work.
Slashdot Mirror
Misunderstanding on your part when you use the word 'capture'.
"This is a windows only issues, but why is it that the DV manufacturers decided in their infinite wisdom to make it so you could only record in one format (DV)?"
DV is the format the recording is stored on the tape. There *is* no 'capture' method when you transfer to the PC. Now, what you want is a program that converts from the DV stream into your codec of choice *before* it is stored onto the drive.
See, but prefetch is a *choice*
:D
Quicktime gives you leeway by letting you tell the system your bandwidth and instant on settings.
In the same way Safari2 would know too... "Oh, he's not using his bandwidth" or "Hmm, he's got crappy bandwidth"
So this has rambled. Let me reiterate, then:
Perhaps a drawer or a pane for tabs/views/links/bookmarks. Personally I like a row of horizontal 'tabs' over a row of vertical 'links' but that's a quibble over interface layout' like the difference between a text only toolbar and a window attached menubar
Clicking in 'smart' bookmarks has nigh instantaneous response because the system has 'preloaded' the page. It will periodically check for a delta, and download it, according to your tastes and your bandwidth.
As per screen real estate, these tabs/views/links/bookmarks collapse into the 'Window' menu if they are active, 'Bookmarks' if they aren't. Clicking on a Bookmark opens the site; if the site is already open, it refreshes it.
Closing a view opens up the next 'smart' bookmark in the stack, sorta like turning pages or popping a stack.
Opening a view puts a new page on the stack.
Closing the last view closes the window.
Double clicking on a view pops open a new window. Closing the window doesn't get rid of a view until it is removed from the stack, however.
Sorry, my language is too imprecise.
iTunes only provides one playlist view at a time *unless* you double click on a playlist, and a new window opens up.
But clicking on each playlist brings up a different 'view' in the same window, so in that respect iTunes supports multiple views in one window.
In the *same* analogy sense, tabbed browsing, via tabs rather than playlists, supports multiple views in one window: Click on any tab, and a different view is presented.
So that's all I mean when I say that multiple views, one window, is workable for web browsing because it's already been implemented in iTunes, iPhoto, Mail, etc. One 'view' is active at a time, yes, but they do have a collection of alternative views switchable at any time. Does this sound like bookmarks? Perhaps, but implementation wise you can imagine that Safari2 precaches a select list of bookmarks so that when you click on the link it loads instantaneously. That is, theoretically, how tabbed view can be framed in a coherent and consistent interface, I believe.
How can I use the Dock? What I want is *one* HTML window with multiple HTML views.
The Dock gives me multiple HTML windows with one HTML view each, and one Moz icon with multiple Windows accessable via the menu.
An analogy would be how Mail.app keeps multiple emails but only provides one window, unless you double click on an email, and then giving you additional windows.
Mail's email list is ordered by date, since emails can logically be ordered by date received, though some people like to order them by priority, by sender, by subject, etc.
If we imagine a hypothetical web browser with a 'list' view, we could order sites by alphabet, date, user preference, or rank. Using this hypothetical web browser would not be any different than using Mail.app, theoretically.
What you would be doing *different* than the 1 window 1 view is that you are collapsing multiple sites into one 'browser'. The same way that iTunes is an mp3 browser, iPhoto is a photo browser, Finder is a file browser, Mail is an email browser, then Safari2 could be a 'website browser'.
Tabs are the implementation Mozilla uses, but it's not the only way. Having a drop down, having a list view, having a hierarchy, or a playlist view, etc, works. If you look at Safari, it already has this idea, in that bookmarks are available in a playlist like view. The difference is that, for performance reasons, Safari could 'preload' select special sites so that clicking on the bookmark would nigh instantaneously access the site, instead of loading off the web.
So I do believe the multiple website interface is workable, if only because iTunes, iPhoto, Finder, and Mail, as well as the Dock and Application Switcher, all seem to implement something structurally similar.
What you are describing can be thought of as a stack!
So you remember the OS 9 tearable Application Switcher?
What if, instead of apps, they had a Website Switcher. Which, functionally, is similar to tabs. The drawback to tabs, right now, is that you cannot arrange them and cycle through them, so there is inefficiency in actually mousing to them, and they *also* don't show up in the Window menu.
If, however, you make tabs 'collapsable', in that you can move a window onto a stack and have them 'share' real estate, I think that would work.
In the sens of a stack, hitting 'close' would close the topmost window; makes sense, since that is the one the viewer is looking at, and closing a window that is not visible is going to be very error prone.
Likewise, creating a new 'view' should appear on the 'top' of the stack, but with a simple opt-select, can be dragged anywhere in the stack (it's only superficially a stack).
So now you've got 'views' and 'windows'. You can actually close windows, and kill all the views, or you can kill the views on layer at a time.
Oh, another metaphor! The Photoshop 'layers'. Or, the way Photoshop stacks tabbed windows atop each other.
I see nothing wrong itself with tabs or MDI. You can imagine each tab akin to an icon in the Dock, and the Site Switcher is akin to the Dock or the Application Switcher. People are not unuse to the idea now. New window will always create a single view, and you can drag views in and out of windows, and a window can store multiple views, each view selectable from a tab or from the Window->view menu (multiple views separated by a separator line). Again, it's no more complicated or difficult than the implementation of the Application Switcher, the Dock, Photoshop Layers, Photoshop Palette Windows, or even the tabs you find at the Apple website.
Um, how is a backlit keyboard different, exactly, than your proposal for lighted symbols?
Unless I'm mistaken, the median in the Bay Area is 100k, so 6% of 100k leaves you with $94k...
I can't say this implementation is the *end all* of this type of file association filing system, but all your cases are handled by a more effective version.
/O/BAR, or that extra typing. Tab complete, for example, is similar in that the system intelligently autocompletes for you. If you typed 'Y in F'-tab, and it autocomplete the path, would you complain?
Case 1: The average home user *does* remember attributes for each and every file. Meaningful file names and locations. Use those. Other users, who *don't* use meaningful file names and locations can instead use what *they* find meaningful. Perhaps date and content attributes, or sizes, or last modification time?
Case 2: So do a search for file Y in F/O. The neat bit about searching (like Google) is the ability to use the *least* amount necessary to discriminate the data. If Y, F/O is sufficient, you just saved yourself the time of navigating
Case 3: Excellent idea. This is how it *should* work. The system classifies the files for you, either via prompting, on the fly, or continuously while the document is updated.
Case 4: So you rolled your own solution because there is no existing solution. Congratulations. The next scientist down the hall, who is less computer savvy than you are will appreciate a system like this, rather than DIY.
Other positive cases where this product *like this* is useful:
Searching for emails by content. The idea, when abstracted away, is the same. Most email programs already do this, some better than others.
Google (exact same idea, but applied to the web, instead of the filesystem) releases a product to organize and itemize your computer. Fine a file by any attribute you can remember, not *just* path. Right now you can only use the path. A file has other attributes than path.
Finding photos according to date, location, theme. iPhoto already does this. I'm sure other programs do to. Google does this, in a mechanical manner.
Finding music according to artist, name, album, year released, genre, style, appeal. iTunes does this, I'm sure other programs do to.
Address book functionality. Finding a person's phone number by looking for their name! Finding a person's address by looking for their name!
Finding word documents by summaries. Office already allows you to do this.
See a theme? What a system like this, when abstracted away into the OS or an API, is to allow *all* programs this kind of functionality, without forcing developers to reinvent the wheel over, and over, and over, again. One set of bugs, one set of problems, one set of developers, one set of fixes, rather than 80 different sets of bugs for 80 different apps and 80 different search methodologies and 80 different information indexing methods and 80 different application interfaces.
You could get Photoshop Elements. Yeah, it's more expensive than graphic converter, but you get 90% of Photoshop for 15% of the price, and it still beats the pants of GIMP for most stuff :)
Every thing that accesses the keychain at least does.
If Mail has been changed or tampered with, if AIM or ICQ or iChat, etc, etc, it asks me 'should I allow this program access to the keychain'?
Of course I dunno if this is robust or reliable, but it seems to exist.
Aww, it is now
:(
V 0.1 was written in Java Bridge
Google is an interface that seems to imply files and data are arranged via association; that's how Google collects and maintains ranks, isn't it?
Sure, it's a derivative of Limewire, on the other hand it's written in Cocoa/Java, so it at least looks prettier :)
http://www.kapsi.de/software/fern/
Alongside Duke Nukem Forever, or Halo!
Though Halo got release for XBox, it's still missing from the PC or Mac desktop.
Um, decent value for cheap price, and at convenient locations?
I always thought the Apple strategy was like the Honda racecar strategy: Vet and hone technology in a serious environment, like a racetrack or a video production house, and release similar but less hardcore technology to the consumer world.
Yeah, but Apple still happens to add value, to various respective industries...
Like Final Cut Pro->iMovie, DVD Studio->iDVD, and the iPod+iTunes combo, among other things.
Such as Apple's Quicktime?
It can support MPEG4, MJPEG, and h.XXX out of the box, and has Ogg and MPEG2 components (for both encoding and decoding) and can decode MPEG1 without any special effort.
What, exactly, is your problem? Quicktime, I believe, *is* documented. The only thorn is the Sorensen codec... which is just a codec, and not a container and not a platform.
The point was that at 6gb a pound, a paper solution would outlast a magnetic media solution because it was optically readable and be able to survive much harder conditions.
But how about a 600dpi laser printer, 8"x10"?
For good readability, we can use:For (1,0) which gives us 3 dots per bit, or 200 bits per inch. A square inch would then give us 40,000 bits, or 5,000 bytes. A sheet of 8x10 then gives us 400,000 bytes. Or if you tweak the margins, 400k per page. So that's already 20 times your density. Increase the resolution to 1200dpi, and you can increase the data density to 1600k per page.
We can also use different encodings: Right now we use 9 bits to encode 1 bit of information (really, really, redundant). We can probably safely use the following encoding to double our data density:So this further gives us 2 bits of information in the same 3x3 square, which increases our data density another 2fold: 800k or 3200k per page. At 1200dpi, that's 3mb per page, so that 1gb == 333 pages, and 1tb == 333k pages. 67 boxes, or 134 pounds per terabyte.
There are more variations of course. We can increase density to 4 bits per 3x3 square. With a bit of thought, we can also increase the density up to the theoretical limit of 2^9 values in a 3x3 square, but we want to include some leeway for data redundancy...
So by doubling to 4 bits per square, we require only 70 pounds per terabyte. By doubling again to 8 bits per square, That's down to 35 pounds.
That much (little) paper... is actually lighter than a terrabyte of digital storage!
How about the name 'Farsci'?
Hereforth thou shalt be known as the Far-sci, pronounced 'Far-see' and therefore a clever pun on Sci-Fi, far sightedness, Farscape, and of course the Persian language of Farsi
It does mean that the ISP can afford to dispense more bandwidth (excess supply means lower prices, after all, doesn't it?) at the same price (and will do so to keep competitive with other ISPs, see Intel vs AMD)...
So more bandwidth *is* good
Well, perhaps an oversight on my part, but I *was* talking about sound traveling through air (and thus rarefaction and compression), which does mean my (simplified) description of the interference between two frequencies causing an audible third frequency which also happens to be related to the beat frequency...
Quicktime was invented for Macs
No surprise then that Quicktime for PC is so crappy, in comparison.
Adobe Acrobat, however, is a whole different story. It wasn't invented on the Mac, though it currenty has a home on OS X (DisplayPDF).
LOL, if you say so.
Here's what I understand: Two high frequencies interfere, and the interference of those frequencies create a third frequency. This is the effect you're prof is talking about.
Another point is that not only is there temporal interference, there is spatial interference. This allows for spatial placement of sound, IE, 3d positioning.
Finally, sound, by it's definition, is the compression and decompression (rarefaction) of the air. That is how sound travels and propogates. So it's not unusual that *compressed* air heats up, or rarefied air cools down, which is partially how sound heat pumps might work.
Old hat
You're talking about beat frequencies I think.