Enum and namespace syntax fixes to satisfy -pedantic
Resolved a couple "code never reached" areas to satisfy -Wextra
git-svn-id: svn://localhost/ardour2/trunk@688 d708f5d6-7413-0410-9779-e7cbd77b26cf
Havn't managed to completely remove it because of Session loading from XML - the
Diskstreams are separate from the Tracks (I assume as a throwback to when they
were distinct) so the Diskstreams need to be stored somewhere until the Tracks
are loaded. Ideally tracks should completely own their Diskstreams - not sure
how to accomplish this without breaking Session loading though...
git-svn-id: svn://localhost/ardour2/branches/midi@687 d708f5d6-7413-0410-9779-e7cbd77b26cf
Added mac specific ardour2_mac_ui.rc file
Fixed some memory leaks in add_instant_xml() usage.
Added EXTRA_WARN scons option for pedants.
Reformatted xml++.cc into something that wouldn't drive me insane.
git-svn-id: svn://localhost/ardour2/trunk@686 d708f5d6-7413-0410-9779-e7cbd77b26cf
This is the first swath of changes, replacing add_undo with MementoCommand
pattern, through most of the editor_mouse.cc file. However there were a few
places that weren't symmetrical that I need to think about. The question is
whether to tweak things so that they are symmetrical (add_undo paired with
add_redo*), or to allow Commands to not be undoable or not be redoable. Your
thoughts are welcome.
git-svn-id: svn://localhost/ardour2/branches/undo@685 d708f5d6-7413-0410-9779-e7cbd77b26cf
I just had an epiphany. I tried so many ways to make saving function name and
args work, it never occured to me that you could just as easily save undo
information as a pair of mementos, even in the Command-based structure we
agreed on.
Since many (read: almost all) existing undo commands take this form:
begin_reversible_command (_("change fade in length"));
session->add_undo (arv->region.get_memento());
arv->region.set_fade_in_length (fade_length);
session->add_redo_no_execute (arv->region.get_memento());
commit_reversible_command ();
We are already doing the save a memento before and after work. All we need to
do is instantiate an appropriate instance of MementoCommand. So the above
becomes:
begin_reversible_command (_("change fade in length"));
MementoCommand<arv_region_t, arv_region_memento_t> before, after;
before = arv->region.get_memento();
arv->region.set_fade_in_length (fade_length);
after = arv->region.get_memento();
session->add_command(arv->region, before, after);
commit_reversible_command ();
(With apologies for being too lazy to go look up what arv_region_t and
arv_region_memento_t are)
Note that the true command approach is still possible, and encouraged (both by
dictate and design).
git-svn-id: svn://localhost/ardour2/branches/undo@680 d708f5d6-7413-0410-9779-e7cbd77b26cf
Renamed pbd3 back to pbd, since it's version 4.1 now.
Very minor fixes
git-svn-id: svn://localhost/ardour2/trunk@656 d708f5d6-7413-0410-9779-e7cbd77b26cf
Coding for undo/redo starts in earnest. Paul and I decided to go with a
standard gang of four Command pattern, with serialization. This overcomes the
terrible difficulties we were having with static type checking and the sigc++
approach. I'm adding the requirement that each command support undo,
simplifying undo/redo. NOTE that an important fallout here is that
Command::operator()() is the opposite of the old UndoAction::operator()(), i.e.
Command::operator()() is execute/redo, and Command::undo() is undo.
This commit is a reworking of the infrastructure, and won't compile until
creating Command subclasses for the various commands being performed. That is
primarily where you find get_memento and/or calls to add_(undo|redo.*).
git-svn-id: svn://localhost/ardour2/branches/undo@655 d708f5d6-7413-0410-9779-e7cbd77b26cf
unecessary changes. (Sorry, doing a "sprint" based thing, this is the end of the first one)
Achieved MIDI track and bus creation, associated Jack port and diskstream creation, and minimal GUI stuff for creating them. Should be set to start work on actually recording and playing midi to/from disk now.
Relevant (significant) changes:
- Creation of a Buffer class. Base class is type agnostic so things can point to a buffer but not care what kind it is (otherwise it'd be a template). Derived into AudioBuffer and MidiBuffer, with a type tag because checking type is necessary in parts of the code where dynamic_cast wouldn't be wise. Originally I considered this a hack, but passing around a type proved to be a very good solution to all the other problems (below). There is a 1:1 mapping between jack port data types and ardour Buffer types (with a conversion function), but that's easily removed if it ever becomes necessary. Having the type scoped in the Buffer class is maybe not the best spot for it, but whatever (this is proof of concept kinda stuff right now...)
- IO now has a "default" port type (passed to the constructor and stored as a member), used by ensure_io (and similar) to create n ports. IO::register_***_port has a type argument that defaults to the default type if not passed. Rationale: previous IO API is identical, no changes needed to existing code, but path is paved for multiple port types in one IO, which we will need for eg synth plugin inserts, among other things. This is not quite ideal (best would be to only have the two port register functions and have them take a type), but the alternative is a lot of work (namely destroying the 'ensure' functions and everything that uses them) for very little gain. (I am convinced after quite a few tries at the whiteboard that subclassing IO in any way is not a feasible option, look at it's inheritance diagram in Doxygen and you can see why)
- AudioEngine::register_audio_input_port is now register_input_port and takes a type argument. Ditto for output.
- (Most significant change) AudioDiskstream abstracted into Distream, and sibling MidiDiskstream created. Very much still a work in progress, but Diskstream is there to switch references over to (most already are), which is the important part. It is still unclear what the MIDI diskstream's relation to channels is, but I'm pretty sure they will be single channel only (so SMF Type 0) since noone can come up with a reason otherwise.
- MidiTrack creation. Same thing as AudioTrack but with a different default type basically. No big deal here.
- Random cleanups and variable renamings etc. because I have OCD and can't help myself. :)
Known broken: Loading of sessions containing MIDI tracks.
git-svn-id: svn://localhost/ardour2/branches/midi@641 d708f5d6-7413-0410-9779-e7cbd77b26cf
