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

From: Philipp Überbacher <hollunder@email-addr-hidden>
Date: Mon Jul 19 2010 - 16:14:42 EEST

Excerpts from Joel Roth's message of 2010-07-19 13:39:29 +0200:
> 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. :-)

Uhm, well, yes. Having offline editing available would certainly be a
nice addition for any DAW. Basically just something like pass the file
to something external, edit, and re-integrate it. Well, someday :)

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

I don't think so, women's mud wrestling would probably be more
interesting.

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

So it's faster than realtime, which is good :)
Do understand it correctly that you use the same ecasound chain setup
but with file instead of audio output?

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

Yep, probably not optimal. Applying effect + write new file + create
peakfile only to update a single parameter that changed slightly sounds
like huge overkill.

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

I'm in the fortunate position to have no experience with threads
whatsoever, so this thought doesn't trouble me at all :)

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

Yes, looking for clipping would be an obvious application. I plan to
first concentrate on jack, which means 32bit float. I heard that
clipping isn't possible there, but I must admit that I don't fully
understand it.

I talked to Remon about it, and T does reflect only gain changes in the
waveform view (gain, gain curves, fades). It looks really nice in T.
I briefly tried to figure out how A does it. It seems it doesn't
even reflect that much, no gain curves, no fades, to track gain change,
only clip normalization. I don't know what happened to the crossfades,
they used to appear automatically but I couldn't find them anymore, so
no idea what happens there.

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

Don't remind me that I need to find a name at some point :)
I think the simplest form, the way A does it, is enough for most cases.
It can become surprisingly complicated, especially when you want fancy
stuff like zoom, proper alignment to a timeline and reflection of
effects. At some point I want at least a simple, static waveform for
orientation purposes.

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

I know nothing about timers, but using an external one does sound
suboptimal to me. I think I'd want to have the thing sample aligned, but
no idea how to do it and it's far away anyway.

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

It's still a work in progress, but apparently getting there. Remon just
shocked me when he said he plans to release this summer. I want to have
my proof of concept before his next release, so I have little time :)
Git is currently unstable, but with changes to routing and other quite
substantial things it's not surprising.

Here are two screenshots, showing a new feature called 'childview'
(proper name pending), which is simply about showing a subset of tracks.
http://traverso-daw.org/screenies/transport/idea19.png
http://traverso-daw.org/screenies/transport/idea18.png

Other things being worked on, in parallel to the internal routing, is
a track manager to achieve said routing. Here's a preliminary
screenshot: http://traverso-daw.org/screenies/routing/trackmanager.png

Also qwerty control and a sheetview to more easily manage hundreds of
tracks is pretty much finished. I don't want to advertise here, just
want to say that T is promising.

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

Something is different between us here, my curiosity usually only leads
me to the point where I understand it in principle, no further.

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

Big IF. I had a look at juce, which seemed interesting, but after a
closer look and asking Remon for his opinion it seems it has lots of
nice stuff I'll never need due to ecasound. Thanks for hinting me at
IUP, I'll likely try that.

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

That definitely is a good thing, popups are really annoying. It's not
easy to make up a clean interface, not talking about the coding part.

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

Interesting idea. Verify by means of TTS?

> > b) holding control responses and production audio apart
>
> Can you explain what you mean in a bit more detail?

Assuming you get both 'feedback' and 'production' audio the same way,
possibly at the same time, the two might clash. We have only two ears,
and usually use them together (maybe there's a hint here?). I
can imagine that you might have a hard time hearing the 'feedback' while
the music is playing, or vice versa. It might be even hard to say what
is more important at any given time.
The problem comes down to using the ears for two things at the same time.
It probably can be done cleverly, there are a few things I can imagine
to workaround the problem, but I don't see an obvious best solution.

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

Hey, I happen to know someone who writes an ecasound frontend in lua,
maybe that's a chance to look into it ;)

-- 
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
Received on Mon Jul 19 20:15:02 2010

This archive was generated by hypermail 2.1.8 : Mon Jul 19 2010 - 20:15:03 EEST