Re: [ecasound] Nama/Ecasound (was: Re: ecasound and lua?)

From: Philipp Überbacher <hollunder@email-addr-hidden>
Date: Mon Jul 19 2010 - 13:45:03 EEST

Excerpts from Joel Roth's message of 2010-07-18 02:23:41 +0200:
> On Sun, Jul 18, 2010 at 12:00:29AM +0200, Philipp ??berbacher wrote:
> > Excerpts from Joel Roth's message of 2010-07-17 23:31:25 +0200:
> > > On Sat, Jul 17, 2010 at 10:11:08PM +0200, Philipp ??berbacher wrote:
> > > > A waveform view is a future feature for nama. So far I've seen only one
> > > > frontend that has anything like that. Is it especially hard to do with
> > > > ecasound?
> > >
> > > To start, we could create a graph from the WAV data
> > > for a track. Ecasound isn't even needed for this.
> > > To draw a graph with Tk isn't especially hard.
> >
> > I assumed that was the case. Different programs handle this differently
> > in the simple recording case, Traverso waits until the recording is
> > stopped before it draws the waveform, Ardour draws it in chunks. Either
> > way is fine IMO.
> >
> > > But if you apply effects, say a fade, then probably you
> > > want to see the processed waveform, not the original.
> >
> > Yes, probably. Traverso does this nicely. All effects in T(raverso) and
> > A(rdour) are realtime effects, so what they probably do is to work with
> > the waveform, not the actual audio data, when displaying stuff like
> > that.
> For many purposes, it may be valuable just to view the recorded
> signal.

Yep, I think that would be enough in many cases. Maybe automation
editing right next to the waveform would be sufficient. Automation is
one case where I think that a waveform is more than just 'nice to have'.

> For other purposes, it might be sufficient to start up
> Audacity or Mhwaveedit to handle waveform viewing/editing
> needs. Why reinvent the wheel?

For destructive editing that makes sense.

> > > So it would be necessary to run the engine, record
> > > the track output as a WAV file, and display _that_.
> >
> > I guess that's true for T and A as well, at least for any effect more
> > complex than a fade.
> As a hot-blooded male, I can state proudly that I like T&A!

My research suggests multiple possibilities [1], but because of the male
reference I assume you mean the wrestling team :)


> > > In other words, you would have a processing delay after each
> > > effect tweak before you could see the result. Perhaps that
> > > processing run could could be performed in the background.
> >
> > This is what audacity does, and part of why it is categorized as audio
> > editor, not a DAW, so I guess the question is more about the goal.
> > Offline- or Online-processing, or both?
> The convenience of realtime processing is one of Ecasound chief
> advantages over Audacity, IMO.

While it was afair the first audio recording program I ever used, it's
pretty much the one I like least now. The offline processing is one of
the smaller problems, it sometimes is an advantage.

> That said, Nama also implements a track caching function
> (AKA track freezing) to free up CPU in constrained
> situations. We could work from that. Of course it's much
> quicker (for the computer) to process
> a subset of the audio data.

This certainly is a nice thing to have. How do you do that? Process (in
realtime?) and write to another file?

> > > > I don't necessarily need it but especially in combination with
> > > > automation it would be a good thing to have.
> > > >
> > > > Said automation is another thing I'm wondering about. Is there a way to
> > > > do proper automation? Via MIDI CC possibly? Is there another way?
> > >
> > > If you just need an envelope of some kind, it is already
> > > possible with Ecasound alone. (See CONTROL ENVELOPE SETUP
> > > in the man page.)
> > >
> > > Nama already has simple fades, but of course could be
> > > tinkered to do more.
> >
> > Thanks, I had a look at that part of the man page. Most envelopes seem
> > to be linear, which is fine in some cases but not others, however, that
> > one generic linear envelope that lets you specify any number of points
> > looks interesting after a quick glance.
> Yes, that is what Nama uses to provide fades.
> It's also possible to schedule effect parameter changes
> directly, which Nama uses for fade-out at transport stop.

Scheduling this stuff is something I wonder (see mail to Kai). So how do
you schedule it, sample based or using some timer internal to ecasound?

> > > Ecasound effect parameters (whether internal or LADSPA
> > > plugin) can be controlled directly by a MIDI controller.
> > > An intermediate process would be needed for Nama to store
> > > those changes for subsequent replay.
> >
> > Exactly what I had in mind. One downside however might be that MIDI CC
> > is limited to 128 values. I'm not claiming it's not enough, I have no
> > idea :)
> > > Ardour is ready to do all expected forms of automation
> > > today, and may be your best choice for instant
> > > gratification (minus Ardour's learning curve.)
> >
> > I know my way around A2, but I don't want to use it anymore. It feels
> > very heavy, has loads of features I'll never need and also quite a
> > number of known bugs. It doesn't do all forms of automation either, per
> > clip automation is missing for example. Eventually it's a matter of
> > preference, nothing is perfect.
> Nice to hear that in your estimation, there is a place for
> other DAW software than Ardour. :-)

There sure is, A can be surpassed in many areas. Reliability and
usability for sure, even features to a degree. I'm not alone with that
estimation, there's at least one guy who switched from A to T for his
orchestra work. He's working with Remon, T's author, to make T into a
professional DAW, and in at least performance and usability it does
surpass A already. It's a relatively special case, but it's a case :)

> Nama's further development of automation, if it is to
> happen, will be driven by specific user needs and proposals.
> At the moment, I don't think I'm likely to conquer new frontiers
> without some prodding. :-)

From what I gathered from Juliens mails, you respond well to prodding :)

> > > > I know those are rather advanced features, I'll be glad if I manage to
> > > > write a proof of concept frontend during the next few weeks, but it
> > > > would still be interesting to know what would be possible.
> > >
> > > I'm very interested to learn about your concept
> > > as well as your proof. :-)
> >
> > Hehe, my concept is quite simple.
> > Is it possible for me to write an ecasound frontend in lua?
> > And I'll already be happy about something that proofs that I could get a
> > usable result, given a lot of time :)
> > I try to stay realistic, I'm happy if I manage to write a GUI that
> > controls some simple aspects of ecasound. Actually writing the thing I
> > envision will certainly take a long time.
> Writing a GUI adds signifant overhead. Even with good
> libraries to help, GUIs bring in a lot of complexity. Nama's
> GUI is about a thousand lines.
> By separating Nama's processing logic from the GUI, I was
> later able to add a text interface. I've pondered a third
> output interface... a speech output. Done cleverly, I'm
> wondering if an engineer with headphones could record
> a session without referring to a screen at all!

A text interface is something I won't need, you seem to have covered
that nicely already.

I wondered about audio feedback one or two times, and I agree that
would need to be done in a really clever way. The main issues I see are:
a) input errors
b) holding control responses and production audio apart

> Incidentally, I just found out that it's possible to embed
> Lua in Perl.
> So you might be able to mock up some things taking
> advantage of Nama's existing data structures.
> Of course if you were going to work in Nama, reading
> from the source, then you might as well be programming in
> Nama's implementation language!
> Cheers,
> Joel

Heh, yes, lua can be embedded pretty much everywhere, but I don't want
to make it even more complicated than planned. Using lua is already
strange enough :)

"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
This email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit --
Ecasound-list mailing list
Received on Mon Jul 19 16:15:04 2010

This archive was generated by hypermail 2.1.8 : Mon Jul 19 2010 - 16:15:04 EEST