[swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

[Adam Nemecek]

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 <dabrahams at apple.com> 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 <dabrahams at apple.com>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161226/6c68d90f/attachment.html>