diff options
| -rw-r--r-- | AUTHORS (renamed from muse2/AUTHORS) | 0 | ||||
| -rw-r--r-- | COPYING (renamed from muse2/COPYING) | 0 | ||||
| -rw-r--r-- | ChangeLog (renamed from muse2/ChangeLog) | 0 | ||||
| -rw-r--r-- | NEWS (renamed from muse2/NEWS) | 0 | ||||
| -rw-r--r-- | README (renamed from muse2/README) | 29 | ||||
| -rw-r--r-- | README.de (renamed from muse2/README.de) | 0 | ||||
| -rw-r--r-- | README.effects-rack (renamed from muse2/README.effects-rack) | 0 | ||||
| -rw-r--r-- | README.instruments (renamed from muse2/README.instruments) | 0 | ||||
| -rw-r--r-- | README.ladspaguis (renamed from muse2/README.ladspaguis) | 0 | ||||
| -rw-r--r-- | README.shortcuts (renamed from muse2/README.shortcuts) | 0 | ||||
| -rw-r--r-- | README.softsynth (renamed from muse2/README.softsynth) | 0 | ||||
| -rw-r--r-- | README.translate (renamed from muse2/README.translate) | 0 | ||||
| -rw-r--r-- | README.usage (renamed from muse2/README.usage) | 0 | ||||
| -rw-r--r-- | SECURITY (renamed from muse2/SECURITY) | 0 | ||||
| -rw-r--r-- | muse2/README.svn-branch | 125 |
15 files changed, 29 insertions, 125 deletions
diff --git a/muse2/ChangeLog b/ChangeLog index 7a81f9a1..7a81f9a1 100644 --- a/muse2/ChangeLog +++ b/ChangeLog @@ -8,6 +8,35 @@ MusE is distributed under the GNU General Public License (GPL). Please check out the file COPYING in this directory for more details. + + ============================= + Features: + ============================= + + MIDI sequencing: + - Realtime record/playback + - Midi file import/export + - Input filter + - Support for internal softsynth plugins using + DSSI, VST and MESS + - much more + + Audio sequencing: + - Realtime Record/Playback several mono/stereo inputs/outputs + - Graphical editing of automation + - Support for LADSPA, DSSI, VST plugins + + Technologies supported: + - LASH - for session control with external LASH enabled applications + - JACK - The Jack Audio Connection Kit can be used for audio and midi + - ALSA midi output + - Plugin formats: DSSI, VST(i), MESS + - FLAM plugin guis. + - Built on QT4 + + + + ,-----------------------------------------------------------------. | NOTICE | |-----------------------------------------------------------------| diff --git a/muse2/README.de b/README.de index 75aaf57f..75aaf57f 100644 --- a/muse2/README.de +++ b/README.de diff --git a/muse2/README.effects-rack b/README.effects-rack index 071ba08e..071ba08e 100644 --- a/muse2/README.effects-rack +++ b/README.effects-rack diff --git a/muse2/README.instruments b/README.instruments index 1bc66e7f..1bc66e7f 100644 --- a/muse2/README.instruments +++ b/README.instruments diff --git a/muse2/README.ladspaguis b/README.ladspaguis index c1b168ff..c1b168ff 100644 --- a/muse2/README.ladspaguis +++ b/README.ladspaguis diff --git a/muse2/README.shortcuts b/README.shortcuts index e5227853..e5227853 100644 --- a/muse2/README.shortcuts +++ b/README.shortcuts diff --git a/muse2/README.softsynth b/README.softsynth index 662ef423..662ef423 100644 --- a/muse2/README.softsynth +++ b/README.softsynth diff --git a/muse2/README.translate b/README.translate index f4741a4d..f4741a4d 100644 --- a/muse2/README.translate +++ b/README.translate diff --git a/muse2/README.usage b/README.usage index 2c799bd3..2c799bd3 100644 --- a/muse2/README.usage +++ b/README.usage diff --git a/muse2/SECURITY b/SECURITY index e0fa68a5..e0fa68a5 100644 --- a/muse2/SECURITY +++ b/SECURITY diff --git a/muse2/README.svn-branch b/muse2/README.svn-branch deleted file mode 100644 index 94e44ed8..00000000 --- a/muse2/README.svn-branch +++ /dev/null @@ -1,125 +0,0 @@ -Branches are handy for developing larger features (especially if you -temporarily break muse and then fix it again). You might want to ask -why you shouldn't simply develop in your local working copy, and then -commit a huge chunk. Well, this has multiple reasons: - o with branches, you'll have a history, because there are many small - commits. this makes bisecting for finding a bug possible. - o when you develop your feature publicly, others can check out half-done - versions, and already test the one half. they also could fix bugs. - o another advantage of keeping it public is: others can see whether you - may exclude some use case and inform you about that in time. otherwise - you'd spend lots of work in a design which was obsolete from the - beginning. - o and it shows that there's something going on :) - -also, branching makes "feature freezes" easier, for release planning. - -General note: ^/trunk means [url of the repo]/trunk. when you're inside -a working copy, svn understands the ^/trunk notation. -i assume you're inside some working copy - -whenever merging, make sure you're in the correct directory! - -CREATING A BRANCH - the following command creates a branch called yourbranch in the branches - directory, which is built upon the current (NOT the checked out!) trunk - revision: - - svn copy ^/trunk ^/branches/yourbranch - - svn copy does a "light copy", that is, as long as you don't change files, - they don't occupy any disk space. - -USING THE BRANCH - you might want to checkout every branch relevant to you into another local - copy. believe me, it makes life easier. alternatively, svn switch is your - friend. - just develop inside the working copy, then commit. - -MERGING WITH THE PARENT BRANCH (in my example: the trunk) - from time to time, you want to update your branch to represent the - current trunk plus your changes (and not an ancient trunk plus your - changes). to be safe, only merge with the parent branch, and only - merge in one direction (usually from trunk into your branch), unless - you know what you're doing. if you're reading and not skimming this, - you're probably NOT knowing. svn help and google are your friends. - - be in your branch'es working directory root (the dir which is containing - all the files/dirs also trunk (the parent) is containing as well. - - svn merge ^/trunk --accept postpone - - does the job for you. there might be conflicts, when both in your branch - and in trunk some file has been changes at a similar location. svn by - default asks you what to do then, which is annoying. --accept postpone - turns this off, and gives you a summary at the end of the merge. - - If There Were Conflicts: - if any file in "svn status"'s output has a C in front of it, there are - conflicts. open the file in your editor, and look for markers like - "<<<<<", "=====" and ">>>>>". these show what code is in the trunk - (between <<<< and ====), and what code is in your branch (between - ==== and >>>>) (or vice versa. svn tells you). - you have to make it work again and save the file. - - with "svn resolved FILENAME" or "svn resolved -R some/directory" you - mark the conflicts for FILENAME or all files below some/directory as - solved. - - Another word about conflicts: there may be conflicts, even if svn doesn't - note them. ALWAYS recompile the merged code and test it. - - if done, you can commit the merge normally using "svn commit" - -PUTTING YOUR WORK BACK INTO THE PARENT BRANCH (in my example: trunk) - do a final merge from your parent branch into your branch. compile and - test. - then there are several ways to proceed: - o use svn merge --reintegrate, which doesn't work with the old repo - version muse is using :( - o go into the trunk (or the parent branch'es directory), and issue - svn merge ^/branches/yourbranch --accept theirs-full - the problem with the merge is, that every previous merge from trunk - into your branch will be applied a second time, which doesn't work. - --accept theirs-full will basically use the files in your branch. - you might want to verify with diff: - diff -R /path/to/local/trunk /path/to/local/yourbranch - there should be no differences. - - commit that to trunk: svn commit - - then, "fake-merge" trunk into your branch again. otherwise, with the - next merge from trunk into your branch, we would have the duplicate - changes problem again. if you're _SURE_ that you aren't using the - branch any more, you can leave this step out. - - svn merge ^/trunk ^/branches/yourbranch --record-only - svn commit - - - this solution is a bit hackish :( but it works - - -NOTES FOR RELEASE BRANCHES - after creating the release branch, ALL commits which are fixing bugs - must go into the release branch. ALL commits which are adding features - must go into trunk or other branches. - the team should focus on fixing bugs in the release branch. - to get the fixes into the trunk, from time to time run: - - svn merge ^/branches/releasebranch ^/trunk - svn commit (in trunk's local copy) - - when releasing the release branch, merge it into the trunk a last time, - and then never touch the release branch again. - for the next release, create a new one. - -TAGGING - when there's any reason for tagging a revision, simply do - svn copy ^/whatever ^/tags/yourtagname - read the svn manual for details - -GETTING HELP: - svn help <command> (usage notes, short explanations) - google (everything) - the svn book (->google) (long explanations) |