[nama] Long answer to a Short question about commands.yml
- From: Joel Roth <joelz@xxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Fri, 10 Aug 2012 18:32:37 -1000
On Fri, Aug 10, 2012 at 08:53:08PM +0200, Julien Claassen wrote:
> Hi Joel!
> OK, so no options help and configuration help from the
> commands.yml. Could we put something in the help topic
> overview,reachable from help_topics.p?
I agree that all help should be available online,
including options and the man page (why not allow the person
a subprocess to do it?), and even any tutorials.
Launching of browser windows
may be permitted as well, why not give maximum
comfort? This is the 21st century, after all.
For now I'll add whatever I can to the
help topics listing.
Thinking broadly, about tutorials,
We could have a sample project, with audio files
that downloads from github, packaged with
the distribution.
Sharing that could provide a
be a common platform to demonstrate bugs,
something we've always done.
If we have a script, perhaps a command history for the
project, we could replay it for testing, and checking
outcomes, and then play back the same test to demonstrate
for users.
I don't know if it's too much trouble, it would be an
interesting tool for accessibility.
On the subject of accessibility,
I also had the idea of whether Nama
could concentrate responses enough
to be able to run it with a keyboard
and audio feedback via headphones.
That would let engineers work in the
field, even if the screen of their laptop
broke. :-)
I think it's an interesting question,
whther audio responses could concise enough
to actually record a project.
I wonder if we could feedback every keypress audibly
to confirm typing.
So, that's the disclaimed thinking broadly.
Less challenging would be think if we want to create a typical
example of music production.
I can imagine blurring testing with tutorial, if
you had an automated script. You could run
a whole script, that would announce itself,
an execute a command.
"Okay, now we're going to add a track." # possibly by audio
nama> add_track massyguitar
nama> source 1
nama> start
"This is a simulation, but here is a sample of the
audio Massy is laying down."
A few seconds, and fade out.
and *bling* the first track pops up of the
guitar part.
I mean, why not use Nama to deliver the
presentation, as well. We don't need
to screen capture, if we can just
use Nama to present the material.
Also, Julien, you mentioned about whether to
spend more time stabilizing Nama. Limiting
the recording time and providing keyboard
access during commands such cache_track
seems to be the most important thing
in the current-awkwardness category.
If I fool around with regions, I guarantee
I won't change the semantics of existing
regions. It would be part of the editing
infrastructure. It's going to be fairly
cheap to do.
Also, if we could unconstrain the playback
region, people could be in the editing
mode while still having full access to the
track at any time except during punch in itself.
That would fit in with Massy's go to active
region command.
Okay, going outside while there is still light...
Joel
> It would just be nice to have it all in there, whle I'm at it. I'm
> just creating a list of problems and questions in parallel to my
> work.I'll post it, when I'm done.
> Massy: How about you going through the manpage? Or shall I do that
> as well? I just ask, because you also mentioned it.
> Best wishes
> Julien
>
> 050e010d0f12010401-0405-0d09-030f12011a0f0d-
> Such Is Life: Very Intensely Adorable;
> Free And Jubilating Amazement Revels, Dancing On - FLOWERS!
>
> ******** Find some music at ********
> http://juliencoder.de/nama/music.html
> ---------------------------------------------------------------
> "If you live to be 100, I hope I live to be 95 and 37 days,
> so I can be sure, there's someone at your site, who loves you."
> (Not Winnie the Puh)
>
--
Joel Roth
Other related posts:
