[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Traverso-devel] Some confirmations for the manual
From: |
Nicola Doebelin |
Subject: |
Re: [Traverso-devel] Some confirmations for the manual |
Date: |
Sun, 11 Feb 2007 09:28:10 +0100 |
User-agent: |
KMail/1.9.3 |
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
- [Traverso-devel] Some confirmations for the manual, Nicola Doebelin, 2007/02/10
- Re: [Traverso-devel] Some confirmations for the manual, Remon, 2007/02/10
- Re: [Traverso-devel] Some confirmations for the manual, Niklas Klügel, 2007/02/10
- Re: [Traverso-devel] Some confirmations for the manual,
Nicola Doebelin <=
- Re: [Traverso-devel] Some confirmations for the manual, Remon, 2007/02/12
- Re: [Traverso-devel] Some confirmations for the manual, Nicola Döbelin, 2007/02/12
- Re: [Traverso-devel] Some confirmations for the manual, Remon, 2007/02/12
- Re: [Traverso-devel] Some confirmations for the manual, Nicola Doebelin, 2007/02/12
- Re: [Traverso-devel] Some confirmations for the manual, Remon, 2007/02/12
- Re: [Traverso-devel] Some confirmations for the manual, Nicola Doebelin, 2007/02/12
- Re: [Traverso-devel] Some confirmations for the manual, Remon, 2007/02/12
- Re: [Traverso-devel] Some confirmations for the manual, Ingmar Vanhassel, 2007/02/12
- Re: [Traverso-devel] Some confirmations for the manual, Remon, 2007/02/12
- Re: [Traverso-devel] Some confirmations for the manual, Nicola Döbelin, 2007/02/13