[Clam-devel] Get{In,Out}{Ports}{Controls}

[David García Garzón]

Not to be taken seriously, but who knows, menace: Merge the typed-control 
changes or when i would be back on holidays in two weeks i'll start to develop 
them again in trunk in a more incremental way.

Pau and me did a nice DynamicTypes refactor in a not so nice branch and it has 
been there for some years (3? 4?) without a merge. Big refactors should be 
integrated in an incremental way. If not the probability of the branch to 
become abandoned increases each day the merge doesn't happen. Branches are 
evil because merges scare so face the merge or kill the branch. Don't let the 
branch become a zombie like the DynamicTypes one.

David.


On Saturday 06 September 2008, Hernán Ordiales wrote:
> I like this approach.
>
> Some related thoughts: Sometime ago I had started an experimental
> bazaar/launchpad based "branch" to maintain (and btw trying the
> launchpad thing) the typedcontrols migration patch, in other words,
> francisco's changes without commit to the trunk yet. I already
> commented something about this to him but I still have to find more
> time to post a detailed mail about that. Main advantage i see is that
> this allows to evolve the patch with private commits (and more free,
> since you hasn't to be so careful to avoid breaking something) and
> still having the opportunity to update from trunk (with the 'bzr
> merge' command), not lose the sync and then produce a final patch to
> apply. OTOH, I'm still not sure of how to turn it into a branch
> allowing multiple developers "commits" or contributions, i think it's
> just a matter of more merges but i have to try it. Beyond that, i
> think it's pretty the same of having and maintaining a sandbox with
> uncommitted changes but in this case with the option of private
> commits (as example, useful to rollback some changes)
>
> On Fri, Sep 5, 2008 at 6:03 PM, David García Garzón <dgarcia at iua.upf.edu> 
wrote:
> > I did a couple of changes which may have impact on existing code and in
> > Francisco work with TypedControls and MIDI.
> >
> >  * Midi plugins joined into a single one
> >
> > This one just requires a warning to Francisco: I moved the sources to
> > one 'src' folder and i made them to compile into a single libmidi plugin.
> > So, if you had local changes save them, just in case.
> >
> >  * Processing::Get{In,Out}{Control,Port}() overloaded for indexes and
> > names * Processing::GetN{In,Out}{Controls,Ports}() to get the number of
> > connectors * Processing::Get{In,Out}{Controls,Ports}() are now protected
> > methods
> >
> > I hope that this change will made CLAM coding more easy.
> >
> >  processing.GetOutControls().Get("gain");
> >  processing.GetOutControls().GetByNumber(3);
> >
> > becomes:
> >
> >  processing.GetOutControl("gain");
> >  processing.GetOutControl(3);
> >
> > and
> >
> >  InControlRegistry & inControls = processing.GetInControls().
> >  for (InControlRegistry::iterator it = inControls.Begin();
> >        it != inControls.End(); it++)
> >  {
> >        InControl & inControl = *it;
> >
> > becomes
> >
> >  unsigned nInControls = processing.GetNInControls();
> >  for (unsigned i=0; i<nInControls; i++)
> >  {
> >        InControl & inControl = processing.GetInControl(i);
> >
> >
> > This change also might have impact in Francisco work with Typed controls
> > as i also changed the Typed related interface.
> >
> > I made base connectors Processing friends to still be able to access the
> > old functions. A better solution is feasible for sure but not enough time
> > to implement it.
> >
> > Going to Granada now. Bye.
> >
> > David.
> >
> >
> >
> >
> > _______________________________________________
> > Clam-devel mailing list
> > Clam-devel at llistes.projectes.lafarga.org
> > https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel


-- 
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
http://www.iua.upf.edu/~dgarcia