[nama] Re: remove_track safety, strange behaviours
- From: Joel Roth <joelz@xxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Wed, 27 Oct 2010 10:29:30 -1000
I wrote this at terrible length, then forgot to send it.
Please ignore!
On Tue, Oct 26, 2010 at 10:16:56PM -0400, S. Massy wrote:
> Hi,
>
> Yesterday, I absent-mindedly removed the wrong track, which led me to
> wish for a safer remove_track. One simple idea I had is to require one
> to specify the track as an argument to the command, as opposed to simply
> operating on the currently selected track.
>
> Secondly, I tried correcting my blunder by adding the track again ind
> reimporting the audio, since the wavs aren't deleted when removing a
> track, but it somehow adds a completely different wav, and, also, I
> somehow end up with several versions of that unwanted wav. I removed
> that track again and tried a different name for the track in case nama
> was getting confused, but the same problem arose. I can only assume that
> something I did at some point fouled up my state.yml file. Sorry to be
> so vague, but you know how it is when you're trying to achieve
> something, you don't necessarily remember every step you follow. Anyway,
> it's meant as a hint: if I have time, I will make a copy of the project
> and experiment. Hopefully, I can recover this project without having to
> reimport all the audio from scratch.
S.M.,
Sorry to hear about your misadventures with remove_track.
There weren't any special safeguards to remove_track
up to now.
Consider the following:
nama [sax] > remove_track
nama > add_track sax # add
nama [sax] > show_track # sh
If you have some WAV files sax_1.wav, sax_2.wav, sax_3.wav, then
after re-creating 'sax', the 'show_track' command will have
a line like this:
All versions: 1 2 3
This part of Nama is dynamic: Nama reads the
~/nama/project_name/.wav directory to see which
files are there.
That is where import_wav copies files.
Nama is designed to be non-destructive. That means
that you will never lose anything. Okay maybe your
girl- or boyfriend, but at least not
any WAV files.
Once a file arrives in ~/nama/project_name/.wav,
it never needs to be copied or moved again.
If you're ever in any doubt, look in that
directory for yourself. :-)
(The reason for the hidden .wav name is to
help the directory and its files from being
casually deleted.)
remove_track only deletes a data structure:
mainly whatever effects were on the track.
One way to preserve your work is
to use autosave. If you set
autosave: 2
in .namarc, you'll get an State-autosave-timestamp.yml file
every 2 minutes if there is a change in configuration.
This is not elegant. You end up with a lot of files in your
project directory. But it will give you some
added measure of safety.
Another way to save your work, is manually: When you get to
a good place, save to a unique name:
nama> save Strings_bus_ready
Ideally I'd like to have an 'undo' command able to go back
any number of steps, but that is waiting the appearance of a
bright, motivated and perl-loving computer-science student.
Responding to your post, tho, I did write a patch that
asks user permission before removing a track.
I kind of hate that, because it's fiddly, and people get used
to saying 'yes', so they end up causing the same damage
anyway!
Your suggestion of 'remove_track piano' syntax is well
taken, but consider what happens when you want to get rid of
all tracks in a sub-bus.
Right now you can say:
nama> for Strings; remove_track
With the new patch you can say:
nama> for Strings; remove_track quiet
To get the old behavior, in .namarc, set:
quietly_remove_tracks: 1
Finally, Nama (mostly) won't let you do anything bad, and I
promise you that State.yml can't get easily corrupted. If
something it broken, it will usually be for another reason.
In the worst case, if you send me State.yml, I can probably
diagnose and fix it for you. :-)
But that is rare. Ask Julien! It used to happen during
upgrades in the old days. Now very rarely. We
have tests for basic functionality, and our
design is changing in evolutionary, rather than
revolutionary ways.
If a single track appears to be screwed up, or behaving
badly.
- if it relates to REC/MON/OFF status, there is a
bus rec/mon/off setting that is like a mask, and
can influence whether you can record or even play
a track.
- try using 'dump' (dump_track) to
see if any settings are suspect.
- generally the only way to really create havoc
is by using the 'set' command, which bypasses
all of Nama's user protections. (Or 'eval'
commands to execute perl code written by
your cat.)
- 'set bus Strings' is the only 'set' command
that you should use routinely.
I could add an 'enable_user_set_command'. (But does that
begin to make Nama too much like a kindergarten?)
The only problem with 'set' is that it's too easy
to type. :-) But who wants type 'qset'? (Ugh!)
These are the type of decisions Underwood and
I spend debate endlessly while huge vats of
chemicals boil over hideously burning prisoners
and animals. (It really bothers us seeing
innocent animals get hurt.)
Joel
> Cheers,
> S.M.
--
Joel Roth
Other related posts:
