[nama] Re: FX Editor
- From: "S. Massy" <lists@xxxxxxxxxxxxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Fri, 28 Jan 2011 00:32:12 -0500
On Wed, Jan 26, 2011 at 09:06:41AM -1000, Joel Roth wrote:
> On Fri, Jan 21, 2011 at 03:04:34PM -0500, S. Massy wrote:
> > In any case, here are some ideas for an edit_effect idea.
> >
> > * From Nama prompt > edit_effect BH launches the editor on effect BH.
>
> efx BH
> efx [ current effect ]
Sounds good.
>
> Alternatively, we already check incoming characters
> for SPACE in column one of the line buffer.
>
> We could expand that to looking for various
> arrow keys, or capital letter (since all nama
> commands are lower-case) or a special trigger character.
Could this be a viable to a curses or some other interface? Personally,
I have no objection, I just thought some people might prefer visual
feedback.
What would be a safe/useful/confusion-free prefix for commands?
FXeditor could then just be a special mode where the prompt contains the
current parameter and its value and you poll for keypress events.
Definitely simpler, but is it feasible, desirable?
>
>
> > * Right/left arrow switches next/previous parameter, displaying name and
> > current value at bottom of screen.
>
> That sounds good to me.
>
> > * up/down arrow, pgup/dn, home/end, shift arrows modify current
> > parameter with various stepping values.
>
> Okay.
>
> > * ENTER brings up a prompt to enter literal value or arbitrary
> > increment/decrement.
> > * I returns current parameter to initial value when FXEditor was
> > launched, D returns it to default.
> > * ESC returns to prompt with current values, CTRL-ESC does same but with
> > previous values.
>
> Probably not ENTER or ESC, as GNU ReadLine's
> callback_read_char() routine doesn't give those to me.
>
> I'm thinking of:
>
> L - enter literal value
> I - increment by literal ( or +<literal> )
> D - decrement by literal ( or -<literal> )
> Q - quit mode (if we use a special mode)
> X - quit and restore original value
> F - quit and set default
No problem.
>
> If we use a special mode, we can use some vi-like
> alphabeticals as alternatives to arrow keys:
>
> a - home
> e - end
> h - back arrow
> l - forward arrow
> k - up arrow
> j - down arrow
> u - page up (can't detect Ctrl-B)
> n - page down
Sounds good.
>
>
>
> > * SPACEBAR still starts/stops playback.
> > (Keystrokes are only suggestions.)
>
> If we can start/stop playback, don't we also want
> to step forward/back, list marks, navigate to marks
Yes, we do. :)
Another thing needed would be:
- Ability to skip to a certain parameter without scrolling through the
list.
>
> Basically, to have a more jumpy (efficient, possibly
> suprising and hopefully not too dangerous :) interface.
>
>
> > Along with that, I would second the idea of a current effect for each
> > track put forward elsewhere
>
> I think that make sense, and is consistent with the
> current track/bus design.
I love consensus!
So in short, I would vote for the readline approach if it's feasible as
it would be friendlier, information-wise, and easier to implement, and,
also because the curses perl bindings can be a little heavy/slugish, at
least from what I recall. But would such an interface be okay from a
visual standpoint?
Cheers,
S.M.
Other related posts:
