Open GoogleCodeExporter opened 8 years ago
I like this idea. A problem I foresee is someone locks a track but doesn't lock
the
anchors and then moves the anchors causing the notes to be repositioned. Maybe
the
anchors should have to be locked before the tracks can be locked. If you unlock
the
anchors, the tracks would automatically be unlocked as well.
Original comment by xander4j...@yahoo.com
on 24 May 2010 at 4:05
It would be necessary for the user to know what he/she is doing to make the
most of
this, but I agree that people would have less reason to lock the instrument
notes and
not the anchors.
As far as moving anchors when instrument notes are locked, it would probably
have to
override the auto-adjust function so that the locked notes stay put.
Original comment by raynebc
on 24 May 2010 at 4:39
Ultimately, I think it would be more useful to implement this as an option to
disable click and drag. I could foresee where people would want to be able to
make edits that include toggling lanes, deleting/adding notes, but don't want
to accidentally move things. This would be best as a song property instead of
a global preference, so the author can lock a project when he/she is done with
most of it.
Original comment by raynebc
on 17 Oct 2011 at 11:30
r910 adds the ability to lock the tempo map and disable editing changes to the
beat markers (except for changing the MIDI delay). It should be easy enough to
create a track flag to disable changes to the active track, as there are 31
bits left in the track flags variable.
NewCreature's suggestion of requiring the tempo map to be locked as a
prerequisite for locking individual tracks will probably be the best way to
continue.
I haven't decided whether or not it would be useful enough to create a separate
option to disable click and drag operations on notes, but it would be a pretty
easy code change.
Original comment by raynebc
on 18 Jun 2012 at 1:28
The ability to disable the click and drag mechanism was added in r1097. While
the project format would easily accommodate a track flag to indicate the track
is locked for editing, I'm not sure if it is worth the amount of work it would
take. Every single operation that altered notes, text events, phrases, etc.
would have to check the lock status flags of affected tracks. At best it would
involve calling a function that would return a boolean status for whether the
operation would be allowed to run, so that's an if() return block in every
single applicable editing function.
Original comment by raynebc
on 25 Apr 2014 at 11:11
The function to create an undo state could check if the chart is locked and
return an abort code if the calling function should cancel whatever edit it was
planning to make. This would mean each call to eof_prepare_undo() would need
to check the return value, but this should reliably identify all points in the
program where the chart would be edited. eof_prepare_undo() could also be
given a parameter so the calling function could identify the scope of the
alteration (track wide, track-difficulty wide or project-wide, etc).
Original comment by raynebc
on 14 Jun 2015 at 2:18
Original issue reported on code.google.com by
raynebc
on 20 May 2010 at 6:12