App is made with AI.
Nothing much to say, it’s rather an alpha release, i plan to tinker with it later this week. Currently playback, likes and search work, the rest needs do be done/redone.
Openrepos link: Soundsail | OpenRepos.net — Community Repository System
Source code: GitHub - neneneche/harbour-sonicsail · GitHub
Screenshots can be found on Openrepos.
0.2.0 update changelog:
Openrepos seems to have issues since i can’t publish any changes. Please download update from RPMs folder from github. I will update the page on Openrepos as soon as i can.
Hi @neneneche
I don’t use SoundCloud, but I would like to share few tips about working with code and ai. I hope they’re useful, so please take them as suggestions, not criticism. I am writing this, to hopefully encourage you to keep working on this app and make your work a little easier . My boss decided to vibe-code changes on an app, that I’ve been building for him for +6 months. It was easier to explain things to him, so his code quality wouldn’t degrade the whole project. Not sure what you know about programming, so I structured this as to a non technical vibe coder.
The idea is to make a change for x, then another change for y, so they don’t end up bundled together and you can “load” the save from after x but before y. Why, you may ask ? Let’s say you push a new feature that adds Related tracks. You build the app, people install it, and they start reporting the feature doesn’t work. On Sailfish this isn’t a huge problem because you can fix it and push again. But with separate commits you also have the option to “load” the last commit that worked and build from that straight away for stores, that do not support installing older versions of your app. eg. Google play store
Since you use claude, you could ask it to help you learn git and use it in your project. Run /init on its own first. It reads your project and writes a CLAUDE.md file, which includes instructions for it. Those instruction do include everything, from how git should work, to how code should look like. It may ask you follow-up questions so the instructions fit your code. Then send it something like this as a normal message:
I’m new to programming and Git. Please guide me through making and releasing changes safely, writing clear commit messages, and using git in this project. Explain what you’re doing and ask me questions when you need to understand what I want. When you finish a distinct change, suggest a commit and explain why it’s a good point to save the work. I work alone, so I don’t need to use separate branches unless there’s a good reason. Please also write these rules into CLAUDE.md so they apply in future sessions.
That last sentence matters. Without it, you’ll have to repeat all of this in every new session.
If you want to learn a little more about how Git works in general, you can watch this video. It’s a 100 second explainer. Might be a little too short, but it covers most of what you’ll use: https://www.youtube.com/watch?v=hwP7WQkmECE
You already have a .gitignore, so it just needs a few more lines:
RPMS/
harbour-soundsail
harbour-soundcloud
.gitignore only affects files, that git doesn’t track yet. Files that are already committed stay tracked, so you also need to tell Git to forget them:
git rm -r --cached RPMS
git commit -m "Stop tracking build output"
If you want to see how another vibe-codded ( as far as I know ) project handles this, have a look fintube’s .gitignore and LICENSE: GitHub - sandstorm244/harbour-fintube · GitHub. I’m not saying copy everything from it, just that the layout is a reasonable reference. You can also paste this whole point to Claude and it’ll help you do it.
x.x.x update. That’s a good start, but it’s worth also creating an actual release at Releases · neneneche/harbour-sonicsail · GitHub. The usual way is to mar version with a tag first:git tag v1.2.0
git push --tags
Then github lets you create a release from that tag and attach the RPM. That way anyone can open the releases tab, download the package for a chosen version, and see the exact code it was built from.
Consider adding a changelog. It helps users understand what the app does and what has changed, especially if they find the project without seeing the forum thread you start writing release notes, that more or less becomes your changelog.
Your project has no LICENSE file, even though the readme says See repository license (BSD-3-Clause unless otherwise noted). That note points at a file that isn’t there. It’s worth fixing.
About openrepos: the site is in read-only mode because of a php issue, so nothing new can be published there for now: Openrepos is in Read-Only Mode | OpenRepos.net — Community Repository System
Ps. If you’d like a hand with Git or the app, feel free to ask I am not a c++ developer, but I might still be useful.
well, yeah, thanks for the tipps! i will reorganize it today. i didn’t bother to include proper pushes regarding some features made or fixed in between updates since LLM generates too many new issues in between fixes, so imo it kind of makes sense to publish the working slop rather than non-/ halfwaysworking one
i’ll check whether xiaomi can write a proper md file too.
Comments: shown in “open track/related tracks”(if anyone has an idea for a better naming scheme here – please tell me) as a single comment. Click to expand last 20 comments. Posting a comment also does work, send is done with enter. I didn’t manage to make all of them showing in a scrollable list. Comments can be fully disabled in settings.
Well, i ran out of tokens. Current build is published on Github once again. Openrepos will be updated as they turn off read-only.
