traverso-devel
[Top][All Lists]
Advanced

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

Re: [Traverso-devel] Some confirmations for the manual


From: Remon
Subject: Re: [Traverso-devel] Some confirmations for the manual
Date: Sat, 10 Feb 2007 23:06:01 +0100
User-agent: KMail/1.9.6

Hi Nic,


> I'm about to write the "recording" chapter for the manual, and I would like
> you (mainly Remon) to clarify some points:

Kewl.


> - I assume that the recording format (sampling rate, bit depth) is given by
> the audio backend. If that is correct, I would suggest in the manual that
> users who need a different format than the default ALSA settings should use
> qjackctl and set the sample rate and bit depth there.

If I'm not mistaken, when one creates a project, you set the sample rate, and 
_that_ will be the sample rate for the whole project, so it's a fixed value.
Currently, when creating a project in Traverso it looks at the current rate 
value of the audiobackend.

Changing the samplerate from the alsa driver is really simple, you can use the 
quickdriver config widget, or go to the settings page, which shows 
essentially the same.

When u use jackd, you indeed have to use qjackctl to set the samplerate.

Setting the bitdepth doesn't make sense, we use 32 bit float everywhere, 
conversion to the bitdepth supported by your sound card is done 
automatically, so the bit depth is fully transparent throughout the 
application.

Saving is done to 32 bit float by default as well, but there's nothing against 
using another bitdepth to save too, in case you are out of hard disk space, 
and the recording quality doesn't matter all that much......

I would suggest that at this moment we don't look at how it is currently in 
traverso, but how we WOULD LIKE IT TO HAVE!
Changing the file save format, or setting a sample rate to be used in a 
project are rather one liners, and a feature that is basic enough imo that it 
should be available and work for the next release.
RFC please!

> - What happens if I mix clips with different file formats (sr, bit depth)
> in one song? Is it possible?

Bit depth is no issue, but as explained above, projects only support a fixed 
sample rate, no conversion takes place.
Since I'm in the very nice position to change things to my own hearts feelings 
and wishes and yadayada, it's something that would be nice, I mean, importing 
an audiofile that's sampled at 48 KHz, in a project with sample rate 44.1 
KHz.

If this as a matter of fact would be very hard to implement, or very cpu 
costly, it's no big deal to pipe the file through sox or some other lib 
(libsrc e.g.) to convert the file to the correct format, and use that 
instead....

> - On cheap soundblaster or onboard sound cards switching between line-in
> and mic input is done either in KMix (or alsamixer), or in qjackctl. Is
> that correct? 

No idea really, never tried it lol

> Better sound cards seem to be able to record from several 
> input channels with ALSA and jack. In that case, assigning a capture bus in
> Traverso allows to record these channels. Is that how it is done correctly?
> (I don't have a multichannel card, so I don't know.)

Indeed, when you open the menu to assign a capture bus to a track, it shows 
all the available hardware capture buses!

> - I saw that there are key commands for recording the left or right channel
> only, or both (<J K> <K L> <J L>). Is it working already? Does it
> automatically create a mono clip if only one side is recorded? 

It worked before, but doesn't work at the moment. Channel count is handled 
transparantly, so if you have a hardware bus with 3 channels (do they 
exist?), you create a clip with 3 channels hehe.
If only the left or right channel is selected, a mono clip will be created.
Well, that's how it is supposed to be. It in fact should work, the only 
problem is that right now you can't set a tracks recording state to only left 
or only right channel....

However, since I only know about stereo hardware buses with a left and right 
bus, it would be great to select a capture bus which by default uses both 
channels, and, on request only uses the left or right channel.

Using a key action for this seems a bit overkill, though it doesn't hurt 
either to have those available.
They currently don't work btw.

So this actually is another RFC, does anyone have a simple and solid idea how 
to select a capture bus, and selecting only the right/left channel of it ?

One feature comes in mind, Nicola, you sugested to use [ O ] and move mouse 
up/down to mass solo/unsolo a bunch of tracks.
The same could be used with [ A ].....

> Is there any 
> visual feedback showing which channel is recorded?

You mean real time audioclip waveform drawing?
Right now, nope.
Main problem is this:
Painting the waveform during record isn't very hard, easy to do. But what if 
the user wants to zoom?
We don't have all the zooming peak data yet, only the first and very low zoom 
level (1/64 iirc). It means if you go to a much higher zoomlevel, it takes 
considerable amount of processing power to generate those on the fly, well, 
not really, but say when you record on a number of tracks at the same time, 
it's a bit of an issue.

So what I need to know: Is zooming allowed during record, between which 
levels, which minimum level to use during record, should scrolling the view 
be supported, and so on.
Depending on these 'needs', I'll try to figure out which solution to generate 
the peak data for recorded material is the most sufficient.
Most likely a seperate thread to offload the waveform data creation for 
recording stuff, which is used by the painting routine, could in fact be 
relatively easy.....

> - Anything else I should add to the chapter?

Yeah, I think a certain set of actions should be disabled during record, like 
setting the workcursor to another location, the recording starts from the 
work cursor position.
So thats something we could point to the user too, hmm, can't think of any 
more right now.


> Thanks for your help.

Always a pleasure,


Remon






reply via email to

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