[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sc-devel] server naming conventions cleanup?



Hi Ross,


I will chime in support as well.

JMc had something of a tradition of SC going through complete changes of paradigm between versions and reserving clean-up of this sort
for new versions.

But the book project and has triggered a really magnificent shared effort to make SC clearer and more consistent.
IMHO that constitutes a change of equivalent importance.

RJK

On Jan 20, 2008, at 6:11 AM, Dan Stowell wrote:

Ross,

I'd vote in favour of your two changes.

Dan

2008/1/17, Ross Bencina <rossb-lists@xxxxxxxxxxxxxx>:
I don't think that a cosmetic change to the source code is a valid
reason to break plug ins - ever. I think we should live with it the
way it is.

That's kind of killed the conversation before we finished. For a start it's not clear what "break plugins" means -- are we talking about breaking binary compatibility (changing enum values or structure layout) or changing source compatibility (just changing names). And which plugins are we talking about?
We can always fix the ones which are part of the distro within any
name-change patch.

Private plugins could depend on any and all of the server source code in one way or another so I don't see a clear way to follow this guidance and move forward in improving the quality and redability of the server source code...

The main requested changes from my original post are below, I'm still
pushing for (1) because it makes it hard to read and write the server code and (2) because it makes it unnecessarily hard to understand. If backwards compatibility with plugins is the only issue then I'll prepare a patch which includes typedefs or defines as necessary to the old names (not so easy with
file name changes)..

1. - Inconsistent use of SC_ prefix: sometimes it's there, sometimes it
isn't.
This applies to both source files and headers.. often one or the other uses SC_ but not both. I can provide a full table of these if necessary. At a
minimum, in terms of types, I'd recommend  removing SC from
SC_BufReadCommand, SC_SequencedCommand and SC_LibCmd. All other types with SC_ are generic system object (like SC_Lock) which could easily collide if we removed SC. The alternative is to be add SC_ everywhere or remove it
everywhere

2. - Now for the big one: I'd like to see Graph renamed to Synth, and
GraphDef
renamed to SynthDef. There's 400 occurences of "Graph" in the source code,
but the IOUgens seem to be the only plugins which reference the name.

Ross.




--- james mccartney @ iphone

On Jan 12, 2008, at 2:20 AM, "Dan Stowell" <danstowell@xxxxxxxxx> wrote:

Well FWIW I don't agree with Ross, I think that keeping both for 3.2
and then dumping the old one for 3.3 would be standard deprecation
practice. But I'm not strongly motivated, happy to leave them named as
they are.

Dan


2008/1/12, Click Nilson <clicksonnil@xxxxxxxxx>:
Changing this seems like it would impact on a lot of plugins; would
seem too much to force everyone to recompile everything to be
compatible with 3.2. Can we please keep the old names even if they're not the most elegant? (though actually, we might live perfectly well
with calc_BufRate, as Ross also notes, and this is the only
controversial one). Or at least allow both to persist; unlike Ross, I
don't recommend a harsh name swap at this notice.

just my opinion,
N

On 10 Jan 2008, at 14:56, ronald kuivila wrote:

Hi guys,

This may be gelding the lily, but...
How about calc_SampleBlockRate and, for consistency,
calc_SampleRate?


RJK

On Jan 10, 2008, at 6:38 AM, Ross Bencina wrote:

Hi Dan

Thanks for the feedback... re the rates stuff:

I'd also like to mention one which came up re my chapter. In the
plugin API the constants for the different rates are
calc_ScalarRate
(scalar-rate), calc_BufRate (control-rate), calc_FullRate
(audio-rate), calc_DemandRate (demand-rate). "calc_BufRate" to me
is a
bit opaque/confusing and it would perhaps be more helpful to
change
over to "calc_ControlRate"? (Both constants would be preserved
for a
while, with calc_BufRate being deprecated, since it's in the API.)
Grateful for thoughts on that.

Seems like ControlRate would make more sense for people who are in
the know,
but "BufRate" is actually more accurate to the semantics of the
operation
imho..

I don't like the idea of keeping both.. I say break plugins and
change the
name. If it has the same value it will only break things on
recompile and
developers will soon sort that out.

R.
_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel


_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel



--
http://www.mcld.co.uk
_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel



--
http://www.mcld.co.uk
_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel