[nama] Re: commands.yml
- From: Joel Roth <joelz@xxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Sun, 12 Aug 2012 14:58:32 -1000
On Sun, Aug 12, 2012 at 06:20:12PM +0200, Julien Claassen wrote:
Well, not to worry. There are other things. I've seen, that there
> were quite a few changes, when I pulled just now. I will have to try
> and see, how Nama amzes me today. :-)
If it works, that will be amazing! There aren't many visible
changes. :-)
I've looked over your suggestions list. Find my
responses inserted below, marked with !
Great work, Julien, I appreciate it!
cheers,
--------------
General:
Shortcut-particles for different categories.
Track has no "t" added to any command, it being the most frequent.
bunch - bn
bus - bs (at the moment b-prefix)
effect - fx (already consistently done)
effect_chains - ec (already in place)
effect_profile - ep (already in place)
mark - mk
project - p
project_template - pt (already in place)
send_bus - sb (already in place)
fade - fd (already in place)
comment - c (already in place)
! So bunch/bn mark/mk project/p need attention
Adjusting time:
Allow + | - with times for more floating point params:
pan, shift <f_seconds>, loop(?),
The reason is easier adjustment, the user doesn't have to know, where exactly
a parameter is, but can just modify it relatively.
! Agreed, although as you mention, there is the problem when
position is specified using marks.
help:
allow for capitalisation (as shown in just 'help')
! Not clear about this.
rec:
Make the full command record and rec a shortcut to comply with rerec.
! Do-able.
setpos:
couldn't we set position in samples or frames as well? Just asking.
(time commands in general):
The same question goes for forward and rewind.
! Two jobs: 1) convert underlying representation to samples
2) allow use to specify times in either frames or seconds.
add_track:
The add_track name key_1 value_1 - does not work properly.
Either fix or remove. I have never used it. Ask around?
! Agreed
add_tracks:
Shortcuts add and new don't work, collision with shortcuts for add_track.
! Agreed
import_audio:
What's the i_frequency for? It's not described.
! That's an optional sample rate parameters, in case
Nama can't tell what it should use.
source:
When giving a port to a stereo track, only one input port is allowed and used;
stereo;source synth:p1 synth:p2 - does not work, synth:p1 is set as input.
! "source synth" will do the right thing, if synth has a stereo output
remove_send:
Consistent shortcuts: noaux, nosend, noout or change shortcuts for send.
rmsnd and on the other side asnd (the add or apply and remove pair).
! nosend sounds good to me.
list_versions:
Again the shortcuts: either lver and ln or rename the second shortcut for
version from n to v, to be consistent.
! Agreed
unmute:
The capital C is another alternative for send/remove_send, but you'd have to
find a letter other than S, because, that's used for ecasound_stop.
??
show_tracks_all:
Shortcut consistency: allow for lta and perhaps remove sha, because it's too
similar to sh, which is something different.
! Worth reviewing if we have a clear distinction between
list_* and show_* commands, the former giving names, the
latter giving more information.
show_bus_tracks:
Shortcut consistency: ltb and showb would be OK, but again remove shb please?
!
set_region:
Allow for mark indices as well as mark names.
! Agreed
new_region:
I propose to call it add_region, as add_track, add_effect... new is used for
creating global things (effect_chains, effect_profiles), then also have the
shortcut arg.
! add_region is okay.
Also allow for using mark indices as parameters.
! Agreed
remove_region:
Should we have a shortcut? Make it hard to destroy/lose data.
! Not sure, is there a scenario someone might want to
conveniently remove many regions?
shift_track:
In deed think about + | - to adjust shifting and perhaps display shift time,
when used without parameter (low priority).
! Agreed
bus_rec and bus_mon:
Do they really change the bus' mix-track from rec (rec) to MON, if a cached
version is there?
bus_off:
What about shortcuts bo and go (in consistence with mro, mxo)?
! Need to review
bus_version:
See comments about version and list_versions command above.
How does this work? Just typing bver - in a test project - doesn't yield any
result. "New bus default version is:". No number and I ca't use this command to
set a number.
! Obsolete, we can't set a version for an entire bus that
way. The workaround is:
nama> for Strings; set_version 5
new_bunch:
Again use add_bunch - as in add_track, add_effect, add_sub_bus...
So have: add_bunch - abn
! Agreed
list_bunches:
Change shortcut to lbn.
! Agreed
remove_bunches:
Rename to remove_bunch in accordance with remove_track, remove_bus,...
Remove the shortcut or change to rbn.
! Agreed, rbn
add_to_bunch:
Difficult to change. Perhaps with shortcut atbn (Add to BuNch). This is a
unique case.
save_state:
Suggestion for a shortcut: store .No reason, than it being common language
for that.
! Agreed
get_state:
Proposal: load_state and as shortcuts reload restore and recall.
! Agreed
get/save_state:
Perhaps a more user-friendly name might be *_project, in keeping with the
other commands.
! Is "get_state" different from "load_project" ?
create_project:
Why not new_project and shortcut new, as for new_project_template,
new_effect_chain... And have create as one shortcut?
! Agreed, new_project with shortcut create
use_project_template:
I still wonder if apply_project_template might not be better. Even, if the
name is slightly less correct, it's much easier to guess and use intuitively.
The shortcut apt is already in place.
! Personally, I like use_project_template (upt) better than apply...
remove_project_template:
Does this destroy the template file or remove all tracks from the curent
project, that were added by using use_project_template? I think it's removeing
actual template_files. Then it would be better to stick to
destroy_project_template and ave no shortcut, in keeping with: make it
difficult to destroy work.
! Agreed: destroy_project_template
arm/arms:
Note to self: find a better more user friendly help text.
enable/disable_loop:
consistency: use long name loop and noloop and for shortcuts perhaps l and L
or l and nl?
! Is anyone actually using this?
insert_effect:
Why prior to arm only? I have used it in a running setup. :-)
position_effect:
! Outdated I'm sure.
move_effect might be a better name or shift_effect. Move, because it's common
language and shift, because we already have time shift at least. It's a weak
argument though.
add_insert:
What does the "local" in the description mean? Where does it go? What will it
do? Example?
! Just create the auxiliary tracks without external signal
path, so you can have wet/dry control over a LADSPA plugin.
*_register:
Region has the short form rg. so make it reg perhaps or in general switch the
shortcuts around rgc rgp...
! I just use tab completion, which takes care of this, but
you can add these shortcuts if you like.
new_mark:
In keeping with the typical scheme, why not add_mark, and shortcuts amk, mark
and k?
new_mark without a parameter causes an error message to be printed. It still
works. Forbid that or fix that?
! Agreed
next_mark:
If new_mark were to be renamed, the shortcuts could also be a little more
unambiguous.
! Agreed
name_mark:
Shortcut collision with next_mark nmk. Remove shortcut for name_mark, since
is used less frequently.
! Agreed.
dump_track:
Remove the shortcut dumpt, since no track commands have the 't' in their name.
! Agreed
dump_group:
What is a group? Perhaps another name?
And remove the shortcut dumpgroup, found nowhere else like that.
! Review code
dump_all:
Again remove shortcut dumpall.
show_io:
Shortcut showio is somewhere in between, since io already is an abbreviation.
Still think about removing it.
Perhaps rename the command to dump_io, since from a user perspective it's
similar to the dump_* family. Show internal information, mostly needed for
debugging and diagnostics.
! Agreed: dump_io
delete_effect_chain:
Proposal to rename to destroy_effect_chain and have no
shortcut. Make it difficult to destroy information and
rename it to destroy, because other commands, which
permanently remove templates and files are called destroy.
Also the user will think twice with a name like that. :-)
! Doesn't sound quite so serious as to merit calling it destroy
find_effect_chains:
A usage example is needed for key value pair. but I'd still vote for having
list_effect_chains (lec) wihtout parameter and find_effect_chains (fec) with
one parameter being name or part of the name, as for find_effect.
! I agree we need a simpler command for searching, although
the key-value search is important to keep.
find_user_effect_chains:
For consistency, make the shortcut fuec .
! Agreed
bring_back_effects:
Perhaps rename the command to restore_effects (and have bring_back_effects as
an alternative?
! Agreed
delte_effect_profile:
Rename to destroy_effect_profile and have no shortcut.
! Agreed
show_effect_profiles:
What does it do? Is it necessary with list_effect_profiles? If it is more
like find_* rename it.
! Good question.
Rename the shortcut to sep and think about another name for the edit command,
which has sep as a shortcut.
full_effect_profile:
Rename to dump_effect_profile and shortcuts dumpep. fep can be misleading see
fe .
cache_track:
Probably remove the ct shortcut, for there was only dumpt, which had teh 't'
at the end and c can't be used.
! The two-letter shortcut ct is okay, IMO
Can cache_track use the + x (seconds) syntax? is cache [ <f_secs> ] still the
only allowed syntax?
! Agreed, allow incremental setting
show_comments:
Perhaps make the shortcut sca (as in shla or showa).
! Okay
add_version_comment:
Collision with shortcut for add_comment "comment".
! Good find
show_version_comments_all:
What's the difference to show_version_comments. Is there a typo and svc shows
comment for current version, while svca shows all?
! Sometimes there are system comments as well as user
comments, which i think this command may show.
set_system_version_comment:
This also has the shortcut comment, which is in collision with ac and avc.
! Good find
set_edit_position:
Suggestion for shortcut sep: sped (setpos edit). Just an idea.
! This is the notorious, three-P-keypress marking procedure.
preview_edit_in:
For consistency: pedi as shortcut.
! Umm...
preview_edit_out:
Again set the shortcut as pedo.
! Oops, pedo, hah-hah-hah, pedo! No way!
All edit functions:
Especially preview_* would benefit from clearer description of behaviour or a
comprehensive example. The whole edit command set is well disposed for a
tutorial.
edit_track, host_track, host_track_alias and version_mix_track, should need
some better explanation. Perhaps a rename of commands to somehow fall into an
edit-name-scheme. Just thinking...
! Agreed, we need an editing tutorial
promote_version_to_track:
Perhaps use pv as a shortcut or promote (add, show...)
! What about pvt? pv might be confused for preview
limit_run_time(_off):
shortcuts and consistency: Either make it: lr and lro (as in mr and mro) or
lrt and lrto.
! Agreed
offset_run:
Allow for i_mark_index and f_time_seconds (as with some other commands)
! Agreed
offset_run(_off):
Consistency in shortcuts: of and ofo or ofr and ofro .
! I prefer ofr/ofro
check_level:
Reconsider shortcut, could be confused with sometlhing controller.
! chkl ?
> Warmly yours
> Julien
>
--
Joel Roth
Other related posts:
