I just realized that there were still a lot of InControlTmpl around CLAM. InControlTmpl is a subclass of InControl so we need to manage it before removing XControl classes (step 3). Say a 2.5 step.
So i did a ninja move on the svn to push the callback controls into InControl and TypedInControl using the implementation i wrote yesterday, in order to ease step 3. Now you can move the typedef safely and all those controls will work the same. I had also to reimplement/erase InControlArrayTmpl. I just added the needed methods (but not all) to ControlArray<ControlType>. If i missed any occurrence to migrate those are the steps: * InControlTmpl<MyProcessing> -> FloatInControl * InControlTmplArray<MyProcessing -> InControlArray * Constructor parameters are the same * Any linked callback should return void now As soon as we have the wiki available i will write the full migration guide. On Diumenge 15 Febrer 2009 17:25:41 David García Garzón wrote: > Sorry for the delay on answering but you don't need acknoledgement, as soon > as you pass all the tests. You are a commiter ;-) Further changes or > reverts can be done if something outside the tests is wrong. Don't let the > show stop. > > Commented out tests on GetLastValueAsBool/Integer can be fully removed. We > should use TypedXControl<bool/unsigned>. > > About the publishers, why aren't the tests passing? > > On Dissabte 07 Febrer 2009 11:37:32 Francisco Tufró wrote: > > I've done the necessary changes to migrate FloatXControl from XControl to > > TypedXControl<float>. > > Except for testInControlPublisher and > > testInControlPublisher_ConnectControlsFromPublisher all tests where ok > > and i compiled NetworkEditor & Annotator an run them. > > I send the patch through the list for you to test it better before > > commiting it. > > > > On Fri, Feb 6, 2009 at 12:20 PM, David García Garzón > > <[email protected]>wrote: > > > I guess so. Nice because compiler will warn us if there is any one left > > > as soon as we remove the class (before renaming the template). > > > > > > On Friday 06 February 2009 13:42:31 Francisco Tufró wrote: > > > > I've found that some XControl direct access still exist in plugins. > > > > Should i rename all these to FloatXControl? > > > > > > > > examples/MIDIIOExample.cxx: InControl > > > > stopReceiver("stop-receiver"); > > > > plugins/continuousExcitationSynthesizer/SDIFDatabaseProcessing.hxx: > > > > InControl mPitchControl; > > > > plugins/continuousExcitationSynthesizer/SDIFDatabaseProcessing.hxx: > > > > InControl mAmplitudeControl; > > > > plugins/continuousExcitationSynthesizer/SDIFDatabaseProcessing.hxx: > > > > InControl mBrightnessControl; > > > > plugins/spacialization/src/BFormatRotation.hxx: CLAM::InControl > > > > _roll; plugins/spacialization/src/BFormatRotation.hxx: > > > > CLAM::InControl _azimuth; > > > > plugins/spacialization/src/BFormatRotation.hxx: > > > > CLAM::InControl _elevation; > > > > plugins/spacialization/src/IncoherenceCompensator.hxx: InControl > > > > mDeviation; > > > > plugins/spacialization/src/ComplexSpectrumMixer.hxx: InControl > > > > _gain1; plugins/spacialization/src/ComplexSpectrumMixer.hxx: > > > > InControl _gain2; > > > > plugins/spacialization/src/RoomImpulseResponseSimulatorCommandLine.hx > > > >x: InControl _sourceX; > > > > plugins/spacialization/src/RoomImpulseResponseSimulatorCommandLine.hx > > > >x: InControl _sourceY; > > > > plugins/spacialization/src/RoomImpulseResponseSimulatorCommandLine.hx > > > >x: InControl _sourceZ; > > > > plugins/spacialization/src/RoomImpulseResponseSimulatorCommandLine.hx > > > >x: InControl _listenerX; > > > > plugins/spacialization/src/RoomImpulseResponseSimulatorCommandLine.hx > > > >x: InControl _listenerY; > > > > plugins/spacialization/src/RoomImpulseResponseSimulatorCommandLine.hx > > > >x: InControl _listenerZ; > > > > plugins/spacialization/src/RoomImpulseResponseSimulatorCommandLine.hx > > > >x: static unsigned map(InControl & control, unsigned limit) > > > > plugins/spacialization/src/VectorBasedArrayPanning.hxx: > > > > > > CLAM::InControl > > > > > > > _beta; > > > > plugins/spacialization/src/BFormatRotationZoom.hxx: > > > > CLAM::InControl _roll; > > > > plugins/spacialization/src/BFormatRotationZoom.hxx: > > > > CLAM::InControl _azimuth; > > > > plugins/spacialization/src/BFormatRotationZoom.hxx: > > > > CLAM::InControl _elevation; > > > > plugins/spacialization/src/BFormatRotationZoom.hxx: > > > > CLAM::InControl _dominance; > > > > plugins/spacialization/src/ImpulseResponseInterpolator.hxx: > > > > InControl _position; > > > > plugins/spacialization/src/Vbap3D_OneSpeaker.hxx: CLAM::InControl > > > > _azimuth; > > > > plugins/spacialization/src/Vbap3D_OneSpeaker.hxx: CLAM::InControl > > > > _elevation; > > > > plugins/spacialization/src/Vbap3D.hxx: CLAM::InControl _azimuth; > > > > plugins/spacialization/src/Vbap3D.hxx: CLAM::InControl _elevation; > > > > plugins/spacialization/src/ImpulseResponseDatabaseFetcher.hxx: > > > > > > InControl > > > > > > > _emitterX; > > > > plugins/spacialization/src/ImpulseResponseDatabaseFetcher.hxx: > > > > > > InControl > > > > > > > _emitterY; > > > > plugins/spacialization/src/ImpulseResponseDatabaseFetcher.hxx: > > > > > > InControl > > > > > > > _receiverX; > > > > plugins/spacialization/src/ImpulseResponseDatabaseFetcher.hxx: > > > > > > InControl > > > > > > > _receiverY; > > > > plugins/spacialization/src/ImpulseResponseDatabaseFetcher.hxx: > > > > static unsigned map(InControl & control, unsigned limit) > > > > plugins/GuitarEffects/AutomaticGainControl/AutomaticGainControl.hxx: > > > > InControl mOutputReference; > > > > plugins/osc/LibloSink.hxx: InControl _in1; > > > > plugins/osc/LibloSink.hxx: InControl _in2; > > > > plugins/osc/LibloSink.hxx: InControl _in3; > > > > > > > > On Wed, Feb 4, 2009 at 4:29 PM, David García Garzón > > > > > > <[email protected]>wrote: > > > > > Just for the record, and just in case some one wants to take them > > > > > > before > > > > > > > > i can > > > > > do it: > > > > > > > > > > Current refactoring status (X=In or Out): > > > > > > > > > > - BaseXControl: Is the base class for any X controls > > > > > - XControl: Is the old control interface for just floats > > > > > - TypedXControl<T>: Is the new templated interface > > > > > - FloatXControl: Is a typedef to XControl to easy the transition > > > > > > > > > > To get there: > > > > > - Most common behaviour has been moved to BaseXControl. > > > > > - All uses of XControl has been renamed to BaseXControl or > > > > > > FloatXControl > > > > > > > > depending on the kind of usage (general or float). > > > > > - Some direct control sending has been abstracted into functions > > > > > living in Processing.hxx > > > > > > > > > > Target status: > > > > > > > > > > - BaseXControl: Is the base class for any X controls > > > > > - XControl<T>: Is the new templated interface (renamed!) > > > > > - FloatXControl: Should point to XControl<float> or we could remove > > > > > it > > > > > > > > > > So, pending steps are: > > > > > > > > > > 1- Converge existing differences in float interface (bounds, > > > > > defaults > > > > > > and > > > > > > > > bool/int conversion) in BaseXControl/XTypedControl versus XControl > > > > > one. 2- Point FloatXControl typedef to XControl<T> and check that > > > > > all is > > > > > > still > > > > > > > > working properly ¬¬ > > > > > 3- Remove the XControl classes, checking that there still is no > > > > > direct dependency on them > > > > > 4- Rename TypedXControl<T> to XControl<T> so we have the same > > > > > interface than > > > > > with ports. > > > > > 5- Rename FloatXControl usage to XControl<float> (or keep it as we > > > > > have AudioInPorts as InPort<float> alias) > > > > > > > > > > Other issues to address eventually: > > > > > > > > > > 6- Decide what to do with the Bound and Default interface in > > > > > > BaseXControl > > > > > > > > 7- What to do with the free functions in Processing.hxx that handle > > > > > > float > > > > > > > > control sending. > > > > > 8- Make XControlPublishers not just float > > > > > > > > > > > > > > > David. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Clam-devel mailing list > > > > > [email protected] > > > > > > https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-dev > > >el -- David García Garzón (Work) dgarcia at iua dot upf anotherdot es http://www.iua.upf.edu/~dgarcia _______________________________________________ Clam-devel mailing list [email protected] https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
