[nama] Re: What about this display?
- From: Ffanci Silvain <silvain@xxxxxxxxxxxx>
- To: Joel Roth <joelz@xxxxxxxxx>
- Date: Sat, 2 Jan 2016 17:12:10 +0100 (CET)
Hey hey Joel,
and a happy new year to you and everyone else, who is reading!
Joel Roth, Jan 2 2016:
...
No. Name Status Source Destination Vol Pan
=========================================================================
1 Master MON (play) -- 1/2 0 50
2 Mixdown OFF -- -- -- --
3 sax OFF (play) null Main 0 50
...
Track 3, sax, is set to PLAY, so it ignores source setting
of "null", looking instead for a WAV file, which, when not found,
causes the status to be OFF.
The distinction between setting and outcome has been with
Nama since the beginning. I wonder how to make this simpler
in the display.
Here's one suggestion, that struck me. It's imperfect and possibly not
feasable. In the end the two status fields reflect, that a track is alive or
dead with respect t5o the desired setting. The foundation for their activity is
either a matter of disk I/O (the presence of a file) or the mode, which may
inhibit certain operations (disk input or input from the same hard- or software
channel). In a few cases more restrictions could be put into action. A Mixdown
track should never be set to MON. A master track never to PLAY. Caching a
mster track is effectively mixing somthing down. Whereas a Mixdown's whole
purpose is to capture a snapshot of what is passing through the Master track.
So the paradigma of two "status" fields still holds true. In doodle mode all
PLAY'ing tracks are inactive as are duplicated input tracks, only one of them stasy
active. How does Nama handle this at the moment? If there are three tracks sourced from
the same hardware input port. Will Nama always choose the first? Or will it check first,
if one of these three tracks is active and prefer that one over the natural unbiased
choice?
Every other user track can be MON or REC in the arm'ed mode.
So the logic in my mind is: choose "live" and "dead?" and otherwise print the actually set track
status. In doodle and preview mode only MON is allowed, which conflicts with that idea somewhat. This could be
cushioned by including a short mode indicator in the "show" and "sh" commands. Actually two would
be better: one at the top and one at the bottom. It will suit both major systematic reading methodsw, that a user can
adopt. At least, the only two, that I can think of.
And then split the status field into two fields: status and active perhaps.
What to put in such an active column? Live and Dead? On and Off? I'd suggestion
putting something meaningful, if abbreviated into that field, not just Yes and
No, since that will require the user to return to the table heading. That
helps, but the way Nama displays its table right now, you get a meaningful row
of the table without referring back to the heading. The volume and panning
settings are debatable points for t5hat argument. But they are best represnted
by numerical values and have no meaningful unit, that I can think of. Besides
the table is norally limited by a space of 80 characters, the standard terminal
width.
Another approach might be to simply disallow actions, that try to change a track to an
unreachable state and otherwise only print the currently effective status. Though this
could lead to more confusion and misunderstanding. But this is only my opinion. I can
certainly do without the "potential status" of a track. I simply wonder, what
others might make of it.
Having looked into this, have you come up with insides to a solution? Do you
feel a preference for a certain level of information or
restricting/restructuring of commands? I'm sure there are quite a few other
viable possibilities for this conundrum, which might turn out much better than
the two sketcehd out above.
Thank you for once again letting us take part in the decision process and the
active forming of the environment we thrive in. It's a very comfortable place
to work in and be creative with.
...
Ta-ta
----
Ffanci
* Homepage:
https://freeshell.de/~silvain
* Twitter:
http://twitter.com/ffanci_silvain
* GitHub:
https://github.com/fsilvain
Other related posts:
