only played back if the automation mode is set to "Play". Munge AutoState
for AutomationRegionViews so that they reflect their AutomationTimeAxisView's
setting. Fixes#3135.
git-svn-id: svn://localhost/ardour2/branches/3.0@7304 d708f5d6-7413-0410-9779-e7cbd77b26cf
MementoCommand<Region>. More use of State<> for Region members.
git-svn-id: svn://localhost/ardour2/branches/3.0@6675 d708f5d6-7413-0410-9779-e7cbd77b26cf
Testing seems to show the old way and this both working equally well, which is a bit weird since the old way really doesn't seem to make any sense whatsoever.
This way works as well as far as I can tell and actually makes sense, so hey, let's go with this one.
git-svn-id: svn://localhost/ardour2/branches/3.0@5879 d708f5d6-7413-0410-9779-e7cbd77b26cf
Make Sequence::read_lock const correct in the process (a read lock can be taken out on a const Sequence, but not a write lock).
git-svn-id: svn://localhost/ardour2/branches/3.0@5857 d708f5d6-7413-0410-9779-e7cbd77b26cf
LOADING 2.X SESSIONS WITH THIS COMMIT IN PLACE WILL (PROBABLY) CORRUPT THE .ardour FILE,
MAKING THE SESSION UNLOADABLE ON 2.X AND LOSING INFORMATION.
So don't do that unless you make a backup of the session file first.
git-svn-id: svn://localhost/ardour2/branches/3.0@5786 d708f5d6-7413-0410-9779-e7cbd77b26cf
Vimmers, try let c_space_errors = 1 in your .vimrc to highlight this kind of stuff in red. I don't know the emacs equivalent...
git-svn-id: svn://localhost/ardour2/branches/3.0@5773 d708f5d6-7413-0410-9779-e7cbd77b26cf
The vast majority of Route signal processing is now simply in the list of
processors. There are definitely regressions here, but there's also
a lot of things fixed. It's far too much work to let diverge anymore
regardless, so here it is.
The basic model is: A route has a fixed set of input channels (matching
its JACK input ports and diskstream). The first processor takes this
as input. The next processor is configured using the first processor's
output as input, and is allowed to choose whatever output it wants
given that input... and so on, and so on. Finally, the last processor's
requested output is used to set up the panner and create whatever Jack
ports are needed to output the data.
All 'special' internal processors (meter, fader, amp, insert, send) are
currently transparent: they read any input, and return the same set
of channels back (unmodified, except for amp).
User visible changes:
* LV2 Instrument support (tracks with both MIDI and audio channels)
* MIDI in/out plugin support
* Generic plugin replication (for MIDI plugins, MIDI/audio plugins)
* Movable meter point
Known Bugs:
* Things seem to get weird on loaded sessions
* Output delivery is sketchy
* 2.0 session loading was probably already broken...
but it's definitely broken now :)
Please test this and file bugs if you have any time...
git-svn-id: svn://localhost/ardour2/branches/3.0@5055 d708f5d6-7413-0410-9779-e7cbd77b26cf
All #include statements that include a header that is a part of a library
bundled with ardour MUST use quotes, not angle brackets.
Do this:
#include "ardour/types.h"
NOT this:
#include <ardour/types.h>
Rationale:
This is best practice in general, to ensure we include the local version
and not the system version. That quotes mean "local" (in some sense)
and angle brackets mean "system" (in some sense) is a ubiquitous
convention and IIRC right in the C spec somewhere.
More pragmatically, this is required by (my) waf (stuff) for dependencies
to work correctly. That is:
!!! FAILURE TO DO THIS CAN RESULT IN BROKEN BUILDS !!!
Failure to comply is punishable by death by torture. :)
P.S. It's not that dramatic in all cases, but this (in combination with some
GCC flags specific to the include type) is the best way I have found to be
absolutely 100% positive the local ones are being used (and we definitely
want to be absolutely 100% positive on that one).
git-svn-id: svn://localhost/ardour2/branches/3.0@4655 d708f5d6-7413-0410-9779-e7cbd77b26cf
Update MIDI region length (actually and visually) when position changes.
git-svn-id: svn://localhost/ardour2/branches/3.0@4644 d708f5d6-7413-0410-9779-e7cbd77b26cf
sframes_t is "session frames". The rules for time stamps are:
- Anything relative to transport time, session position, etc, should be sframes_t
- Anything relative to jack cycles, including the length thereof, should be nframes_t
To support sessions which exceed UINT32_MAX frames, we need to replace all the uses of
nframes_t for session time with sframes_t, and make sure the conversions are sound.
This does not depend on jack's nframes_t; that we are using the same type at all right now was an oops.
This is also be kinda nice for readability since the two different time bases have different types...
git-svn-id: svn://localhost/ardour2/branches/3.0@4636 d708f5d6-7413-0410-9779-e7cbd77b26cf
Move time conversion into the region view rather than the source.
Adapt MIDI (including controllers) regions to the destination tempo when moved (e.g. dragging a region to a location with half the tempo will make the notes twice as long).
git-svn-id: svn://localhost/ardour2/branches/3.0@4635 d708f5d6-7413-0410-9779-e7cbd77b26cf
Most significant changes:
- Factor out FileSource from AudioFileSource, use for SMFSource too
- Explicitly pass embedded rather than mysterious name mangling or whatever
- Destroy a ton of duplicated or very-nearly-duplicated code
- Clean up and document all that weird source stuff in session.cc
git-svn-id: svn://localhost/ardour2/branches/3.0@4609 d708f5d6-7413-0410-9779-e7cbd77b26cf
This has 3 main benefits:
- All conversion code is in one place (less duplication, potential bugs)
- The conversion method can be passed to things that are ignorant
of the actual time units involved, information required, etc.
(In the future it would be nice to have user selectable tempo/frame time)
- It should be relatively simple now to support tempo changes part-way
through a MIDI region (at least architecturally speaking)
git-svn-id: svn://localhost/ardour2/branches/3.0@4594 d708f5d6-7413-0410-9779-e7cbd77b26cf
The time stamp of an event is now always tempo, from file to model and
back again. Frame time is only relevant at playback or recording time,
in the audio thread (MidiModel and MidiBuffer).
I think perhaps we don't need to change the actual time from double (which is
convenient for math), it is the time base conversion that caused problems.
Using a correct equality comparison (i.e. not == which is not correct for
floating point) should probably make the undo issues go away, in 99.99% of
cases anyway.
There's almost certainly some regressions in here somewhere, but they do not
seem to be time related. The bugs I'm hitting in testing are old ones that
seem unrelated now, so it's checkpoint time.
This sets us up for fancy things like tempo map import and tempo/meter changes
halfway through MIDI regions, but for now it's still assumed that the tempo
at the start of the region is valid for the duration of the entire region.
git-svn-id: svn://localhost/ardour2/branches/3.0@4582 d708f5d6-7413-0410-9779-e7cbd77b26cf
Use iterator interface of Sequence to read events in a MIDISource rather than Sequence::read, avoiding timestamp confusion.
Disable no longer useful Sequence::read.
git-svn-id: svn://localhost/ardour2/branches/3.0@4570 d708f5d6-7413-0410-9779-e7cbd77b26cf
Anything related to the storage of events/values over a range of time lives in evoral.
This includes MidiModel (Evoral::Sequence) and automation data (AutomationList (Evoral::ControlList),
Automatable (Evoral::ControlSet), etc).
libs/evoral synced with http://svn.drobilla.net/lad/trunk/evoral r1511.
git-svn-id: svn://localhost/ardour2/branches/3.0@3754 d708f5d6-7413-0410-9779-e7cbd77b26cf
