Version Migration Guide

From Clam

Jump to: navigation, search

This manual chapter gives hints on how to migrate existing code from one version of CLAM to another hihglighting code level incompatibilities and new ways of doing things.

Contents

1.4 to svn

  • DynamicType::MandatoryInit(), which was used to generate DynamicType attribute information, has been removed. A safer solution is implemented now: a required constructor parameter with a built attribute description table. Such table is provided by TypeDescriptionTable() static function generated by DYNAMIC_TYPE macros. As consequence, Dynamic Types with custom constructors and intermediate base classes should be changed.
    • Custom non-copy constructors that ends up calling the base class default constructor should pass as second parameter, the result of TypeDescriptionTable(), a new static function generated by DYNAMIC_TYPE macros that builds the type information, previously done by MandatoryInit. (See Spectrum's extra constructor which receives an SpectrumConfig)
    • Intermediate base clases should propagate such structure from concrete classes to base class (See ProcessingData constructors).
  • TypedInControl and TypedOutControl are now obsolete. In previous version, they were a deprecated alias for InControl and OutControl, now removed.
  • Storable and XMLable now are colapsed into Storable
  • Storage and XMLStorage are now colapsed into XMLStorage Storage is now a typedef to XMLStorage to be deprecated, so that Load�From and StoreOn methods can be kept without modification.

1.3 to 1.4

  • In/OutControl are now FloatIn/OutControls which is an alias for In/OutControl<float>.
  • If you used InControl::GetLasValueAsBoolean/Integer you should consider using InControl<bool/unsigned>
  • If you used InControlTmpl (a control with callback), now you should use a plain FloatInControl, which now has a constructor to provide the callback.
  • Old control callbacks used to return int. Now they should return void.
  • Processing interface to iterate ports and controls has moved from iterator based to an index based access. For example, before we used GetInControls which returned an stl container, now we can use GetNInControl() and GetInControl(i), note that GetInControl(i) is overloaded with GetInControl(name). Also you can access a connector name with GetInControlName(i).
  • CLAM_EXTERNAL_FILE_DATA is deprecated in favor of CLAM_EMBEDDED_FILE
  • Many processings have changed their class name or their configuration. From this release we are providing a way to update the networks to this kind of change. The python program (CLAM/scripts/clamrefactor.py) which takes as input a list of changes to be made. The migration script for CLAM 1.4.0 is in CLAM/plugins/spacialization/migrationScript, not the proper place, sorry for the inconvenience.

1.2 to 1.3

  • Controls will change some behaviour in the future, see this to enable your code to be compatible with next CLAM modifications.
  • The API for creating LADSPA plugins from CLAM processings and networks has changed. See this tutorial
  • AudioFileIn/Out, which were deprecated since 0.98, have been removed. See previous notes on how to migrate.

1.1 to 1.2

  • The way processing are registered into the factory has changed to add metadata. More information in this howto
  • Although no explicit statement is mandatory to be able to use a custom data type, providing a ProcessingDataPlugin for such types is recommended, to have ports with different colors for each type. See this page.
  • Processing::GetExecState() has been removed. Use Processing::IsRunning() and Processing::IsConfigured() which lead to more readable code.
  • {Mono|MultiChannel}AudioFileReader::GetAudioFile() method has been removed. If you want to access the header or the text descriptors just use the {Mono|MultiChannel}AudioFileReader::GetHeader() and {Mono|MultiChannel}AudioFileReader::GetTextDescriptors()

1.0 to 1.1

vmqt and vmfl

clam_vmqt and clam_vmfl were dropped. Annotator/vmqt, based on qt4, contains a set of classes that should provide the same functionality than clam_vmqt but it is not API compatible.

AudioFile

Multi/Mono AudioFile Reader/Writer have changed their configuration. The SourceFile attribute is now a AudioIn/OutFilename instead a AudioFileTarget/Source. For example where your code was:

CLAM::AudioFile file;
file.OpenExisting("audio.wav");
if (file.IsReadable())
{
	// Manage error
}
CLAM::MonoAudioFileReaderConfig config;
config.SetSourceFile(file);
CLAM::MonoAudioFileReader reader(config);

Now it will be:

CLAM::MonoAudioFileReaderConfig config;
config.SetSourceFile("audio.wav");
CLAM::MonoAudioFileReader reader(config);
if (not reader.IsConfigured())
{
	std::cerr << reader.GetErrorConfigMessage() << std::endl;
	// Manage error
}

If your code used the CLAM::AudioFile object further, you can still get it from the processing using the GetAudioFile() method.

Concerning writers, now format parameters, formerly at AudioFile object, are mostly available directly as configuration object attributes. Such attributes are set by default so you can forget about them in most cases. By default,

0.98.0 to 0.99.0

The processing state 'Disabled' has been removed. Now a processing can be either Running, Ready or Unconfigured.

If you used any subclass of FFT_base and IFFT_base, you should consider moving to 'FFT' and 'IFFT' which renders to the better implementation available according to the with_X configure options. That's, by preference fftw3 (disabled by default until the next release), fftw2 and ooura.

0.95.0 to 0.96.0

OutControl::AddLink and OutControl::RemoveLink receive references instead of pointer as parameter.

0.91.0 to 0.95.0

The classes MonoAudioFileReader and MultiChannelFileReader take at the configuration an AudioFileSource instead of an AudioFile. Also MonoAudioFileWriter and MultiChannelFileWriter take AudioFileTarget. This has been changed for the automatically generated interface to treat them differently.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox