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

[Nicola Doebelin]

Hi Remon,

Am Samstag, 10. Februar 2007 23:06 schrieb Remon:
> 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!

I think the audio data should be saved in the format supported by the audio 
card for several reasons:

- saving disk space: If the sound card only supports 16 bit, saving in 32 bit 
is a huge waste of disk space. When backing up a long multitrack recording 
(think of live concerts > 1 hour), having to cope with twice the file size 
can be a serious problem.

- other applications: Are all sound applications capable of playing back 32 
bit files if the hardware only supports 16 bit? Is the dithering done by the 
audio backend?

- the psychologic effect: Sounds trivial, but if someone gives me an audio 
file with 24 or 32 bit resolution, I assume it has enough headroom and a huge 
dynamic range, so no problem if I boost very low volumes hard. But if the 
resolution of the converters actually was 16 bit, I would get pretty poor 
quality nonetheless.

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

Great! I'm in favour of an option in the config file for now. In the 
re-designed config dialog (that's the plan, right?) we could add a combo box 
offering:
- use hardware setting
- use 16 bit always
- use 24 bit always
- use 32 bit float always

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

So for now a big "Nonono!!!" in the manual should do.

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

The idea sounds nice. If the sample rate is different from the projects sample 
rate, show a dialog offering to create a copy with the correct sr, or abort 
the import.

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

Yes, this is rather important. When working with microphones, e.g. two 
singers, I need one mono track for each. If they were recorded into one 
stereo track, one of the left, the other right, splitting them into mono 
tracks would mean a lot of extra work.

The question Niklas came up with in the other mail is if we should label the 
channels 1-left, 1-right, 2-left, 2-right, or rather 1, 2, 3, 4. Well, I'm 
not sure, both schemes have their advantages and disadvantages, depending on 
whether the users mainly works with stereo or mono sources. Maybe 

1 left (1)
1 right (2)
2 left (3)
2 right (4)

would be a solution?

> Using a key action for this seems a bit overkill, though it doesn't hurt

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

A fundamental question, actually. In my opinion configuration related actions 
such as the one discussed above should be done in dialogs, either using the 
mouse or soft selection, depending on what suits better. Let me explain why I 
come up with that again, after we decided to get rid of the fade dialog. I 
think we should distinguish between edit actions, which should always work 
with key actions in the song view, and configuration stuff, which could 
easily be hidden in a config dialog. The fade dialog was "accidentally" 
implemented as a config option, although it obviously is an edit action. It 
is something that is changed all the time during mixing. Input channel 
assignments, OTOH, are usually done once per track, and not changed 
afterwards. So we'd better save the key actions for more important stuff.

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

Absolutely, and <<A>> should work the same way as <<O>> and <<U>>. It's 
extremely intuitive.

> > Is there any
> > visual feedback showing which channel is recorded?
>
> You mean real time audioclip waveform drawing?

No, actually I wanted to know if there is a label somewhere saying "capture 
bus 1 (left channel)", "... (right channel)", or "... (stereo)", to inform me 
about which channel is recorded.

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

How about drawing the bounding rect of the clip in the correct size during 
recording, and calculate the wave forms as soon as recording is stopped? Any 
kind of feedback that the recording is working would be sufficient for now, 
IMO.

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

Something I wanted to suggest again (but later, since I bothered you with lots 
of small stuff lately):

Even if some tracks are armed for recording, we need to distinguish a playback 
mode and a recording mode. We will need this later on anyway, as soon as 
overdubs are implemented (Niklas has a few comments on this in the other 
mail, too). What I have in mind is:

- If tracks are armed, <SPACE> starts playback and ignores armed tracks. They 
are played back just as if they were disarmed.
- <CTRL SPACE> would start recording armed tracks, just as <SPACE> does in the 
current version.
- It should be possible to toggle between playback and recording during 
operation. E.g. start playback with <SPACE> and have some tracks armed. Then, 
as soon as a critical position is reached, hit some key <K> to switch to 
recording mode, and hit <K> again to switch back to playback mode. Later on 
this should also be possible with setting markers in the timeline, to allow 
precise punch-in and punch-out recording. This technique (manually and with 
markers) is used to fix wrong parts in a recording by only re-recording the 
faulty part.

If you want me to elaborate on that (with the aid of some screenshots from 
samplitude), I'd be happy to do so.

Have a nice sunday.
Nic