Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Looking for maintainers #82

Open
MathewSachin opened this issue Jul 28, 2020 · 24 comments
Open

Looking for maintainers #82

MathewSachin opened this issue Jul 28, 2020 · 24 comments

Comments

@MathewSachin
Copy link
Member

The main use for ManagedBass for me was within a screen recording program I made. Eventually, it shifted to use NAudio to be completely open-source and because it had to run only on Windows. BASS is really great for multi-platform use.

But, I had many bad experiences (not related to BASS) in that screen recording program like people just blatantly copying it and selling it as their own on Microsoft Store and reporting those apps doesn't help. As a result, I've kind of grown frustrated of Windows and .NET as platforms to develop for and I'm shifting to other platforms like Android.

I would like to leave the project in the hands of people who continue to use it actively. Since ManagedBass is just a wrapper library, not much of an effort should be required for maintenance.
Particularly, I'd like if people who have already contributed to the repo could take up the ownership like @olitee @RCSDustinBond
and the folks from osu!.

I don't really feel good leaving my projects like this, but, it's not much use to keep it stale when I'm not motivated enough to work on it 😢.

@DustinBond
Copy link
Contributor

DustinBond commented Jul 28, 2020 via email

@MathewSachin
Copy link
Member Author

@RCSDustinBond That's really nice to hear. I have sent you an invite to add as a Member to the ManagedBass GitHub organization. After you accept, I'll convert you to an Owner.
I'll also share the NuGet keys by mail to you.

@MathewSachin
Copy link
Member Author

@RCSDustinBond I think NuGet has changed how permissions work for organizations a bit. To give you access to the NuGet packages, I need to know your NuGet username.

@olitee
Copy link
Contributor

olitee commented Jul 28, 2020

Hi @MathewSachin, thanks for the callout. I think @RCSDustinBond is clearly better positioned to maintain this library day-to-day. My interest in this library is limited to a number of personal audio playback projects, that often need to sit on the back burner while I do the day job.

Happy to stay involved though.

@bpieslak
Copy link

@MathewSachin - sorry to hear about your bad experiences. Thank you for making this project, and for all of the support you provided me in the early days. I know I haven't been involved in a while, since my project basically reached steady-state and didn't require any further development or updates. I know my project would not have been possible with out you and your efforts.

Be well, and feel free to reach out if you ever need anything.
-Brian

@DustinBond
Copy link
Contributor

@MathewSachin - I created a new account on Nuget, Dustin.Bond ([email protected]) ...

@FoggyFinder
Copy link

What's a status of this issue?

@d8ahazard
Copy link

@MathewSachin , @DustinBond - Is this project still being maintained? Having some issues with a device, could really use a bit of assistance.

#86

@DustinBond
Copy link
Contributor

DustinBond commented Feb 8, 2021 via email

@mdsitton
Copy link
Contributor

mdsitton commented Feb 24, 2021

We use ManagedBass for Clone Hero as well, so if needed could also potentially help out with maintenance.

I've just submitted a pr #87 for a bug i found today while converting some of our sound effects to use Opus.

@olitee
Copy link
Contributor

olitee commented Aug 7, 2021

Hi @DustinBond / @MathewSachin,

Do you have any plans for updating the nuget packages for this library? I'd be happy to assist in setting up an automated build/release process if you want?

I'm conscious that the current v3.0.0 nuget packages have some versioning issues, and have not been updated for almost 18 months - and that ParkSquare has recently forked this repo as 'BassSharp' (https://github.com/parksquare/BassSharp) to fix this issue.

While I'm tempted to switch to using the BassSharp nuget packages for my own projects, I feel it makes sense the solve the problem at the source - particularly since this repo has an established userbase and is relatively active.

Any thoughts? :)

@MathewSachin
Copy link
Member Author

Automated releases would be great!
I can set up a NuGet key as a GitHub Action secret, or would you prefer collaborator access?

I personally didn't have any important projects depending on ManagedBass/BASS now, so the packages were left stale...

@MathewSachin
Copy link
Member Author

I've added a GitHub Actions secret: NUGET_KEY which can be used to push packages to NuGet.
This wouldn't be accessible from pull-requests due to security concerns.

@peppy
Copy link
Contributor

peppy commented Aug 7, 2021

