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

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

[1] http://en.wikipedia.org/wiki/T%26A

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

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

-- 
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list