The midi conversation went south the second it started. > Heh, you're missing my point
No you are missing mine. It doesn't make sense for two days to combine. It totally makes sense for two signals to combine. > If you want to treat your midi notes as bare numbers that can be added and have no semantics of absolute pitch until you send them to a synth, be my guest. These things are fundamentally numbers, you can call them whatever you want. > I think I've offered all the help here that I have to give, and I don't feel I'm successfully getting my point across, so with respect, I'm going to retire from this discussion now. I'm supposed to be on vacation :-) That's two of us. On Mon, Dec 26, 2016 at 2:49 PM, Dave Abrahams <[email protected]> wrote: > > on Mon Dec 26 2016, Adam Nemecek <adamnemecek-AT-gmail.com> wrote: > > >> here weren't one, that hypothetical machine is, logically speaking, > > stripping the absolute-pitch-ness off of the MIDI note used for > > transposition and using it as a relative pitch offset. > > > > Indeed. > > > >> It's like the relationship between dates on the calendar and time > > intervals (10 days). > > > > No it's not. Two days cannot occur at the same time. Two events totally > > can. It's more like signals that combine. > > Heh, you're missing my point because there's a “time” component to both > systems but that wasn't intended to be a connection. It's like the > relationship between addresses in memory (pointers) and offsets. > > If you want to treat your midi notes as bare numbers that can be added > and have no semantics of absolute pitch until you send them to a synth, > be my guest. I would tend not to design a system that way, but if it > works for you, more power to ya. > > I think I've offered all the help here that I have to give, and I don't > feel I'm successfully getting my point across, so with respect, I'm > going to retire from this discussion now. I'm supposed to be on > vacation :-) > > > On Mon, Dec 26, 2016 at 2:31 PM, Dave Abrahams <[email protected]> > wrote: > > > >> > >> on Mon Dec 26 2016, Adam Nemecek <adamnemecek-AT-gmail.com> wrote: > >> > >> >> `ManagedBuffer` is the standard library base class that offers > >> facilities > >> > for managing buffers. If there's a concrete use case that isn't > served, > >> > then the argument would be to improve `ManagedBuffer` or to design > other > >> > types or protocols for that use case, not to add a protocol to conform > >> > every type that implements `init()`. > >> > > >> > I'd prefer not to deal with raw storage unless necessary. > >> > > >> >> The distance between two values of type T does not itself need to be > of > >> > type T, > >> > > >> > Never said otherwise. > >> > > >> >> Moreover, one can have distances being strideable opaque types that > >> can't > >> > even be initialized > >> > > >> > You sure can. Doesn't disprove any of my points. > >> > > >> >> This example does not make sense, computationally or musically. > >> > > >> > You mean that it does not make any sense to you. I have two midi > streams > >> > (and they are midi) and I want to use one midi note to transpose the > >> other. > >> > I'm pretty sure that I can find a machine that does this in hardware > if I > >> > really try. Does the fact that such machine might exist imbue the > concept > >> > of midi addition with any meaning? > >> > >> There's a Channel Coarse Tuning SysEx message for this purpose. Even if > >> there weren't one, that hypothetical machine is, logically speaking, > >> stripping the absolute-pitch-ness off of the MIDI note used for > >> transposition and using it as a relative pitch offset. It's like the > >> relationship between dates on the calendar and time intervals (10 days). > >> > >> -- > >> -Dave > >> > > -- > -Dave >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