As a heads up when releasing a new version: #93 may be regressing behaviour (we can't compile for iOS currently). Haven't investigated in detail yet.

@d8ahazard
Copy link

Hi @DustinBond / @MathewSachin,

Do you have any plans for updating the nuget packages for this library? I'd be happy to assist in setting up an automated build/release process if you want?

I'm conscious that the current v3.0.0 nuget packages have some versioning issues, and have not been updated for almost 18 months - and that ParkSquare has recently forked this repo as 'BassSharp' (https://github.com/parksquare/BassSharp) to fix this issue.

While I'm tempted to switch to using the BassSharp nuget packages for my own projects, I feel it makes sense the solve the problem at the source - particularly since this repo has an established userbase and is relatively active.

Any thoughts? :)

Would it be possible to add package(s) that also include the native bass.dll and/or other required libraries, similar to how Emgu.CV packages the required openCV libraries for various operating systems? I think having the runtimes avaialable via NuGet as well would be incredibly useful.

@olitee
Copy link
Contributor

olitee commented Aug 7, 2021

@d8ahazard I can think of a number of pros and cons for this approach. The most obvious problem being how to intelligently handle switching between 32/64 bit versions of the libraries at compile time.

I'd also have to check with Un4Seen - as I'm pretty sure the licencing for those DLLs doesn't allow us to distribute them as part of a library. Their licence specifically states:

"Please note the products must be end-user products, eg. not components
used by other products. "

But I could reach out to Ian in the forums there for clarification.

@DustinBond
Copy link
Contributor

DustinBond commented Aug 7, 2021 via email

@MathewSachin
Copy link
Member Author

I've sent him an invite 👍

@olitee
Copy link
Contributor

olitee commented Aug 8, 2021

@DustinBond @MathewSachin Thanks for the invite.

I've setup a pair of github Actions: One to act as a build-test (replacing appveyor), and the other to build, package and publish the nuget packages. All of this is currently on automation/github-action-for-package-publishing branch for now, while I test.

I'm thinking the best way of handling the nuget packages will be via the repository's Releases feature. So creating a release with a tag using semantic versioning (e.g. v.3.0.1, etc) will trigger the action to create and publish the nuget packages.

This approach also supports prerelease versions (e.g. v3.0.1-prerelease, or v3.0.1-beta) which could be handy.

It gives us complete control over the releases - rather than simply firing out a new package when the master branch changes.

Are you both OK with that approach?

@MathewSachin
Copy link
Member Author

Yes, sounds perfect to me.

@d8ahazard
Copy link

@d8ahazard I can think of a number of pros and cons for this approach. The most obvious problem being how to intelligently handle switching between 32/64 bit versions of the libraries at compile time.

I'd also have to check with Un4Seen - as I'm pretty sure the licencing for those DLLs doesn't allow us to distribute them as part of a library. Their licence specifically states:

"Please note the products must be end-user products, eg. not components
used by other products. "

But I could reach out to Ian in the forums there for clarification.

Yeah, that would be awesome. Heck, maybe Un4Seen would be open to creating nuget package(s) directly...which would alleviate any issues with licensing.

In regards to handling the binaries at runtime...I think the solution would be to just emulate what EMGU.CV is doing for their runtime libraries, which handles this exact situation:

https://github.com/emgucv/emgucv/blob/master/Emgu.CV.Runtime/Windows/Emgu.CV.Runtime.Windows.projitems

@olitee
Copy link
Contributor

olitee commented Aug 12, 2021

@d8ahazard I like this idea, but I think it needs opening up for investigation and discussion. Could you create a new issue for this, as it's a little lost in this maintainers thread.

@olitee
Copy link
Contributor

olitee commented Aug 13, 2021

For those interested, v3.1.0 of the ManagedBass nuget packages have now been released:

https://www.nuget.org/packages/ManagedBass/3.1.0

@mysteryx93
Copy link
Contributor

I'm not sure that including the unmanaged DLLs is a good idea, because you do not know which DLLs the application wants to include or not.

Here's my solution, I created a project with all the DLLs, and I simply reference the BassDlls project to get all the DLLs for the desired platform. There's another BassEncDlls project for when I need to encode.
https://github.com/mysteryx93/HanumanInstituteApps/blob/master/DLL/Bass/BassDlls.csproj

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

9 participants