[Clam-devel] very basic processings examples / no time-domain audio gain in NE?

[David García Garzón]

On Monday 19 November 2007 15:43:58 Hernán Ordiales wrote:
> On 11/19/07, David García Garzón <dgarcia at iua.upf.edu> wrote:
> > On Diumenge 18 Novembre 2007, Hernán Ordiales wrote:
>
> [snip]
>
> > > i know that already exists this guide:
> > > http://clam.iua.upf.edu/wikis/clam/index.php/Creating_a_minimal_process
> > >ing_ object but maybe is also useful to add it in some place as basic
> > > reference...
> >
> > When creating the tutorial pages of the wiki we intended to split the
> > former simple but full example (ports+controls+config) into aspects just
> > because the tendency of users is to copy and paste examples that leads
> > into having complex processings even when it was not needed. CLAM is full
> > of empty configuration objects, meaningless controls just in case and
> > code with empty implementation of deprecated optional virtual functions
> > such SetPrototypes and the like just because the first examples defined
> > every single redefinable function. Anyway, maybe we moved too far. It
> > could be worth to add such complete example with ports and controls. If
> > you feel so, just add it to the wiki. I would rather like to have
> > exemplifiable code on CLAM: too much of the code doesn't follow current
> > guidelines of coding processing but old ones ;-)
> >
> > Something i would like to do is adding to the wiki a 'Further reading'
> > section to connect, for example, the the basic example to the one of the
> > controls and the one of the configurations. I just added one to the
> > simple processing one.
>
> nice
>
> > > if you want, you can suggest changes here, making something like a
> > > diff (only make changes and post):
> > > BaseProcessing.hxx: http://clam.pastebin.com/f6dad9724
> > > BaseProcessing.cxx: http://clam.pastebin.com/f13032ff1
> > > (commented code is to easily convert it in a processing with a
> > > configuration)
> >
> > We consider having commented out code a bad practice. If any example a
> > new user does starts with commented out code that's bad.
>
> i know, i made it in that way to have in the same file a simple start
> point for a basic processing with configuration (the commented code)
> or not
> own use purposes, not to commit or show in that way in the wiki or
> elsewhere
>
> > Also, the commented out code refers to the NullProcessingConfig. I would
> > not even mention it. If you need NullProcessingConfig you don't need any
> > Config.
>
> then i have a question: if i don't do it in that way (removing all the
> config code regarding NullProcessingConfig) i get a "red processing"
> in NE until i configure it pressing "Configure" at the context menu of
> the processing and pressing ok to enable it.

Maybe because this:
                BaseProcessing()
                        :
                        mInputAudio("Input Audio",this ),
                        mOutputAudio("Audio Output",this),
 
                        mInputControl("Control", this)
                {
                        Configure( mConfig );
                }

Should be:

                BaseProcessing(ProcessingConfig & config=Config())
                        :
                        mInputAudio("Input Audio",this ),
                        mOutputAudio("Audio Output",this),
                         mInputControl("Control", this)
                {
                        Configure( config );
                }
Try it out.


> > > As a next basic example i thought in an audio linear amplifier... was
> > > weird to me but i could not find a basic time-domain audio gain in
> > > networkeditor's processings (exists?), so i made one by my own...
> > >
> > > AudioGain.hxx: http://clam.pastebin.com/f78113b36
> > > AudioGain.cxx: http://clam.pastebin.com/f1643ef69
> > >
> > > should i commit this one? or there is an special reason to not have a
> > > time-domain amplifier?
> >
> > An AudioAmplifier It would be a nice addition. Some months ago I wondered
> > the same question, until i realized you can use the AudioMixer with a
> > single channel whenever we want to amplify something,
>
> btw, how this would work? i can only see one audio output in that
> processing

Yes, you should configure the number of channels which is default to 0. Maybe 
the default should be 2, feel free to change it. You get as many inports and 
gain controls as channels. If you configure it to 1 you have a nice 
amplifier.

> > but i it would be good to add
> > an specific processing, just to be findable. Usability and not processing
> > types economy should be the rule.
> >
> > We could also say that there are a lot of ladspa plugins for that, but
> > you are right, looking for an amplifier example is a typical way to start
> > learning a processing framework. Adding such processing without the fuzz
> > of old processings as example to look at is a nice thing ;-)
>
> can you point me (or remove and post there) old guidelines code here?:

The guidelines are engraved into a lot of legacy code within CLAM. The options 
were reading a 400 pages documentation which were also out of date or cutting 
and paste an existing class and changing the relevant parts. Of course most 
developers choose the later. So, the direct consequence is what i said. Old 
fashioned coding practices propagated more that new ones. And that's why we 
did the wiki documentation, which is task oriented. Anyway people still will 
cut and paste code, so that's why we need examples which use the new 
processing coding style.

> > > AudioGain.hxx: http://clam.pastebin. com/f78113b36
> > > AudioGain.cxx: http://clam.pastebin.com/f1643ef69
>
> On 11/19/07, Xavier Amatriain <xavier at amatriain.net> wrote:
> [snip]
>
> > There is a time-domain gain implemented in a sample by sample manner in
> > the SampleBySample collection in the NetworkEditor Processing collection.
>
> at first i tried with that but is not working at least with a common
> audio input, i'm getting this backtrace:
>
> http://clam.pastebin.com/m4291743e
>
> for a minute i thought was for another thing, but now you confirmed it
>
> btw, i did a quick check in the code, seems like a expression
> templates schema, don't?
>
> > However this is probably not general purpose enough to replace what
> > hordia is proposing. I agree this would be an interesting addition.
> > Actually I think that
> > there should be far many more time-domain processing classes, be it in a
> > sample by sample or block processing manner.
>
> On 11/19/07, David García Garzón <dgarcia at iua.upf.edu> wrote:
> > I definitely should take a look at the sample by sample way. We started,
> > within the 3d acoustic part to do consider diferent processings for
> > streaming audio and buffered audio so we could end up with 3 repeated
> > processings. Ok, review them into my spare-time to-do's.
>
> ok, then just let me know if i have to commit something...

Just commit the AudioAmplifier into er... src/Processing/AritOps?

> if sample by sample is working, is ok for me (i'll try to review it deeper
> then)

It is not a implementation review but a review on the decision of making three 
different Audio data types which i consider complex but maybe it is a need.

> i like the idea of my audio amplifier as first approach in time-domain
> processings because it has a very simple code (sample by sample code
> could be a little complex to start with)

I agree. An audio stream (AudioInPort) it would be ok. Let the audio buffer 
(InPort<Audio>) for the 3d plugin by now.

David.