PureBasic Forums - English

One issue I keep running into with PB's implementations of libraries of late is that often times, the implementation doesn't include features of the library I need, or wraps them in the way that doesn't work for me, which is understandable, but the bigger issue is that I can't seem to access the internal API so that I can extend the existing implementation in order to do what I need.
E.g., when PB used Direct Sound for the sound library, I could do something like And then use my own pan/volume scailing that worked better for me.
However, I don't see a way to do this with the existing miniaudio implementation without interfacing with miniaudio directly and completely replacing PB sound library calls with raw miniaudio calls, and the same for WebView2.
I have tried using GadgetID and IsGadget with my WebViewGadget and using it with ICoreWebView2/ICoreWebView2Controller, but that doesn't seem to work.
I feel like it would be very much appreciated and save a lot of headaches if implementations were exposed in such a way that the internal API's could be accessed and worked without rewriting library wrappers all together.
Thanks.

When I hit the WASAPI sleep problem when PB first switched over to MiniAudio, Fred sent me some code that imported raw MiniAudio C functions, as well as the PB_Sound_Engine.i pointer. Would being able to do this do what you want?
For whatever it's worth I agree with you, being able to extend the libs ourselves would solve so many headaches.

I'm glad you agree.
It was just an example, I ended up using Miniaudio directly, but I appreciate the thought.

I will see what can be done, I could share the .h in the SDK folder if you really want to mess with internals (but it could break anytime !)

Hi there,

please have a look at this as well: We started discussing the audio-topic
Would be great to join forces in audio-related topics to improve PureBasic further!

https://www.purebasic.fr/english/viewtopic.php?t=86234

Fred wrote: Tue Feb 11, 2025 4:05 pm ...I could share the .h in the SDK folder if you really want to mess with internals...

Yes please
More info would help a lot in debug and PB tool creation to avoid conflicts.

This would be great if it could be done. To have a way to access the underlying object of a specific instance of a library and manipulate it directly like you could do direct sound, or like you can do gadgets with winapi or cocoa.
Doesn't even need to be a header file, but if that's the only way, I'd take it.
Also what Skywalk said regarding easier debugging.