[nama] Re: Working with nama: A Report
- From: Joel Roth <joelz@xxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Tue, 27 Sep 2011 17:01:09 -1000
Thanks for the report!
It's great to have another engine pulling this train!
A few responses follow below.
On Tue, Sep 27, 2011 at 05:47:05PM -0400, S. Massy wrote:
> 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!
<pop!> <slurp!> Well, having done that, still most credit
goes to Ecasound's author. :-)
> 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.)
Here's what I see.
Case 1: Nama using Audio::Ecasound
$ killall ecasound
[in Nama]
(ecasoundc_sa) Error='sync error', cmd='engine-status' last_error=''
cmd_cnt=3742 l
ast_cnt=3725.
***********************************************************************
* Message from libecasoundc:
*
* Connection to the processing engine was lost. Check that ecasound
* is correctly installed. Also make sure that ecasound is either
* in some directory listed in PATH, or the environment variable
* 'ECASOUND' contains the path to a working ecasound executable.
***********************************************************************
The message repeats periodically, every time a polling
trigger causes Nama to send an IAM command. However the
command prompt is still available (at least to me.)
nama> eval select_ecasound_interface # Nama recovers
Case 2: Nama using -n (--net-eci)
$ killall ecasound
[in Nama]
send: Cannot determine peer address at ../lib/Audio/Nama/Initializations.pm
line 248
As above, the message repeats, however the command
prompt is available.
Likewise, Nama recovers with 'eval select_ecasound_interface'.
Will see if I can detect these conditions, kill and relaunch
the engine.
> 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.
In addition to noting this (mis)behavior, it is interesting
to hear that the mastering mode is useful to you. (The
latest I read about mastering on the LAU list is that most
such tweaks are better applied at the level of individual
tracks during the mix.)
> MINOR:
> Quitting saves state automatically, but loading a different project
> does not, which can lead to confusion and loss of changes.
Would this behavior be better?
* save on loading a different project
* don't save on loading the same project
* don't save on issuing the get_state command
> WISHLIST:
> - As discussed elsewhere, an RCS based project data would present many
> advantages, including progress management, divergent mix management,
> undo/redo, and even autosave.
We already have a kind of autosave that litters the
project directory with files named something like
State-autosave-2011.09.25-21:05.yml. It saves
provided the file differs from the previous
autosave output.
I'll see if I can conceive of a reasonable model for
integrating RCS (most certainly git).
> - More flexible routing could open up many interesting possibilities:
> sidechaining, multiple inserts, reuseable effect chains.
Not sure about sidechaining. Effect chains and effect
profiles *are* reusable. For multiple inserts,
the easiest solution is to work this way:
nama> add_insert send_client_name return_client_name
return_client_name is optional. You could have
several JACK clients strung together, telling
Nama only the names for the first and last.
> - 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.
new_effect_chain, list_effect_chains and add_effect_chain
are probably what you want.
nama> h effect_chain
> - 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.
loop_enable <start> <end>
may do it for you.
> - A command dpsplaying the effect indices along with the effect names on
> a given track would be useful.
Julien mentioned the 'sh' ('show_track') command.
You shouldn't need to deal with effect indices.
> 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?
The track listing automatically outputs anytime there is a change
that triggers regenerating the chain setup.
For some reason, I recently changed Nama to trigger
'show_tracks_all', which is probably not right,
since temporary, special-purpose tracks should
*not* show up.
> - 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.)
Data validation would help.
> - 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.
Ideally we would tell the user, "piano: already anchored to
version 6" or "piano: already set to MON".
> - 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.
I see that "help foo" doesn't currently show the command
category. Easily fixed, and we need this. (You shouldn't
have to burrow to find it, although I consider your
burrowing to be a positive sign. :-)
> 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.
I can move seek_delay to .namarc. Your comments on JACK
period setting might belong in a Nama setup guide,
or perhaps just a comment in the default .namarc.
> 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?
Can you describe these annoyances?
One thing we *don't* have with Ecasound is a way to know
how quickly or slowly we should be sending successive commands.
Doesn't Ecasound have some kind of command buffer so the
engine can process commands as it is able?
> 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.
I'd like to recognize your contribution with the
Nama/Ecasound "Brain of the Week" award. (Redeemable with beer
and pizza at the 1st International Nama/Ecasound BOF. :-)
> 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.
Thanks. It's my autodidactic path to Applied CS and
accessibility studies. (Speaking of sliders, I recall
that the Nama GUI is still broken.)
Best,
Joel
> Cheers,
> S.M.
>
>
>
> --
>
--
Joel Roth
Other related posts:
