[nama] Working with nama: A Report
- From: "S. Massy" <lists@xxxxxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Tue, 27 Sep 2011 17:47:05 -0400
Hello,
As promised, though delayed, as usual, here are some bug reports,
wishes, and general thoughts after completing a reasonably-sized project
with nama.
SETUP:
The project consisted of about ten tracks with anywhere between no and 3
effects on a track and an insert to a specific instance of jconvolver on
every track. All waves were generated somewhere else, though some were
preprocessed by me before importing. I used no busses on this project,
and versioning only on two tracks. Fades were used extensively.
CRITICAL:
I am very happy to report that I encountered no critical bugs while
working with nama and there wasn't anything I wasn't able to do just
because of bugginess. Have yourself a beer, Joel!
SERIOUS:
The most serious bug I encountered is that, if ecasound dies (e.g
segfaults), nama panics and becomes unresponsive, not even allowing to
save changes. There's not really any reason why this should be, as they
are fundamentally separate, and nama should at least let one save
changes, if not just restart ecasound by itself.
(At one point, ecasound started segfaulting when adding new ladspa
effects, but I never figured out the exact sequence that triggered the
crash.)
MODERATE:
It looks as though, in mastering mode, nama fails to arm the first time
around, but thinks it is. So, upon entering mastering mode, or if
loading a project already in mastering mode, if one does not explicitly
issue the arm command but hits spacebar, nama thinks its playinb back.
If one then issue a show_track command, nama floods the screen with:
Can't perform requested action; no chainsetup selected. at
/usr/share/perl5/AnyEvent/Impl/Event.pm line 40
In general, I've noticed operations are a little less stable in
mastering mode, but not always.
MINOR:
Quitting saves state automatically, but loading a different project
does not, which can lead to confusion and loss of changes.
WISHLIST:
- As discussed elsewhere, an RCS based project data would present many
advantages, including progress management, divergent mix management,
undo/redo, and even autosave.
- More flexible routing could open up many interesting possibilities:
sidechaining, multiple inserts, reuseable effect chains.
- The ability to create an effect chain out of a track and/or to copy
certain effects and there parameters to other tracks would have come
in handy.
- The ability to set an beginning and end point for playback and
especially mixdown would have come in handy. I thought that's what
play_start_mark & co were for, but I guess they're more for edits.
- A command dpsplaying the effect indices along with the effect names on
a given track would be useful.
INTERFACE:
- Since a couple months ago, nama's show command displays
"mysterious" tracks associated with a parent track so that for a track
named vocals, for example, the display will also include vocals-9-wet
and vocals-9-dry. It's not too big of a deal, until one has ten or so
tracks with inserts, creating thrice that amount of tracks in the show
display. This means that *every* single time the engine is
reconfigured, one ends up in a pager. Is there a reason for this
behaviour? Isn't that what show_tracks_all is for?
- Addressing a non existent effect index throws an error like this:
Can't use an undefined value as an ARRAY reference at
/usr/local/share/perl/5.10.1/Audio/Nama/Text.pm line 94.
(It's too minor to be called a bug, really.)
- Some commands aren't really forthcoming about whether they did
anything or not; for instance, setting a tracks version to the version
it was already set at cheerfully outputs "Anchoring version N",
leaving it to the befuddled user to figure out he just issued a dumb
command. Same for things like mon, rec, and off.
- A few commands can be misleading: I had to go in the code to figure
out play_start_mark was an edit command, and not a general command as
I thought.
ECASOUND:
You may remember the discussions about ecasound losing touch with
reality when seeking and the possible help $seek_delay might offer?
Well, I found out that increasing my jack period to 128 and $seek_delay
to 0.2 did help a lot as far as seeking was concerned and experienced
very few glitches in that respect. However, soloing/unsoloing as well as
multiple successive mutes/unmutes caused to be a great source of
annoyance (the least pleasant part of my nama experience, in fact). So,
I was thinking, perhaps we should consider a $copp_delay to introduce a
short sleep between each copp-set commands? Could that help?
Well that is a very long e-mail already, and I hope I didn't let
anything slip through the cracks of this old brain of mine.
Thanks for reading and, as always, thanks, Joel, for working so hard on
a piece of software which works so well and provess once and for all
that one doesn't need any silly GUI sliders to work with sound.
Cheers,
S.M.
--
Other related posts:
