SpinTool (SuperBoucle) new release

[manu_controvento]

Hi everyone!
Just to let everyone know that I released a new version of SuperBoucle - version 20.04.07
when I first tried SuperBoucle, I believed it was a nice alternative to Ableton Live, but imho it lacked of some useful functions.
So I created my fork from Vampouille's master repository (i.e. its creator... which I thank again) and I did my own changes and now my version is available at:

https://github.com/manucontrovento/superboucle

Wiki documentation is also available:

https://github.com/manucontrovento/superboucle/wiki

[houston4444]

Hi !
Quite strange idea to make a release of a fork without renaming it.
I quickly test to open it, and directly wanted to report an issue.
Impossible, No "Issues" tab in your github, probably because it is a fork.
There are a lot of appearance troubles here (D.E: KDE Plasma, Breeze Dark theme).

[sysrqer]

Really looking forward to trying this out, will be playing with it this weekend. Thanks for posting and for the extra work you've done for it!

[manu_controvento]

Hi !
Quite strange idea to make a release of a fork without renaming it.
I quickly test to open it, and directly wanted to report an issue.
Impossible, No "Issues" tab in your github, probably because it is a fork.
There are a lot of appearance troubles here (D.E: KDE Plasma, Breeze Dark theme).

Hi!, well, I'm really new to all this system; I'm a sw developer but really new to linux developing and python language, so it's my first work. I guess some issues could happen. About the fork, being the first time I also upload something in repository, I just looked at how other people forked their versions. And I did the same.
I'll check if Github has some options for issues posting which I didn't see...

[manu_controvento]

Hi !
Quite strange idea to make a release of a fork without renaming it.
I quickly test to open it, and directly wanted to report an issue.
Impossible, No "Issues" tab in your github, probably because it is a fork.
There are a lot of appearance troubles here (D.E: KDE Plasma, Breeze Dark theme).

Ok! I found how to enable "issues". Thanks!

[SpotlightKid]

Yes, forking repos to maintain you own changes to the software is coming practice.

But as soon as you package and announce your own releases, you should make it clear that your version is different from the original project. Renaming the project (with a reference to the original project in the docs) is probably the most clear way of doing this.

Anyway, looks like an interesting project, I'll sure check it out soon.

Chris

[manu_controvento]

Yes, forking repos to maintain you own changes to the software is coming practice.

But as soon as you package and announce your own releases, you should make it clear that your version is different from the original project. Renaming the project (with a reference to the original project in the docs) is probably the most clear way of doing this.

Anyway, looks like an interesting project, I'll sure check it out soon.

Chris

Thanks for the advice! I'll consider renaming it.
I already thought about renaming it and changing a bit its logo too, but I thought it would be unpolite towards its original author.
Anyway, I'll do it! Now I understand it would be better.

[tramp]

I already thought about renaming it and changing a bit its logo too, but I thought it would be unpolite towards its original author.
Anyway, I'll do it! Now I understand it would be better.

Usually the way to go is send pull requests to the original authors repository, after you've forked it. If, your requests become useful, normally the original author will invite you to become a contributor, then, you could work together with the original author on the application. That's, how GNU GPL'ed projects work, that's how "fork" work..
Maintain your own fork, rename it, with or without a hint to the original project, means, at least, split development power, and is the last step one do after all other tries fall.
Surly a couple of GNU projects have reached this point, were the development team couldn't find a agreement for the future of the project and a "real" fork happen, but my impression of the situation here is, it's far from that.
Please. do yourself, and the original author, a pleasure, take a step back, and talk with upstream about what you've liked to see implemented, and what you like to do of that by yourself.

That's how this stuff work on GNU Linux.
regards

[SpotlightKid]

Usually the way to go is send pull requests to the original authors repository, after you've forked it. If, your requests become useful, normally the original author will invite you to become a contributor, then, you could work together with the original author on the application. That's, how GNU GPL'ed projects work, that's how "fork" work..

