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

["Dan Stowell" <danstowell@xxxxxxxxx>]

Hi -

OK, thoughts:

2008/1/10, Ross Bencina <rossb-lists@xxxxxxxxxxxxxx>:
> It's pretty difficult to make a clean description of scsynth for the book
> when there is a lot of apparent inconsistency in naming conventions (unless
> I'm missing something). I've highlighted the most glaring below:
>
> - 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

I haven't looked into this but your proposal sounds OK to me.

> - 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.

I think I'm in favour of this. It looks to me like it should be
possible to do this cleanly and straightforwardly, others please
correct me if I'm wrong. I've never seen a third-party plugin refer to
Graph or GraphDef although of course it's possible.

> - The other main domain entity with an alias is SndBuf which is generally
> referred to as Buffer outside the server implementation. I can see why
> renaming that may be less palatable.

I don't think SndBuf is too bad. Also SndBuf is in the plugin API and
used by a lot of plugins. But I'm open to persuasion.


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.

Dan


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


-- 
http://www.mcld.co.uk