On Mon, 27 Nov 2006, Stefan Westerfeld wrote:
> On Sat, Nov 25, 2006 at 05:48:51PM +0100, Tim Janik wrote:
>> On Mon, 6 Nov 2006, Stefan Westerfeld wrote:
>>> + * state which means that the value of one input sample affects not only
>>> one
>>> + * output sample, but some samples before and some samples after the
>>
>> s/and/or/ (since that depends on the filter type)
>
> Writing "or" could mean that either some samples before or some samples
> after the corresponding sample are affected, but not both.
nope, in natural language, "or" can mean exclusive or and non-exclusive or,
but i'm still fine with your new wording.
>>> + * "corresponding" output sample.
>>> + *
>>> + * Often the state is symmetric, so that the number of output samples
>>> affected
>>> + * before and after the "corresponding" output sample is the same. Then
>>> the
>>> + * function returns this number. If the state is asymmetric, this function
>>> + * shall return the maximum of the two numbers.
>>> + *
>>> + * If multiple data handles are cascaded (for instance when resampling a
>>
>> hm, "cascaded"? i'd rather say "nested" (or "chained") here.
>
> Ok: I'll use cascaded.
i don't think "cascaded" is accurate here. cascaded handles could mean
using handles in parallel (e.g. you could line up 6 handles in a specifically
ordered cascade to produce a 5.1 dolby handle ;)
only "nested" and to some extend "chained" carry across the sequential
ordering of the handles.
>>> Index: bse/bsedatahandle-resample.cc
>>> ===================================================================
>>> --- bse/bsedatahandle-resample.cc (revision 4068)
>>> +++ bse/bsedatahandle-resample.cc (working copy)
>>> @@ -136,7 +136,7 @@ protected:
>>> }
>>>
>>> /* implemented by upsampling and downsampling datahandle */
>>> - virtual BseResampler2Mode mode () = 0;
>>> + virtual BseResampler2Mode mode () const = 0;
>>> virtual int64 read_frame (int64 frame) = 0;
>>>
>>> public:
>>> @@ -222,18 +222,38 @@ public:
>>>
>>> return n_values;
>>> }
>>> + GslDataHandle*
>>> + get_source() const
>>> + {
>>> + return gsl_data_handle_get_source (m_src_handle);
>>> + }
>>> + int64
>>> + get_state_length() const
>>> + {
>>> + int64 source_state_length = gsl_data_handle_get_state_length
>>> (m_src_handle);
>>> + if (source_state_length < 0)
>>> + return source_state_length;
>>
>> huh? why should a datahandle every return a negative state?
>
> Well, I thought of that line as a similar error propagation as I do in
> read - that is, if the source handle does something strange, I pass it
> on.
>
> What if the source handle had infinite state (like an IIR filter)?
then we return that, the best approximation would be G_MAXINT64.
> But I
> can also simplify it to a g_return_if_fail(), for as long as there are
> no datahandles with non-finite state or othor "errors".
as i said previously, there's no "error" handling defined for this function.
> Here is the new patch:
just pasting the changed portions would have been enough, it's not like the
patch needed a major overhaul here. provided the above stuff is fixed it
should be ready to go in i think.
> Cu... Stefan
---
ciaoTJ
_______________________________________________
beast mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/beast
