<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 27, 2020 at 1:04 PM Chris Robinson <<a href="mailto:chris.kcat@gmail.com" target="_blank">chris.kcat@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 27 Sep 2020 11:43:10 -0500<br>
Patrick Baggett <<a href="mailto:baggett.patrick@gmail.com" target="_blank">baggett.patrick@gmail.com</a>> wrote:<br>
<br>
> Hi Chris,<br>
> <br>
> Thanks for the document. I've just done some initial implementation of<br>
> using AL_SOFTX_events. It's very useful for my use case, explained<br>
> below. I also have two suggestions:<br>
> 1) Adding per source user data would be more useful<br>
> 2) clarify Q/A slightly.<br>
> <br>
> These are explained more below.<br>
<br>
Thanks for the feedback.<br>
<br>
> However, I did have to add a map from source -> engine data structure<br>
> so that inside the callback I can find the corresponding engine data<br>
> structure that owns this source. My suggestion then is that adding<br>
> per-source user pointer would eliminate the need for this. I'm not<br>
> sure how that would interact with the provided user pointer callback.<br>
> Maybe something like if callback userdata is NULL, then use<br>
> per-source userdata, otherwise, use global userdata. I can't imagine<br>
> a usecase for both pointers in the callback.<br>
<br>
Hmm. My first thought was to allow setting user data on a source, e.g.<br>
alSourcePointerSOFT(source, AL_USER_DATA_SOFT, userData);<br>
which can later be retrieved with<br>
alGetSourcePointerSOFT(source, AL_USER_DATA_SOFT, &userData);<br>
<br>
Although this wouldn't work given the 'no AL calls in the callback'<br>
restriction. Technically such a call wouldn't be a problem as it<br>
currently stands, but some AL calls could pose a problem if called from<br>
the callback, so it's probably best to not tempt fate.<br>
<br></blockquote><div>This was exactly my reasoning. The wording of it seemed to exclude any sort of alGetSource()<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Having the callback give the source user pointer if the context user<br>
pointer is null feels hacky, especially considering different event<br>
types can handle different object types. It can get tricky knowing what<br>
the user data points to.<br>
<br></blockquote><div>Yes, it is hacky. It was the only solution I could come up with that would maintain the function's call signature. The idea of a per-source user datum is just a suggestion that would help my use case. I'm using a source -> pointer map outside of AL so this would only reduce the memory usage of my app by some 1-2k at most. Nothing major.</div><div><br></div><div>Thanks for your hard work on this!</div><div><br></div></div><div class="gmail_quote">--Patrick Baggett<br></div></div>
</div>