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

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.

For other purposes, it might be sufficient to start up
Audacity or Mhwaveedit to handle waveform viewing/editing
needs. Why reinvent the wheel?
 
> > 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!
 
> > 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.

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.

> > > 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.
 
> > 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. :-)

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. :-)
 
> > > 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!

Incidentally, I just found out that it's possible to embed
Lua in Perl.

http://search.cpan.org/~vparseval/Inline-Lua-0.04/lib/Inline/Lua.pm

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

> --
> Regards,
> Philipp

-- 
Joel Roth
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list