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

On Mon, Jul 19, 2010 at 12:45:03PM +0200, Philipp ??berbacher wrote:
> Excerpts from Joel Roth's message of 2010-07-18 02:23:41 +0200:

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

If you make a copy of the waveform before editing, it
is no longer destructive. :-)

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

Heh, heh. Is that women's mud wrestling?

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

Nama's track caching is not realtime. However since there
is no audio output, it generally takes only a fraction
of the actual audio duration.

That would be a simple-minded solution to get a revised waveform
output after a change in effect parameters

If that function ran in a separate process, the interruption
to the user would be less. However one would have to ask
who is willing to write and debug the code to do this. :-)

And why do you need to see what reverb, for example, does
to the waveform? Or volume? I guess looking for overs...
although you won't lose much if sound levels are okay
and you have a limiter at the end of your mastering effects chain.

Perhaps Lauecasound will turn out to be the best environment
for implementing such a feature.

> > > ....Most [Ecasound] 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?

I use the Linux high-resolution kernel timer and an event
framework the lets me schedule timer events. The timer event
triggers a callback that updates the effect parameter, and
Viola! envelope control without using Ecasound's envelope
functions. I do have some question about the accuracy of
this approach, for example, whether indeterminate behavior
occurs if another process has the CPU when the timer reaches
the trigger point.

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

Great to hear that. I was wondering when you said that
Traverso is subject to crashing.
 
> > 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 :)

It's been great to discuss features and implementation
details with him.
 
If I can see a reasonable way forward, my curiosity often
leads me to take the next few steps. :-)

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

Okay, I'll leave the GUI development to you. If it comes out
looking nice, perhaps I can steal it for Nama.

Nama's GUI is ugly, but at least there are hardly any
pop-ups. Just two panes.

> 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

A three-step process to input, verify and execute might help
with this.

> b) holding control responses and production audio apart

Can you explain what you mean in a bit more detail?

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

<snip>

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

I'd like to try playing with it sometime.

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