Written by Thelasko the 5 Aug 08 at 13:29.

Ubuntu Brainstorm was updated in January 2009. Since the idea #11864 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #11864 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by stochastic the 28 Mar 09 at 08:24.

Have an automated system that can run through the variety of combinations of common settings tweaks to check which will give the best stability (least xruns), lowest latency, etc... on the users' system, and present the results to the user to select.

Have an automated system that can run through the variety of combinations of common settings tweaks to check which will give the best stability (least xruns), lowest latency, etc... on the users' system, and present the results to the user to select.

Written by stochastic the 28 Mar 09 at 08:28.

Similar to #1, but rely on users, who have working setups, to report their setup into an (anonymous?) database so that programs can compare the user's hardware against the database to determine the best sound setup.

Similar to #1, but rely on users, who have working setups, to report their setup into an (anonymous?) database so that programs can compare the user's hardware against the database to determine the best sound setup.

Written by yaaarrrgg the 11 Feb 09 at 20:18.

Overall this software would be a cross between a multi-track recorder (like ardour or traverso), p2p file sharing, and maybe a simple instant messenger. I suppose some form of file merging or locking might be useful (like svn/cvs) but a simpler approach would just be to allow individual contributers to fork a copy of the project.

Newly recorded audio tracks would stream (p2p) to all other running instances of the application. So that after each track is recorded, each person has a complete copy of the media files. One person can assume control of the mix, then saving the project would propagate changes. If this used compressed audio as the native format, you could stream this in real time without much latency.

Also this app should run natively on the target platforms, without any additional services required. It would not have a business model wrapped around it, since the goal would be to make it easier for musicians to make music.

Or if there are any servers, it would be very light-weight, only handling routing the machines together, then passing all processing to the target machines for p2p file sharing. This way, any one person in a cluster could run the service. The bottom line, is there's no business model wrapped around it ... limiting services, bandwidth, storage, etc.

Overall this software would be a cross between a multi-track recorder (like ardour or traverso), p2p file sharing, and maybe a simple instant messenger. I suppose some form of file merging or locking might be useful (like svn/cvs) but a simpler approach would just be to allow individual contributers to fork a copy of the project. Newly recorded audio tracks would stream (p2p) to all other running instances of the application. So that after each track is recorded, each person has a complete copy of the media files. One person can assume control of the mix, then saving the project would propagate changes. If this used compressed audio as the native format, you could stream this in real time without much latency. Also this app should run natively on the target platforms, without any additional services required. It would not have a business model wrapped around it, since the goal would be to make it easier for musicians to make music. Or if there are any servers, it would be very light-weight, only handling routing the machines together, then passing all processing to the target machines for p2p file sharing. This way, any one person in a cluster could run the service. The bottom line, is there's no business model wrapped around it ... limiting services, bandwidth, storage, etc.