traverso-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Traverso-devel] Some remarks / missing features


From: Nicola Doebelin
Subject: Re: [Traverso-devel] Some remarks / missing features
Date: Mon, 11 Sep 2006 21:54:36 +0200
User-agent: KMail/1.9.3

Hi Remon,

> > 1. Monitoring: As soon as a track is armed for recording, the channel
> > should be 'opened', that means the audio stream should be piped through
> > the channel (including all plugins etc.), but just not recorded to disk.
> > The VU metre should be active in order to show that a signal is coming
> > in, and to allow to set the levels correctly. (...)

> I'm not sure if I follow you here.
> To be able to have continues monitoring on a Capture Bus seems like a good
> idea, but monitoring at the end of the processing chain?
> I had the impression that Captured Audio generally is stored on hard disk
> directly, without any modifications ?

I might be wrong, but what I had in mind is the following:

When recording, the signal path is:
  input channel -----> wave file

When playing back, the signal path is:
  wave file -----> processing (plugins etc.) -----> output channel

When monitoring is active, the wave file part is skipped:
  input channel -----> processing -----> output channel

But now that I think about it again, your solution is probably better. After 
all it's the input signal that is of interest when setting up a recording 
session, not the processed signal.

> As for monitoring the Capture Buses continuously, this is implemented at
> the moment, but with a lot of Capture VU meters, it consumes some CPU
> power, so it makes sense to turn it on/off by hand, or only turn it on if a
> Track is armed?

I would definitely turn it on for armed tracks only. VU meters of disarmed 
tracks should only show the playback signal, even if something is connected 
to the input channel.

> > 1.1 Playback / Record: I think we should distinguish between playing back
> > and recording. In playback mode all tracks are played back, regardless of
> > whether they are armed or not. In recording mode armed tracks should
> > record and disarmed tracks should play back as usual. This will allow to
> > implement 'overdubbing' funcionality with 'punch-in' and 'punch-out'
> > markers easily. If someone is not familiar with these features, let me
> > know and I will elaborate on it.
>
> Heh, I'm indeed a bit clueless on the punch-in and punch-out in combination
> with the proposal
> But I suppose it's a nice feature to playback some recorded material
> without the need to disarm all the tracks.
> I guess that kinda relates to the 'overdubbing' feature?

Ok, I'll try to explain it...

Let's suppose you recorded an almost perfect vocal track, with only one 
glitch. You wouldn't want to re-record the entire track but only the 
incorrect part. You could mark this region by setting a punch-in marker at 
the beginning, and a punch-out marker at the end. Then you arm the vocal 
track and start recording some time before the marked region, e.g. at the 
beginning of the verse or chorus. Even the armed track is played back at that 
time, but as soon as the punch-in marker is reached, the armed track switches 
from playback to record, until the the punch-out marker is reached. The 
singer sings along the whole time, even when he is not actually recorded. 
This ensures that the re-recorded part fits into the existing part as far as 
melody and flow of words is concerned.

This sort of simulates the technique used with tape machines and stand-alone 
HD recorders. Instead of markers, the operator started playback before the 
faulty region, and pressed the record button just before the error to switch 
all armed tracks from playback to record mode.

> > 2. It would probably be a good thing to have a VU meter on each track.
> > (...)
> 
> Well, it's quite possible right now, or at least with minor code additions.
> The layout should have to be horizontal though, what do you think?

Horizontal layout shouldn't be a problem, but VU meters for 
tracks/subgroups/auxes would introduce a lot of redundancy. E.g. if track 1 
is connected to input channel 1, both VU meters will show the same signal 
while monitoring. On the other hand, I would prefer to have VU meters for 
tracks/subs/auxes rather than for hardware channels, because, as I mentioned 
before, they are handy to follow the signal path.

How about showing the *track* VU meters in the existing VU meter widget, and 
moving the hardware VU meters to a separate dialog which is by default 
hidden? Do you think it is a problem if the meters are not embedded in the 
track itself? It's not as easy to find the meter corresponding to a 
particular track, but if they are labelled it should be ok. FWIW there are 
hardware mixers which don't have the VU meters exactly above the channel 
strips as well [1].

> > 3. According to [...] almost all swh-plugins are ported to LV2! Very nice!
>
> Yeah, but I can't find them, and no-one knows where to find them, so it's
> only theory by now.
> Would be nice to start testing those plugins, so the plugin infrastructure
> can be improved!

Did you contact the developer? I would be surprised if he was not willing to 
send you a snapshot, even if the plugins are not yet stable enough for a 
release.

Best regards,
Nic

[1] http://www.lydrommet.no/aim/uploaded/28636__SOU_SM20.jpg




reply via email to

[Prev in Thread] Current Thread [Next in Thread]