Repository navigation
Make BASS components less internal
#6112
Unanswered
Feodor0090
asked this question in
Q&A
Replies: 2 comments
|
They are internal because BASS is - in the large scale of framework things - an implementation detail. Consumers should not care what's underneath. MIDI playback support is mostly out of scope. It's either what you have or forking framework. |
0 replies
|
I'd say for now you're best off forking of copy-pasting classes you need into your local project. We're severely manpower limited and not looking to increase scope for now. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Primary usage scenario for o!f audio system is obtaining tracks from
ResourceStoreor internet viaITrackStoreby name.My use case is quite more complex - i'm getting tracks data as
byte[]from another application, i don't know arrived track format and it maybe an SMF file (midi). I ended up using BASSMIDI extension and created this thing: https://gist.github.com/Feodor0090/7e9f9a1d53aeb5445a5fabce03751af2The question is in reflection usage.
TrackBassconstructor is internal, so it can't be created directly. Also, to interact with BASSMIDI i need track handle, but it's exposed viaIBassAudioChannelthat is also internal.What were the reasons not making these public, and can they be made public to make BASS plugins integration with o!f easier?
All reactions