[nama] Re: Working with nama: A Report
- From: "S. Massy" <lists@xxxxxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Wed, 28 Sep 2011 17:44:56 -0400
On Tue, Sep 27, 2011 at 05:01:09PM -1000, Joel Roth wrote:
> 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:
> > 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'.
Interestingly enough, upon testing this, I found out that, if using
libecasound, the prompt remains responsive and issuing save/quit does
work, but, using the neteci, which I was, it doesn't. This said, the
eval command *does* work.
>
> Will see if I can detect these conditions, kill and relaunch
> the engine.
Looks like you already did! :)
>
> > 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.)
Well, it's a complex matter with more shades of grey than clear cut
colours. This said, my take on it is that, in an artistically perfect
world, especially when dealing with one's own tracks, there is no reason
why everything should not be done at the recording/mixing stage; but,
living in an artistically imperfect world, especially if doing the work
for someone else who probably expects their material to sound consistent
with similar commercial material (I.E brutalised) and may not always
provide tracks up to scratch, mastering is a fact of life and can even
sometimes prove a blessing. To that end, nama's mastering chain has
served me well and proved flexible enough to keep me happy, though it's
probably simplistic by big DAW standards (I've no idea, really).
>
> > 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
Yes! Of course, another way to do it would be the vi way: leave saving
(w) entirely up to the user, but refuse to quit or load another project
unless specifically overridden ($). As a vim user, the latter appeals to
me, but most likely the former is more in line with the way nama already
does things.
>
> > 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).
As I said elsewhere, that would be great!
>
> > - 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,
Yes, as I said in my previous e-mail, I really have to go and learn more
about effect chains and profiles in nama before I complain any more on
the topic. :)
> 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.
This does make good sense. The only drawback I see to this approach, of
course, is that one would not be able to set the wetness for individual
inserts, one just gets an all-wet and an all-dry signal.
>
> > - 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
Ditto, as above.
>
> > - 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.
This would indeed be useful while working, but not when in mixdown mode.
In mixdown mode, I'd like to be able to set a start and end mark and ask
the engine to create a mixdown with the audio between the marks.
>
> > - 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.
See my reply. I confused effect IDs and indices which are quite
different in nama.
>
> > 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.
Definitely.
>
> > - 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
That would be very helpful.
> have to burrow to find it, although I consider your
> burrowing to be a positive sign. :-)
Yes, it is, I don't do it nearly enough. :)
>
> > 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
Yes, I think it belongs there, really. Besides, it's easier to
experiment and find the right value that way.
> period setting might belong in a Nama setup guide,
> or perhaps just a comment in the default .namarc.
Yes.
>
> > 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?
Same as with the seek problems. Ecasound goes mysteriously silent: it
says its engine is running, and obeys stop/start commands, but it does
not output any audio untill the chain-setup is disconnected and
reconnected. It's very annoying when working.
>
> 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?
I really don't know. I don't remember libecasoundc discussing any such
features when I wrote something using it way back when. Probably a good
question for the ecasound list, since I don't think many other
applications have stressed the ECI as much as nama does.
>
> > 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. :-)
*chuckle* that sounds grand!
Cheers,
S.M.
Other related posts:
