Date: Thu, 30 Sep 2021 03:00:00 +0300
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 paper
>>
>> (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 domains).
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
patterns
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_at_[hidden]> wrote:
>> Thanks Joel- if you don't mind I'll quote you in a later version of the paper
>>
>> (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 domains).
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
patterns
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.
Received on 2021-09-29 19:00:16