[nama] Re: Wolfdream article on Nama
- From: Joel Roth <joelz@xxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Thu, 9 Aug 2012 14:19:06 -1000
On Thu, Aug 09, 2012 at 07:14:09PM -0400, S. Massy wrote:
> On Thu, Aug 09, 2012 at 11:53:36AM -1000, Joel Roth wrote:
> > Hi Massy,
> >
> > Thanks for writing this! You bring up some good topics
> > for discussion.
> >
> > http://www.wolfdream.ca/article3
> My pleasure. I wrote this article because I felt Nama deserved some
> exposure, bcause it's growing into a very good piece of software, of
> course, but also because:
> - It allows for a unique recording/mixing workflow.
> - It disproves the long-standing assumption that a GUI is the only
> sensible way to handle audio streams. (Yes, there are a lot of textual
> synthesis languages, but they fulfil quite a different role.)
> - As I feel Nama, or a similar solution, is the only way in which I
> could competitively hope to work in the audio production world, I
> naturally would like to see it thrive!
> Quite selfish, you see...
I'll add one more feature. It's written in a high-level
language, easy to hack, with smallish codebase, while the
engine is independent, mature and efficient.
> > One comment about documentation. Did you ever look
> > at the man pages? I worked hard to describe Nama's
> > underlying functionality.
> OUCH. And I didn't even know there was a man page. My apologies: I'll
> have a read and contribute improvements if/where necessary.
The man page is behind in documenting changes to
bus/track interaction relating to track rec_status.
> I still feel
> some basic getting started use-cases might be necessary, like those found
> in the ecasound documentation (which I haven't read in years).
I tried writing a tutorial, but the amount of text is somewhat
troublesome.
http://freeshell.de/~bolangi/cgi1/nama.cgi/examples.html
> > Regions. I didn't get what you're looking for
> > in terms of managing larger projects. That could
> > be a low-hanging fruit to go after.
> Nama's regions are more like multing or exporting parts of a track from
> a mother track. In a regular DAW a region remains part of a track,
> although it can be muted, have separate effects, etc., and one can
> interact with each region seamlessly according to where the playback
> head is.
Right now, the new_region command creates a new track that
contains a single snippet from an existing (mother) track.
That is convenient, since one track generally becomes one Ecasound
chain, and each track, like each Ecasound chain, can have one
sequence of effects.
Currently regions do *not* get a copy of the mother track's
effects. It is up to the user to create an effect
chain for this purpose.
IIUC, what you're envisioning, would be to show a single track,
but the underlying selected track (i.e. region) would change based
on the playback head position.
If I selected a region and turned down the volume to 50%. The
mother track should zero the signal for that audio segment,
and the region's volume control would control the output
level.
Possibly the prompt could display a region name as well:
nama [ Strings/violin/first_chorus ] >
The hidden track (region) might be named violin-first_chorus.
All of the regions for a track could feed a bus.
This is all somewhat complicated, but not impossible. In
fact, edits already employ a similar functionality of
converting a single track into a collection of buses (minus
the position-dependent track selection).
Underneath, Ecasound handles the complexity without
complaining. Signal routing for loop devices is well
tested.
> It's not impossible to achieve something close to this in Nama,
> if, for instance, you export all the wanted regions (but what about
> contiguous regions?), move them to a buss of their own and set the
> mother track to OFF. But, in the hypothetical context of a medium-sized
> commercial-grade production, which was that of the article, you might
> easily have, say 25 tracks, half of these needing to be regionised: it
> could become a fairly slow and error-prone process.
It's similar with edits, possible but awkward to do
manually. Fortunately, automating shit is what computers
are good for.
> > Automation. Perhaps this could be attainable, too,
> > with a reasonable programming effort, if we can
> > do it with Ecasound envelopes, and/or if we could
> > manage to record MIDI controller inputs.
> > Someone would need to plan it.
> I'm confident that it can be achieved with ecasound envelopes, though we
> might unearth some more bugs for Kai in the process. :) As to how this
> can be achieved, I think we probably need to throw some ideas back and
> forth to come up with something efficient and intuitive enough to be
> useful. After all, automation is just like fades, save that both start
> and end are non-zero and the target OP can be any effect. Couldn't much
> of the code for fades be re-used?
Yes the code is similar to fades.
I'll just note, in contrast to your pronouncement that
lack of automation is a dealbreaker for large projects,
You can already achieve automation by applying Ecasound
envelope controllers to any Nama effect parameter. You're
just lazy. :-)
> Definitely, I think Nama might need to acquire some time-sensitive
> commands eventually, such as go_to_active_region, or
> show_automated_parameter.
Yes, we could use track/position to select a fade,
select a region to set the playback position to region
start, and show_automated_parameters could list
all automation for the current track/region.
All in all, its a nice list of do-able small parts.
I just need a prescription of Adderall :-), or a
programming minion, someone who's good for more
than merely torturing prisoners (we can leave that
to the government.)
(...)
> > Thanks again.
> Well, really, thank you!
Well, we're grateful to your help in getting the pot boiling
again. :-)
> Cheers,
> S.M.
>
--
Joel Roth
Other related posts:
