[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sc-devel] server naming conventions cleanup?
There are ugens floating around written by people who have moved on
are probably never going to recompile them. These will be broken
forever. OK, Well they didn't release the source code, so maybe it is
deserved.
---
A GraphDef is not a SynthDef. They are different types. One is the
result of a transformation of the other. In pseudo Haskell notation
you'd have this:
SCLang :: SynthDef -> array of bytes
SCSynth :: array of bytes -> GraphDef
I think it would be slightly more confusing to have the SCSynth object
and the SCLang object have the same name since it would then require
an additional word to disambiguate which you are talking about. But I
don't really care that much.
On Jan 17, 2008 1:54 AM, Ross Bencina <rossb-lists@xxxxxxxxxxxxxx> wrote:
> >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
>
--
--- james mccartney