Re: [Zynaddsubfx-user] whitespace, WAS [Fwd: Re: more on improved jack io]

[cal <ca...@gr...>]

Let's see if we can calm this down a little and edge our towards
productivity.
 
Mark McCurry wrote:
> Cal,
> 
> I am not quite too sure how to interpret your emails at this point.
> At first you seemed to make a large issue out of the whitespace:
It is a major issue. A tedious chore to address, but the whole codebase
really does need to be transformed into a readable form.
 
> 
>  >On the subject of whitespace - the complete absence of whitespace and 
> rational
>  >indentation in the official code is one of the main reasons (but not 
> the only
>  >one) why zyn is in danger of bit-rotting its way to oblivion. Code 
> like that
>  >was normal in 2002, but you'd be hard pressed to get any serious coder 
> to even
>  >look at it today. In my humble opinion, the whole codebase needs the 
> whitespace
>  >issue addressed if the code's to have any future.
> 
> This discussion upon the whitespace was attempted because you put the 
> emphasis on it.
> If it is indeed an "utter wast of time", then it shall not be put to a 
> discussion.
Exactly, endless discussion of it is a waste of time, not the transformation.
I tried to make the point that anyone can comply with a half decent style
standard. When modifying code with some inherent measure of style, most
people tend to conform fairly readily. As the benevolent dictator running
the project, just make an executive decision and implement it. 

> I will say that after working though your patch some more, I have been 
> able to see that through some
> simple automation, the patch can be reduced from ~36,000 lines to less 
> than 20,000 lines.
> In this automation many of the repetitive changes were put into a simple 
> script, so that the rest of the code was more visible within the diff.
> Some of the automations were renaming zynMaster to master, REALTYPE to 
> zynsample_t, //file.C to //file.cpp,  prefix increment to postfix 
> increment within basic loops, whitespace regulation with uncrustify, and 
> OSCIL_SIZE, SAMPLE_RATE, and SOUND_BUFFER being renamed to their Master 
> member names.
> This is still very large and it will take time to sort through.
Whatever works for you, go for it.

> For now I will need to say that although it does contain some good 
> revisions to the input and output systems, but it is not something that 
> can be simply applied.
Of course not. It wasn't presented as a "commit ready" patch, it was
presented as "experimental".

> It does have a number of instances where changes have been reverted (eg 
> doxygen and samples) without explanation
I don't feel any obligation to explain anything.

> It has several feature breaks (which as you said, it is an experimental 
> patch)(eg the VST removal and Windows removal)
I have no interest in Windows/VST. If you care for it, you get to maintain
it.
 
> It also has a number of locations where changes have been made, but 
> testing has not been done (which could result in many small regressions)
Quite true. I do think you're missing the meaning of "experimental". If
you're familiar with the movie Young Einstein, experimental software is
known to produce similar little mushroom clouds when it occasionally
explodes before your eyes. The purpose of my experiment is to explore the
edge of the known universe and figure out a way to make zyn's jack io
acceptable. Right now, I don't know the best way to do it, and nor do you
or you would have done it by now :-). Some experimentation is in order. 
 
> I will say that after reading through a good number of sections I think 
> that there will be a number of changes that will be eventually made to 
> zyn based upon sections of your patch:
> -The Input/Output drivers (The structure is much cleaner that the 
> current configuration)
> -Fixing the .C -> .cpp change within the copyright comment (which should 
> be simple and automated)
> -changing of OSCIL_SIZE , SAMPLE_RATE , and SOUND_BUFFER_SIZE to be 
> members of Master
> -changing of REALTYPE to zynsample_t
> When any piece of your code is integrated you will be given the proper 
> credits.
Yeah, yeah, I'll bet you say that to all the boys ... as GPL requires.

I posted the patch in the hope that presenting an example of how things might
be done better could prove helpful to the project, perhaps even stimulate some
cooperation. I indicated previously that I'm reluctant to engage the project
in any serious fashion. The yelling hasn't changed my mind.

cheers, Cal