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

[Remon]

Hi Nicola,

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

Thats precisely the point I made lol.
So, if you don't have high end gear, and will only be capable of 16 bit 
recordings, it indeed is a waste of hard disk space to save in 32 bit float 
format.

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

Just to make sure, we're talking here about the audio file format used for 
recorded material, and is somewhat an 'internal' thing only.
You're not gonna dig into the /projectpat/audiosources/ dir to find some 
audiofile, and play that with some other application, or send it to someone 
else, would you ?

So, applications should be able to read audio files in 32 bit float, that's no 
big deal, but imo one should use the export ability of Traverso, and there 
you can set bit depth, samplerate, and file type, with the option to render 
to flac too, and hurray, nobody thinks you have a 24 bit resolution audio 
files which in reality only is 16 bit :-)


Using the float format by default has some advantages though:
The resolution is only 24 bit, and many cards support 24 bit recording.
If you record from some other source, or the input signal has been modified 
somehwere else, or in the application, you don't have to worry about 
clipping, it's perfectly save to store a signal > 0 dB.
When Traverso defaults to look at what the audiocard tells, and one starts 
recording some audio stream out of jackd which has some overload, storing to 
16 bits will give lot's of clipping, whereas in other applications, it 'just 
works'.

Oh well, perhaps I'm talking utter nonsense, but a 'use this file format for 
recorded material when creating a new Project', and an overload option for 
existing projects gives enough flexability for everyone ?

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

Yes.


> we could add a combo 
> box offering:
> - use hardware setting
> - use 16 bit always
> - use 24 bit always
> - use 32 bit float always

Ah yeah, should have read a bit more first :-)

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


The only thing that will happen is that an audio file will be played with the 
wrong samplerate, so if you like fancy effects.... :-P

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

Indeed.

<bus enumarating/selection section snip >

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

Absolutely, very important indeed, couldn't agree more, and so on ...


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

OK, good. Since they operate all on Tracks (they do, right ?), it's a perfect 
candidate for a single Command class, hmm...
(this way we have nice code re-use, and it forces equal behavior for these 
actions, which is good I think)

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

Ah, it's in the trackpanel, Capture Bus 1, Capture Bus 2, and so on.
There has been a L / R added to it to indicate which channels were in use (not 
visible right now), but perhaps a Cap. Bus 1 (1/2), Cap. Bus 1 (1), Cap. Bus 
2 (3/4), Cap. Bus 2 (4) etc will be better ?


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

Sure, that would at least be the start point to begin with, anyone feeling 
lucky ? ;-P

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

You do, really ? (hmm, it's not small stuff, it's 'a major feature request 
every day, lol)


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

Wouldn't it be better to just keep < SPACE > to "start/stop transport", and 
use the < K > key to toggle recording mode on/off ?

A recording mode would indeed be handy, if you just want to listen to whatever 
you recorded, you don't have to unarm your tracks first, makes a lot of sense 
indeed, or as you mention to implement overdubbing, start at marker etc.

However, it should be _very_ clear, I mean, extremely very clear that you have 
to _explicitely_ set traverso in recording mode to start recording on armed 
tracks !!!!!!!

Don't know how yet, maybe some huge picture at the center of the screen 
screaming it in your face or something hehe.

Or  a HUGE BUTTON in the to be made song info widget: "SWITCH TO RECORDING 
MODE", something like that...

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

I love screenshots :-)


Greetz,

Remon