Help

On Jul 7, 2013 3:00 PM, <[email protected]> wrote:

> Send Ardour-Dev mailing list submissions to
>         [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org
> or, via email, send a message with subject or body 'help' to
>         [email protected]
>
> You can reach the person managing the list at
>         [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ardour-Dev digest..."
>
> Today's Topics:
>
>    1. Re: Fwd: [Ardour-Cvs] Ardour source branch meterbridge
>       updated. 3.2-153-gf885622 (J?rn Nettingsmeier)
>    2. Re: Fwd: [Ardour-Cvs] Ardour source branch meterbridge
>       updated. 3.2-153-gf885622 (Axel 'the C.L.A.'
> =?UTF-8?B?TcO8bGxlcg==?=)
>    3. Re: Fwd: [Ardour-Cvs] Ardour source branch meterbridge
>       updated. 3.2-153-gf885622 (Robin Gareus)
>    4. Re: Fwd: [Ardour-Cvs] Ardour source branch meterbridge
>       updated. 3.2-153-gf885622 (Thomas Vecchione)
>    5. Re: Fwd: [Ardour-Cvs] Ardour source branch meterbridge
>       updated. 3.2-153-gf885622 (J?rn Nettingsmeier)
>
>
> ---------- Forwarded message ----------
> From: "Jörn Nettingsmeier" <[email protected]>
> To: Robin Gareus <[email protected]>
> Cc: ardour Development List <[email protected]>
> Date: Sat, 06 Jul 2013 22:48:48 +0200
> Subject: Re: [Ardour-Dev] Fwd: [Ardour-Cvs] Ardour source branch
> meterbridge updated. 3.2-153-gf885622
> On 07/06/2013 08:34 PM, Robin Gareus wrote:
>
>> On 07/06/2013 06:27 PM, Jörn Nettingsmeier wrote:
>>
>>> hi robin, i'm not currently tracking the meterbridge branch, so i may be
>>> talking nonsense, but here goes:
>>> peaking should be defined as a configurable number of samples at full
>>> scale (or equal to or greater than 1.0f, in the case of floats) , not
>>> some arbitary level.
>>>
>>
>>
>> Hi Jörn,
>>
>> Do you have a reference for this *should be* defined as? I don't think
>> that makes much sense.
>>
>> Actually it's rather the other way 'round. Since the digital signal is
>> band-limited there can be peaks in the audio even if the digital samples
>> are not exceeding 0dbFS [1].
>>
>
> maybe i misunderstood the purpose of this code snippet (like i said, i
> don't know the context). if this is about a peak hold feature, ignore me.
> if it's about peaking in the sense of "clipping", bear with me.
>
> within a digital audio system based on floats, i don't have to care about
> peaks at all. only at the last step before going back to fixed-point or
> analog do i have to adjust.
>
> so all i want to see from a peak indicator is "has my data been clipped at
> some earlier point in the chain?". i don't really care about inter-sample
> peaks at this stage.
>
> fwiw, the current implementation in ardour is not foolproof either:
> when i overload my micstasies, the peak indicator will show 0.0dB but not
> turn red, so i've learned to look for the numbers rather than the color. of
> course, it could also be that the preamp does not ever deliver fullscale
> for some reason...
>
>  Either way this is not relevant yet. The meterbridge branch (which will
>> be merged back to master soonish) is currently mostly concerned with GUI
>> - not the actual calculations.
>>
>
> i see.
>
>  NTL, the level-metering in ardour will see a major rework in the not to
>> distant future - and doing that needs a rethink.
>>
>> Your suggested approach has one major downside though: it cannot be
>> efficiently accelerated with SSE2 (thanks to Sampo, the current
>> max-peak-hold is accelerated).
>>
>> Other level-meters standards/algorithms will have the same issue and
>> because every port in ardour has a peak-meter and you can have thousands
>> of ports this can become a major DSP-load bottleneck.
>>
>
> thousands of ports? never :-D
>
>  Anyway - this needs careful planning.
>>
>> Thanks for kicking off this discussion..
>>
>
> looking forward to this new code!
>
> btw, i should have written to you about it, but i've been using the video
> timeline for a little project last week (usual workflow: video guy decides
> edits and delivers the final video with rudimentary guide track from
> built-in mics). worked like a charm, thanks a lot!
>
> best,
>
>
> jörn
>
>
>
> --
> Jörn Nettingsmeier
> Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
>
> Meister für Veranstaltungstechnik (Bühne/Studio)
> Tonmeister VDT
>
> http://stackingdwarves.net
>
>
>
>
> ---------- Forwarded message ----------
> From: "Axel 'the C.L.A.' Müller" <[email protected]>
> To: [email protected]
> Cc:
> Date: Sun, 7 Jul 2013 00:41:28 +0200
> Subject: Re: [Ardour-Dev] Fwd: [Ardour-Cvs] Ardour source branch
> meterbridge updated. 3.2-153-gf885622
> On Sat, 06 Jul 2013 22:48:48 +0200
> Jörn Nettingsmeier <[email protected]> wrote:
>
> > fwiw, the current implementation in ardour is not foolproof either:
> > when i overload my micstasies, the peak indicator will show 0.0dB but
> > not turn red, so i've learned to look for the numbers rather than the
> > color. of course, it could also be that the preamp does not ever deliver
> > fullscale for some reason...
>
> ...wich is a good reason for having an arbitrary configurable level for
> triggering the clip indicator (during recording) - working around
> hardware limitations (or features), warning if a preferred peak level
> is exceeded, etc...
>
> As allready discussed on IRC it might be useful to have different
> settings for different places in the signal chain - lower/arbitrary
> level for metering input signals ("in" meter point), simple 0 dBFS
> detection on channels and buses when mixing (pre/post meter point),
> oversampled peak meter on the master for capturing inter-sample peaks
> and so on.
>
>
>
>
> ---------- Forwarded message ----------
> From: Robin Gareus <[email protected]>
> To: "Jörn Nettingsmeier" <[email protected]>
> Cc: ardour Development List <[email protected]>
> Date: Sun, 07 Jul 2013 00:48:39 +0200
> Subject: Re: [Ardour-Dev] Fwd: [Ardour-Cvs] Ardour source branch
> meterbridge updated. 3.2-153-gf885622
> On 07/06/2013 10:48 PM, Jörn Nettingsmeier wrote:
> [..]
>
> > within a digital audio system based on floats, i don't have to care
> > about peaks at all.
>
> You will want to know if a signal on the input is clipping.
>
> > only at the last step before going back to
> > fixed-point or analog do i have to adjust.
>
> Yes, that too :)
>
> > so all i want to see from a peak indicator is "has my data been clipped
> > at some earlier point in the chain?". i don't really care about
> > inter-sample peaks at this stage.
> >
> > fwiw, the current implementation in ardour is not foolproof either:
>
> Ow, that's bad.
>
> > when i overload my micstasies, the peak indicator will show 0.0dB but
> > not turn red
>
> It will only turn red when the absolute signal value is >= 1.0.
> (now this value is configurable).
>
> > so i've learned to look for the numbers rather than the
> > color. of course, it could also be that the preamp does not ever deliver
> > fullscale for some reason...
>
> Can it be that the Micstasy uses integer PCM and never produces a peak?
> e.g with 16-bit audio it sends 2^15 -1 rather than 2^15. That rounds to
> -0.0dB but is still less than 1.0 in jack.
>
> >> Either way this is not relevant yet. The meterbridge branch (which will
> >> be merged back to master soonish) is currently mostly concerned with GUI
> >> - not the actual calculations.
> >
> > i see.
>
> It is related, because the peak-display logic is currently implemented
> in the GUI (only level-calculation and peak-hold is done in the
> audio-thread).
>
>
> [..]
> > btw, i should have written to you about it, but i've been using the
> > video timeline for a little project last week (usual workflow: video guy
> > decides edits and delivers the final video with rudimentary guide track
> > from built-in mics).
>
> That's exactly the envisaged work-flow.
>
> > worked like a charm, thanks a lot!
>
> It's great to hear success stories rather than bug-reports for a change.
> Keep them coming!
>
> Cheers!
> robin
>
>
>
> ---------- Forwarded message ----------
> From: Thomas Vecchione <[email protected]>
> To: Robin Gareus <[email protected]>
> Cc: ardour Development List <[email protected]>
> Date: Sat, 6 Jul 2013 22:16:50 -0400
> Subject: Re: [Ardour-Dev] Fwd: [Ardour-Cvs] Ardour source branch
> meterbridge updated. 3.2-153-gf885622
>
>
>
> On Sat, Jul 6, 2013 at 6:48 PM, Robin Gareus <[email protected]> wrote:
>
>> It's great to hear success stories rather than bug-reports for a change.
>> Keep them coming!
>>
>>
> That is Robin's nice way of telling me to shut up and go away! ;)
>
> All that being said, I already did a couple test projects on A3 with
> Robin's vtl with success, so yes there is lots of success to go around:).
> There should be a short trailer hitting in the next week or week and a half
> that I need to start on as well that hopefully i will be able to release
> the session file for as well.  All I can say for that one right now.
>
>         Seablade
>
>
> ---------- Forwarded message ----------
> From: "Jörn Nettingsmeier" <[email protected]>
> To: Robin Gareus <[email protected]>, ardour Development List <
> [email protected]>
> Cc:
> Date: Sun, 07 Jul 2013 13:55:13 +0200
> Subject: Re: [Ardour-Dev] Fwd: [Ardour-Cvs] Ardour source branch
> meterbridge updated. 3.2-153-gf885622
> On 07/07/2013 12:48 AM, Robin Gareus wrote:
>
>> On 07/06/2013 10:48 PM, Jörn Nettingsmeier wrote:
>>
>
>  when i overload my micstasies, the peak indicator will show 0.0dB but
>>> not turn red
>>>
>>
>> It will only turn red when the absolute signal value is >= 1.0.
>> (now this value is configurable).
>>
>>  so i've learned to look for the numbers rather than the
>>> color. of course, it could also be that the preamp does not ever deliver
>>> fullscale for some reason...
>>>
>>
>> Can it be that the Micstasy uses integer PCM and never produces a peak?
>>
>
> of course it uses integers - it's an AD converter.
>
>  e.g with 16-bit audio it sends 2^15 -1 rather than 2^15. That rounds to
>> -0.0dB but is still less than 1.0 in jack.
>>
>
> ah, thanks for the explanation. so the threshold for the red light should
> probably be lowered to "more than N samples >= (float)(2^15 - 1)".
>
>  btw, i should have written to you about it, but i've been using the
>>> video timeline for a little project last week (usual workflow: video guy
>>> decides edits and delivers the final video with rudimentary guide track
>>> from built-in mics).
>>>
>>
>> That's exactly the envisaged work-flow.
>>
>>  worked like a charm, thanks a lot!
>>>
>>
>> It's great to hear success stories rather than bug-reports for a change.
>> Keep them coming!
>>
>
> sure :)
>
>
>
>
> --
> Jörn Nettingsmeier
> Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
>
> Meister für Veranstaltungstechnik (Bühne/Studio)
> Tonmeister VDT
>
> http://stackingdwarves.net
>
>
>
> _______________________________________________
> Ardour-Dev mailing list
> [email protected]
> http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org
>
>

_______________________________________________
ardour-dev mailing list
[email protected]
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org