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