[Clam-devel] AudioFileMemoryLoader patch

David García Garzón dgarcia at iua.upf.edu
Tue Jun 10 05:00:57 PDT 2008


Both commited. :-) waiting for the next one :-)


El Tuesday 10 June 2008 12:40:32 Pawel Bartkiewicz va escriure:
> Hi,
>
> On 10/06/2008, David García Garzón <dgarcia at iua.upf.edu> wrote:
> > I just commited it. r11459. Thanks
>
> Thanks.
>
> > Anyway don't stop waiting for a commit on our part. Just send the patch
> > and continue with the next. We may get conflicts in this way but we are
> > slow on commiting and waiting for us would delay you a lot.
>
> I'm doing that, but preparing patches compatible with SVN for files
> not in SVN by hand is a bit messy. Does anyone have some script for
> this?
>
> > * The naming conventions we are introducing in new classes for members
> > are _lowerCase, not _UpperCase.
>
> Sorry, I just replaced 'm' with '_' and forgot about it. I'll correct
> this in another patch if you don't mind.
>
> > * As those check are already done in the inner processing you don't need
> > to check for empty filename and so on. Let the inner one complain.
> >
> > * I guess that the next step is to take the configuration error from the
> > inner
> > processing. In such a case don't let the user know about having an inner
> > processing, no "Internal MonoAudioFileReader configuration error", just
> > the one taken from MAFRConfig error as is.
>
> Done in the patch I'm sending right now
> (AudioFileMemoryLoader-error_handling.patch). The other patch
> (AudioFileMemoryLoader-samples_output.patch) adds a position variable
> and outputs the samples (sorry for two things in one patch but
> separating them seemed strange). I've tested it with an AudioSink and
> Oscilloscope and it works fine.
>
> > Keep the nice patches flowing. :-)
>
> The next things to do:
> - replacing _UpperCase with _lowerCase in member names
> - writing the position to the OutControl and testing it with
> OutControlPrinter - adding an InControl for the position (not sure how to
> test it yet)
>
> By the way, is it ok that we use Controls for position instead of
> Ports? It should be fine for the chord extractor application but it
> makes reversing samples and changing the speed impossible, for example
> (because that would require per-sample accuracy). However, it's just a
> hack, so maybe that's no problem.
>
> Pawel






More information about the clam-devel mailing list