I wouldn't see this as a hard and fast rule. If you take a project and add things, which are useful to you, but maybe take the project in a different direction than the original author intended, I don't see a problem when a fork diverges and is maintained separately. At least the author of the fork makes his personal changes public, so others can benefit from them. If the fork author provides his changes as a PR for upstream, all the better. But maybe sometimes such changes are difficult to integrate into upstream or a fork author is moving too fast for the upstream maintainer, etc. so this doesn't always work out. Life's that way

[milkii]

GitHub really didn't help by using (overloading) "fork" rather than "clone".

[tramp]

Usually the way to go is send pull requests to the original authors repository, after you've forked it. If, your requests become useful, normally the original author will invite you to become a contributor, then, you could work together with the original author on the application. That's, how GNU GPL'ed projects work, that's how "fork" work..

I wouldn't see this as a hard and fast rule. If you take a project and add things, which are useful to you, but maybe take the project in a different direction than the original author intended, I don't see a problem when a fork diverges and is maintained separately. At least the author of the fork makes his personal changes public, so others can benefit from them. If the fork author provides his changes as a PR for upstream, all the better. But maybe sometimes such changes are difficult to integrate into upstream or a fork author is moving too fast for the upstream maintainer, etc. so this doesn't always work out. Life's that way

@SpotlightKid What the heck is now different in what you wrote? Sounds to my like you repeated what I wrote, just with other words. So, you didn't see it as a hard rule? But I do?? wops

Surly a couple of GNU projects have reached this point, were the development team couldn't find a agreement for the future of the project and a "real" fork happen, but my impression of the situation here is, it's far from that.

Exact, life is this way.

[manu_controvento]

I already thought about renaming it and changing a bit its logo too, but I thought it would be unpolite towards its original author.
Anyway, I'll do it! Now I understand it would be better.

Usually the way to go is send pull requests to the original authors repository, after you've forked it. If, your requests become useful, normally the original author will invite you to become a contributor, then, you could work together with the original author on the application. That's, how GNU GPL'ed projects work, that's how "fork" work..
Maintain your own fork, rename it, with or without a hint to the original project, means, at least, split development power, and is the last step one do after all other tries fall.
Surly a couple of GNU projects have reached this point, were the development team couldn't find a agreement for the future of the project and a "real" fork happen, but my impression of the situation here is, it's far from that.
Please. do yourself, and the original author, a pleasure, take a step back, and talk with upstream about what you've liked to see implemented, and what you like to do of that by yourself.

That's how this stuff work on GNU Linux.
regards

Hi Tramp!

yes, I know about it, but SB project was stuck since its author currently has no time to develop it and, second thing, I never developed in Python until now and I never developed anything on Linux in general. I tried, beacuse I needed some extra features. I made some intensive testing and it seems stable to me. This means that perhaps code could be improved furtherly, so I didn't want to affect SB's master branch.
I needed to proceed now, I was waiting since some month for my requests in SB's Issues to be considered... now I had some time and so I decided to do this way.
Anyway: if in next weeks Vampouille will consider working again on SB, I won't deny my code, my contributions and we'll consider what to do. In my opinion this is at now the best way to proceed (and for sure, the only way for me to work with SuperBoucle/SpinTool live, on stage)

So. I changed application's name, Wiki, etc.

My version name is now: SpinTool

https://github.com/manucontrovento/SpinTool

and Wiki

https://github.com/manucontrovento/SpinTool/wiki

Have a nice day everyone!

[manu_controvento]

GitHub really didn't help by using (overloading) "fork" rather than "clone".

True...

[Michael Willis]

Oooh, this is exciting. I have to warn you, open source development is kind of like Hotel California. About 2½ years ago I thought I would spend a few weekends building a plugin that I wanted. Here I am, still tinkering around with it!

[manu_controvento]

Hi everyone!
version 20.04.26 is available
Since my last post, a bunch of releases (and fixes and improvements) occurred...
Have a look at it!

https://github.com/manucontrovento/Spin ... /v20.04.26

(Wiki is updated to previous version; soon I'll update it)