Subject: Re: Support in LEWG regarding getting std::hive (nee colony) in C++23
From: Matthew Bentley (mattreecebentley_at_[hidden])
Date: 2021-09-29 19:07:22
Yes, I'd also be interested in more detail on that subject (being a
musician and having dont some VST programming in my time).
To all who're in LEWG: std::hive has been scheduled for a telecon on the
13th of December, 12:00 to 13:30 Pacific time. If you're able to attend
that'd be great. Thanks to all those who thrust their heads above the
surface in the mailing list to request this be discussed for C++23.
On Thu, 30 Sept 2021 at 13:00, Ville Voutilainen <
> On Thu, 30 Sept 2021 at 02:31, Klaim - JoÃ«l Lamotte via SG14
> <sg14_at_[hidden]> wrote:
> >> Thanks Joel- if you don't mind I'll quote you in a later version of the
> >> (putting together an appendix of use-case quotations).
> > I don't mind, though I have noticed that some in the committee assume
> people's experience feedback when coming from games and some other
> industries are not taken seriously and are considered not relevant, not
> necessarily officially but effectively.
> > Basically, I don't think that will help.
> Well, there's people in the committee who are focused on their
> problems and their employer's problems, but there's also
> a fair amount of programmers who are just intrigued about problems
> they're not all that familiar with, have a vested
> interest in helping C++ be better in less-known domains, and have a
> tendency to help other programmers to solve their
> problems. I'd call it "worth a shot".
> >> Where is it used in music? AFAIK most plugin design etc is strictly
> >> ordered in terms of samples etc, so I'm interested as to where it's
> >> getting used in the process.
> > For music, which is still a bit new to me (I have been in this domain on
> the programming side only for a year now), I have seen situations where
> hive would have been a better choice and would have simplified the code -
> but was not available at the time of writing or the devs weren't ready to
> setup a similar container to solve their problem (and then I ended up
> having to maintain that, but couldn't replace the whole thing with hive
> without a major rewrite).
> > I'm talking about music as in the domain, not specifically audio code
> (which is what you are mentioning). The main example I am thinking about is
> musical score modeling, transformation, display and audio interpretation
> (similar to playing midi, but from a score instead of midi). The internal
> data model is where I spotted the issues that could have been simplified by
> hive, mainly by benefiting from fast traversal and stable location of
> elements, allowing to refer to them directly instead of doing shared
> pointers guesses. (that codebase also could benefit from immutable data
> structures but that's unrelated).
> > It's totally possible my experience is not common in that specific
> domain, but I spotted this and it's a pattern/situation/opportunity I have
> seen a lot of codebases in the last 15 years (mostly in performance-focused
> I think it would be very helpful if you can be just a little more
> specific, in describing what you'd use std::hive for, what the access
> are, how it would be used in playback from a score. There are some
> musicians in the committee, it might ring some bells for them
> as a very plausible practical use case. We have a person in the
> committee who has apparently written his own music score application,
> so who knows, it might ring some serious bells.
SG14 list run by email@example.com
Older Archives on Google Groups