Slashdot Mirror

Correct. I was using something called "Code Co-op" released back in something like 96-97 era. It used email as its back end for communication.

http://relisoft.com/

He does mention it's an audio program, not a paint program :-) If it 'just' edited spectrograph images it would be pretty useless (you can do that in Photoshop easily enough, or just create your own by feeding data to any MATLAB-esque graphing software). If the OP is trying to make money on it, I'd guess the software has to make itself useful by tying its output back to audio somehow.

The spectrograph is really just a visual representation of the Fourier transform of an audio sample - this process is ideally lossless, so if correctly applied, the data can be transformed between the time and frequency domains arbitrarily without degrading it. So I'm hoping this is the idea behind the software, and not a simple Paint program :p

Perhaps it needs a P2P-based hosting system to serve up its content.
Here is a product that apparently provides some kind of P2P-Wiki
Here is an academic proposal for hosting wikipedia over a P2P network.
And here is someone else working on the same problem.

""There are frequent disconnections; and hence loss of work while code check-ins.""

Is this the key reason why you need a VPN?
  [BTW, I hope that you are not using MS SourceSafe...]
Have you considered alternate revision control systems?

On the (not too expensive) commercial side, I am a fan of Code Co-op, from http://www.relisoft.com/. I've used it with a development team in China a few years ago, and they were definitely worse-off than you. Free trial available for download.

1. See if your school has LabView or Matlab. Both offer FFT out of the box. One of those would have actually been my first choice for the project you're describing.

2. If that fails, note that there are plenty of textbooks (or websites) that explain the FFT butterfly. A quick search turned up http://www.relisoft.com/Science/Physics/fft.html, which even has C++ source code available for download.

The Peer-to-peer Version Control System for Distributed Teams
Code Co-op is the version control system for distributed development that adds mobility, simplicity, and robust functionality to your Windows development projects.

• Mobility for collaboration from any location using your existing infrastructure
  - no server required;
• Simplicity to give you quick access to project files and history regardless of a network connection;
• Robust functionality to give you all the control and security you require for managing your software assets.

With Code Co-op you can:
- Collaborate from anywhere using Email, LAN, and VPN
- Access your project files and history without a network connection
- Review file changes with the built-in Visual Differ or Beyond Compare Differ
- View, compare, or restore any iteration of your project or file regardless of a label
- Integrate with your favorite development tools
- Forgo costly server maintenance
- Rely on a secure, fully transactional database with automatic back-ups
- Implement source control in minutes for only $159 per user

Reliable Software makes a product called "Code Co-op: Server-less Version Control", (free trial, then cheap licence per seat) designed exactly for distributed closed-source development, especially where there is no central server. (I have never used it, but I came across their site more than 5 years ago when looking for good windows programming info, which they still have - also cool scientific programming info.)

That said, there's nothing you mentioned that you cannot do if you rent a *nix box and install alexandria, which powers sourceforge or Savane, which powers Gna.org, LCG Savannah and GNU/Non-GNU Savannah

Reliable Software makes a product called "Code Co-op: Server-less Version Control", (free trial, then cheap licence per seat) designed exactly for distributed closed-source development, especially where there is no central server. (I have never used it, but I came across their site more than 5 years ago when looking for good windows programming info, which they still have - also cool scientific programming info.)

That said, there's nothing you mentioned that you cannot do if you rent a *nix box and install alexandria, which powers sourceforge or Savane, which powers Gna.org, LCG Savannah and GNU/Non-GNU Savannah

Reliable Software makes a product called "Code Co-op: Server-less Version Control", (free trial, then cheap licence per seat) designed exactly for distributed closed-source development, especially where there is no central server. (I have never used it, but I came across their site more than 5 years ago when looking for good windows programming info, which they still have - also cool scientific programming info.)

That said, there's nothing you mentioned that you cannot do if you rent a *nix box and install alexandria, which powers sourceforge or Savane, which powers Gna.org, LCG Savannah and GNU/Non-GNU Savannah

Good design usually means slightly more initial coding work, and insanely less maintenance. I learned this from this book, particularly this chapter. Admittedly, they are porting to Windows. They are also using C++, which I thoroughly despise. They have also designed their code so well that it only takes one section -- while we're learning new gui concepts -- to port a commandline program to a Windows GUI.

I admit that developing for something portable to begin with (java, parrot, wxwindows, gtk+, or whatever the solution is for databases) can save you the trouble of porting it yourself -- someone ported the library for you -- but still, code can be made modular enough that you can have a port done by the time the meeting on deciding whether to port is over. (Assuming they let you hack on a laptop during said meeting.)

Bottom line -- worry about modularity and general flexibility before you worry about portability, and in the unlikely even that you have to port, it's not a big deal.

Good design usually means slightly more initial coding work, and insanely less maintenance. I learned this from this book, particularly this chapter. Admittedly, they are porting to Windows. They are also using C++, which I thoroughly despise. They have also designed their code so well that it only takes one section -- while we're learning new gui concepts -- to port a commandline program to a Windows GUI.

I admit that developing for something portable to begin with (java, parrot, wxwindows, gtk+, or whatever the solution is for databases) can save you the trouble of porting it yourself -- someone ported the library for you -- but still, code can be made modular enough that you can have a port done by the time the meeting on deciding whether to port is over. (Assuming they let you hack on a laptop during said meeting.)

Bottom line -- worry about modularity and general flexibility before you worry about portability, and in the unlikely even that you have to port, it's not a big deal.

I read some good articles about this at Relisoft.com and it was very helpful.

Mozilla tabs are just a fucking MDI interface

There's a subtil difference, but since Mozilla stole the idea from Opera, it irrelevant anyway.

MDI sucked in 1995, and it still sucks now.

What really sucks is being stuck with SDI when you've got 20 windows open with the same application.

We need is a nice combination, so you can group or ungroup windows whenever you want.

It just perpetuates the stupid every-app-has-its-own-look-and-feel mentality.

I hate that... If it weren't for skins that matched the system's default look it would be unbearable.

Microsoft's COM ... actually a good thing....

Except for that fatal flaw...

For me C++ in action was a really good book for learning C++. It puts an emphasis on good design and writing robust, maintainable code.

just go to relisoft got a lot of useful techniques and free reference books they wrote.

For anyone interested, an excellent book that covers resource management in C++ is C++ In Action: Industrial-strength Programming Techniques by Bartosz Milewski. I'm relatively new to C++, and this is the book that really sold me on the language...he presents a methodology that practically guarantees you won't have leaks. He's also practical enough to tell you how to retrofit the technique to existing projects. Milewski is a former physicist, and a very clear writer and thinker. And to top it off, the full text is available on the web.

The book is here, if you're curious: http://www.relisoft.com/book/

Sounds like a clock hog

The key word here is background. A defragmentation process running with a low priority that flushes its changes to disk regularly will not affect applications running at normal priority. Of course, if you're burning a CD or something, you will have the option of turning it off temporarily.

As an aside, the Indexing Service on Windows 2000 isn't bad. The original version was written by one of these people.

--
"Where, where is the town? Now, it's nothing but flowers!"