COMMUNITY

Interactive fretboard 🎸

Hey there, I just released a personal project :guitar: https://interactive-fretboard.com

I am a Haxe developer with great passion for playing guitar. Lately I am trying to understand the guitar better and especially how the chords and scales are created and how they relate to the positions on the guitar. So I’ve build a online visualization that helped me on that. It started mostly as tool for myself, but I noticed this might be useful for others too. I still have to learn a lot myself, I starting to get some parts from theory perspective, but I don’t have them all “in the fingers” yet.

I noticed while creating the website that the theory behind chords actually is relative simple actually, just some “intervals over intervals”, from a programmer perspective that was wasn’t the hardest part. Mapping the theory to real guitar playing is of course a lot harder. Then it helps when you can easily visualize everything during practice sessions. For example, I like to switch between note names and intervals (since lots of online tutorials talk about such steps) and switch easily to different keys.

The website is build with Haxe 4 + coconut.vdom, which is a really great experience (type-safe, reactive views, component based, pure Haxe).

Ask me anything.

TLDR; If you play guitar/ukulele/banjo/mandolin, you might find this interesting:
https://interactive-fretboard.com

19 Likes

Quite nice! Congrats!

Ask me anything.

  1. How do you handle bundling? (I’m assuming you don’t use any bundler and just use the raw bundled js from Haxe?); what is the final size of the bundle, including any external assets you use?
  2. Where is it hosted? Does it have a server-side or is it purely CSR*[0]/serverless? How do you deploy it? Is there a way to quickly rollback to a previous state if needed? (Capistrano is a nice tool for that, btw, that is, if you haven’t already drank the container/k8s et al koolaid, I still tend to prefer single powerful VMs to container clusters to start with :slight_smile: );
  3. Did you add (automated) tests? If so, what kind of tests (unit, integration …)? What testing libs did you use?
  4. What were your frustrations while using this Haxe-based stack to develop your web app? Anything you wish was better/different?

*[0] Client-Side Rendered

2 Likes
  1. No bundler, just Haxe + Terser to minify (using uglifyjs lib)
  2. I have some simple hosting somewhere, where I can trigger a “pull” button in some plesk admin, and that grabs the thing from a private github repo.
  3. No tests. (If it compiles, it is probably ok)
  4. I wanted to challenge+learn something when creating it. I used vscode only in this project. That was super nice. Except I’m used to refactor/rename a lot, and that’s unfortunately not possible. For coconut, I got some help on discord but overall it was not frustrating at all, lots of stuff makes sense. I used it a few times in some tiny test projects but this is the biggest thing I created with it. Its a different way of thinking compared to making games or how one could create websites, but I have used vue before. The only thing about coconut is you have to figure out which dependencies you exactly need. As for the wishes; would be great if there was a static renderer for coconut. And maybe some more users so it was easier to look how some people setup their project. But again, I recommend all to try it if you want to make some online app.
3 Likes

Hey Mark, thank you for the answers.

I see there’s an #en param/anchor in the URL, which I assume stands for English. Did you implement i18n? If so, what did you use? And any specific reasons you used an anchor syntax (with a hash # prefix)?

1 Like

Well done!

I see there’s an #en param/anchor in the URL, which I assume stands for English . Did you implement i18n? If so, what did you use? And any specific reasons you used an anchor syntax (with a hash # prefix)?

No localisation yet, but already in url for, well, just in case.
The hash was just easiest choice to support deeplinking, but I’m working to change that to “normal urls” (using pushState).

No pressure but do you plan to open source? That would be nice to have a feel for what a real coconut app looks like ;). This even could be linked from their website as a demo of what can be done.

I have to think about this, I don’t want it to be forked/republished. What would be a good license for that?

Not quite what you asked but it’s a possible candidate.

GPL 2.0 would force people to maintain your name and make any change open source, so if it’s forked you can benefit from the changes, and it can never become closed source. GPL 3.0 would in addition to the above prevent it from being used in closed devices such as the Kindle.

Maybe some kind of the Creative Commons License would fit better, e.g. to prevent any commercial use or prevent any modifications.

Some random diagram

The GPL isn’t the best for websites since hosting doesn’t count as distribution, and so most of the restrictions don’t apply (though with js it’s unclear if that’ true). The AGPL fixes that.

You could also release the app without any data/content, if that’s easy to do.

Another solution is to just not make it open source, big commercial game engines like unreal engine or cry engine do that, the source is online, but you don’t have any rights on it (besides using it according to an eula which doesn’t apply here).
That’d make it more of a learning resource, but people can’t legally copy parts of it.

1 Like